[00:02] <cyphermox> Kaleo: ?
[00:03] <Kaleo> cyphermox, we are going to need to land a ui toolkit release soon
[00:03] <Kaleo> cyphermox, can you help?
[00:07] <robru> Kaleo, sorry, I was on lunch. back now. is it landed?
[00:07] <Kaleo> robru, lunch?
[00:07] <Kaleo> robru, where do you live??
[00:07] <robru> Kaleo, west coast north america ;-)
[00:08] <Kaleo> robru, mad person
[00:08] <Kaleo> robru, anyway
[00:08] <Kaleo> robru, it's not landed yet, we are doing final tests before top approving
[00:11] <robru> Kaleo, ok, i'm here now for at least 3 more hours
[00:12] <Kaleo> robru, brilliant
[00:12] <robru> then dinner break, then probably back again even later
[00:12] <Kaleo> :D
[00:28] <Kaleo> robru, it's top approved; waiting for landing.
[00:28] <robru> Kaleo, great
[00:57] <cyphermox> robru: I'm around too if you need any help
[00:57] <robru> cyphermox, cool. might need you to help test ubuntuuitoolkit once it builds.
[00:58] <cyphermox> alright, just ping me when
[01:05] <robru> Kaleo, there's a test failure in the branch: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/1104/console can you fix it?
[01:07] <Kaleo> robru, it's a blip
[01:07] <Kaleo> robru, rerun jenkins
[01:07] <robru> Kaleo, flaky test?
[01:07] <Kaleo> robru, or flaky infra
[01:07] <Kaleo> (test completely unrelated to the fix)
[01:07] <Kaleo> (also it succeeded before)
[01:08] <robru> Kaleo, ok, I'll just ram it through then. I see timp did some independent verification as well
[01:08] <t1mp> yes, looks unrelated.
[01:08] <Kaleo> t1mp, :)
[01:08] <t1mp> I can happrove again and then really go to sleep :)
[01:08] <robru> t1mp, no worries, I will merge manually due to the urgency of this
[01:08] <t1mp> okay, thanks.
[01:08] <Kaleo> thanks robru
[01:09]  * t1mp off
[01:09] <robru> t1mp, goodnight!
[01:27] <robru> Kaleo, this commit doesn't apply cleanly based on what is in distro currently. very difficult for me to backport. are you sure we can't just release uitk trunk as is?
[01:28] <robru> ls
[01:28] <Kaleo> robru, go for the release
[01:28] <robru> Kaleo, great, thanks
[01:29] <robru> cyphermox, still around? just built uitk in PPA, ready for testing ASAP
[01:38] <robru> Kaleo, erm.... just tried the latest build with this patch on my device and it doesn't show any tabs at all for the indicators...
[01:40] <Kaleo> robru, that does not quite make sense, let me see
[01:41] <robru> Kaleo, tab bar takes up corrent height space, but it's blank. no text appears within it
[01:41] <robru> Kaleo, oh, nm, rebooted and it's fine. must have been some mismatch between memory vs newly installed files.
[01:42] <Kaleo> ah
[01:42] <robru> Kaleo, actually they still don't like up after the reboot though ;-)
[01:43] <robru> Kaleo, oh strange, i might not have the right version installed. odd.
[01:44] <Kaleo> "<robru> Kaleo, actually they still don't like up after the reboot though ;-)" not sure what that means
[01:45] <robru> Kaleo, I mean, the indicator icons do not match the tab names. as in, the original bug is still the same. but it seems when I updated the package on the device it didn't get the latest version from the PPA
[01:45] <Kaleo> ok
[01:45] <robru> Kaleo, couple of false starts here, rushing too hard ;-)
[01:45] <Kaleo> :)
[01:45] <Kaleo> you are scaring me
[01:46] <robru> Kaleo, first problem was not rebooting after update, second problem was looking at https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=toolkit&field.status_filter=published seeing 'published' and then not realizing that armhf was still building (published just means source package published)
[01:47] <Kaleo> oki doki
[01:52] <Kaleo> I'm here in case anything goes kaboum
[01:52] <robru> Kaleo, ok, indicators look good, just gotta run through a suite of tests to check for regressions then will publish. thanks for doing the hard part ;-)
[01:53] <Kaleo> robru, thanks
[01:54] <robru> rsalveti, you still around to kick the image build? should be ready in about an hour
[01:55] <rsalveti> robru: yup
[01:55] <rsalveti> robru: let me know once you publish the package
[01:55] <robru> rsalveti, ok, will do
[02:09] <Kaleo> robru, I suppose you don't need me anymore
[02:09] <Kaleo> actually
[02:09] <robru> Kaleo, just saw 100% passes on uitk tests, so I think we're good. some more tests before publishing though
[02:09] <robru> Kaleo, thanks!
[02:09] <Kaleo> robru, ok
[02:10] <Kaleo> robru, if anything goes awry zsombi and bzoltan should be up in few hours
[02:10] <Kaleo> robru, thank you
[02:21] <cyphermox> robru: sorry, I'm around now
[02:21] <cyphermox> still need testing?
[02:27] <robru> cyphermox, yeah sure, install uitk from the ppa and run some app tests
[02:27] <cyphermox> ok
[02:28] <robru> cyphermox, so far so good, ive done addressbook, camera, dialer, and working on gallery now
[02:33] <cyphermox> figured ;)
[03:08] <robru> rsalveti, ok, uitk is published. not sure when it will make it through -proposed and into distro, but can you watch for it and kick a build soon?
[03:09] <rsalveti> robru: just, still waiting it to be accepted by lp
[03:13] <rsalveti> in proposed
[03:23] <robru> rsalveti, alright I'm EOD but will probably be back around in 4ish hours if anything is needed. best is to email me.
[03:24] <rsalveti> ok, will trigger a new image in a few
[03:24] <robru> rsalveti, thanks! goodnight!
[03:24] <rsalveti> np, goodnight!
[05:12] <rsalveti> robru: seems to be published in the lp UI for almost one hour but not yet published in the real archive
[05:13] <rsalveti> wonder if something wrong happened
[05:23] <Mirv> weird
[05:23] <rsalveti> rmadison ubuntu-ui-toolkit is still not showing the latest version
[05:23] <rsalveti> not even in proposed, as it was one hour ago
[05:23] <Mirv> rsalveti: do you know who archive admin might be online? I've never seen a situation where LP states it in either proposed/release but rmadison doesn't show anything
[05:24] <rsalveti> not sure, let me ping them at #ubuntu-release
[05:24] <Mirv> thanks
[05:26] <rsalveti> triggered a new image so we can have the other many changes tested asap
[05:26] <rsalveti> but we'll need another one once this issue with the toolkit is fixed
[05:28] <rsalveti> anyway, scheduled another image respin once the one I triggered a few minutes ago is done
[05:30] <rsalveti> and I'm gone, later!
[05:32] <Mirv> bye!
[06:57] <didrocks> Mirv: hey, how are you?
[07:08] <Mirv> thanks, fine didrocks. how's your start of the day?
[07:08] <didrocks> Mirv: well, catching up, I guess will be a busy day!
[07:08] <didrocks> Mirv: thanks for the keyboard release, you are on upstart-app-launch now?
[07:09] <Mirv> didrocks: yeah, or that's also now published and soon in proposed
[07:09] <didrocks> great!
[07:09] <didrocks> so, if I'm correct, what remains:
[07:10] <didrocks> the unity8 crash due to Mir
[07:10] <didrocks> and the wlan/gsm connexion in empathy
[07:10] <didrocks> did I mention anything else to you that I'm forgetting?
[07:12] <Mirv> no, that's the remaining thing, and you didn't even mention empathy
[07:12] <Mirv> the bug has been updated to say it's not mir related, but might be unity-mir related (which hasn't seen changes besides version bump)
[07:13] <didrocks> Mirv: I wonder if we can envision reverting unity-mir to previous release
[07:14] <didrocks> Mirv: there were a lot of revs between rev 136 and latest in distro
[07:14] <didrocks> Mirv: can you try building rev 136 against latest Mir? (well 137 to get the changelog ;))
[07:15] <didrocks> to ensure there is no API break
[07:15] <didrocks> I guess the daily-build ppa has a newer Mir, so building directly on phone?
[07:15] <didrocks> (when I meant latest Mir, I meant, latest Mir released in distro)
[07:15] <didrocks> I'm taking care of the empathy thing with upstream
[07:15] <didrocks> we do have a double bug there :)
[07:29] <Mirv> didrocks: hmm actually there is one new commit in unity-mir, I wonder if there's any chance it would fix something
[07:30] <didrocks> Mirv: it doesn't seem related, I would rather try "previous Mir release"
[07:30] <didrocks> (to the part of the code crashing)
[07:30] <Mirv> ok.. and locally indeed
[07:30] <didrocks> thanks Mirv, keep us posted, if we can get that + the empathy one, we can rekick an image
[07:30] <didrocks> and have a beautiful day :)
[07:45] <robru> didrocks, http://q-jenkins.ubuntu-ci:8080/job/cu2d-webapp-saucy-3.0publish/82/console can you check why this never made it into proposed?
[07:46] <robru> saucy-proposed, that is
[07:46] <didrocks> robru: because saucy is released?
[07:47] <didrocks> so it's in unapproved: https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=
[07:47] <robru> didrocks, i thought the whole point of saucy-proposed was to hold uploads prior to SRU approval?
[07:48] <didrocks> robru: no, SRU approval is to get to -proposed
[07:48] <didrocks> then, people can test for 7 days in proposed
[07:48] <didrocks> and if no regression is spotted, it's going to -updates
[07:48] <robru> didrocks, this process is insane.
[07:49] <didrocks> robru: well, it's the process when we had no test automation
[07:49] <didrocks> it was fine by then
[07:50] <robru> didrocks, so i have an SRU bug filed and ubuntu-sru proposed, they will eventually look at it and put it in -proposed? I already verified the change in a fresh saucy VM, so I already tagged the bug 'verification-done' even though it's not even in -proposed yet.
[07:50] <didrocks> robru: you shouldn't tag it before it's in proposed
[07:51] <didrocks> robru: but yeah on your first question, this is the process
[07:51] <robru> didrocks, ok. /me cries
[07:51] <didrocks> weird you were not aware about the process before discussion the SRU process session :)
[07:52] <robru> didrocks, and yet, I was arguing against a simpler process... now I find out the process is **even harder** than I already thought was so hard it deserved to be argued against!
[07:52] <didrocks> well, there are reason to not accept every crack that people want to SRU
[07:52] <didrocks> or we can end like in fedora when they SRU a new KDE major release :)
[07:53] <robru> didrocks, yeah, I understand the need for SRU when it comes to stuff that can't break when left to it's own. but when you are in a race to play catch up with half the websites on the internet, every step in the process represents an enormous slowdown.
[07:53] <didrocks> robru: agreed
[07:53] <didrocks> this is really a difficult situation
[07:53] <didrocks> I totally get you, no worry :)
[07:54] <robru> didrocks, well, I published my first click app today. it was delightful. it is *absolutely* the only acceptable way to publish webapps. The fact that I have to SRU webapps into trusty for the next 5 years is nothing short of tragic. I don't think I can do it.
[07:55] <didrocks> robru: push to convert them to click apps then, but there are a lot of implication in term of security I guess :)
[07:55] <robru> didrocks, that's what my talk was about! i wanted to clickify desktop webapps in trusty! but I was immediately shot down, click apps won't be ready in desktop trusty.
[07:58] <robru> didrocks, can you accept my saucy nomination here? https://bugs.launchpad.net/ubuntu/+source/unity-webapps-facebookmessenger/+bug/1246503
[07:59] <didrocks> robru: done!
[08:00] <robru> didrocks, thanks.
[08:00] <didrocks> yw
[08:00] <didrocks> thanks for the toolkit upload
[08:00]  * didrocks hopes the last 2 remaining issues will be gone soon and we can move on
[08:00] <robru> didrocks, no worries. I did really try to backport that patch but there were soo many conflicts.
[08:01] <didrocks> robru: as long as you ensured all tests were working, that's fine
[08:01] <robru> didrocks, yep yep, ran all tests and also dogfooded directly, saw the indicators working.
[08:02] <didrocks> robru: excellent, let's cross fingers, there was no other unseen regression bundled
[08:02] <didrocks> robru: the fix has a test btw?
[08:02] <robru> didrocks, yeah, I think so. I didn't read it too closely but I saw the diff touching test files ;-)
[08:03] <didrocks> well, you should look more :)
[08:03] <Mirv> didrocks: doesn't look good for compiling older unity-mir against the current archive mir. the refactoring done needed for mirserver10 support is where the crash also happens, and there's eg. bzr141 after the refactoring that claims to fix another crash related to unity-mir's MirSurface. I'm not sure what to try.
[08:03] <didrocks> most of test files were deleted
[08:03] <didrocks> but         function test_tabOrder_bug1253804() {
[08:03] <didrocks> robru: so we're good ^
[08:03] <didrocks> :)
[08:04] <didrocks> Mirv: ok, so let's try to see with greyback
[08:04] <robru> didrocks, my understanding is that they didn' tjust fix the bug, they changed the way tabs are created. so many tests were testing obsolete API that was removed, that's why those tests are dropped. but yeah I do see new tests written there
[08:04] <didrocks> robru: ok
[08:04] <didrocks> robru: yeah, sounds good!
[08:05] <Mirv> ok
[08:05] <didrocks> alan_g as well
[08:05] <didrocks> Mirv: the first who can catch either of them :)
[08:05] <Mirv> robru: I also had the UI Toolkit updated already when I ran my various tests today, looked good too
[08:06] <Mirv> didrocks: upstart-app-launch is stuck because of a new dependency that is not available on arm64
[08:07] <didrocks> Mirv: can you work with the release team to get that unblock/see the best way to get the transition done?
[08:07] <didrocks> I'm trying hard on the empathy side meanwhile
[08:08] <Mirv> didrocks: ok
[08:12] <Mirv> arh, I can't bug them, it's not as simple as that. it's not that it wouldn't be available for arm64 otherwise, but there's a build-dep that specifies the PPA version.
[08:12] <Mirv> and for a reason, ie. the dbus-test-runner would need to be released
[08:14] <Mirv> so, hmm, adding dbus-test-runner to the landing task
[08:22] <Mirv> didrocks: it seems the reverse build-depends continue to build with the new dbus-test-runner (including the new upstart-app-launch that also uses the added DbusMock functionality), so is there something more specific to test in order to release it?
[08:23] <didrocks> Mirv: if it builds against it, feel free to release it to unblock
[08:23] <didrocks> as it's using it at build time
[08:25] <Mirv> thanks, yes it does and the build logs show the tests being run
[08:26] <Mirv> didrocks: ack needed http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-test-runner_14.04.0+14.04.20131126-0ubuntu1.diff
[08:27] <Mirv> the changelog is slightly misleading since the Vcs/M-A were added in a manual upload already
[08:27] <didrocks> Mirv: +1
[08:27] <Mirv> thanks again
[08:30] <didrocks> thank you Mirv :)
[08:43] <sil2100> Am I the only one that thinks a day should have more than 24 hours?
[08:43] <sil2100> So sleepy...
[08:43] <didrocks> sil2100: +1
[08:46] <didrocks> ogra_: popey: good morning around?
[08:46] <popey> didrocks: morning
[08:47] <didrocks> popey: I have a potential fix on the GSM bug
[08:47] <didrocks> (you know about that one, right?)
[08:47] <didrocks> https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1252737
[08:47] <popey> gsm no working when wifi?
[08:47] <popey> right
[08:47] <didrocks> when no wifi, right :)
[08:47] <didrocks> can you try a recent image
[08:47] <didrocks> with nothing changed on it of course :)
[08:47] <didrocks> +
[08:48] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5269486/+files/libmission-control-plugins0_5.16.0-1ubuntu2~ppa1_armhf.deb
[08:48] <didrocks> and https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5269486/+files/telepathy-mission-control-5_5.16.0-1ubuntu2~ppa1_armhf.deb
[08:48] <didrocks> I've tried a tentative "fix"
[08:48] <popey> then what? try and make a call when on wifi?
[08:49] <didrocks> no, disable wifi
[08:49] <didrocks> reboot
[08:49] <didrocks> see you are connected to the GSM network
[08:49] <didrocks> (hopefully)
[08:50] <popey> what's your test for connected to gsm?
[08:50] <popey> nmcli d ?
[08:51] <didrocks> popey: I'm just relying on the indicator TBH, not sure about a command line tool (and not really knowledgeable in that area)
[08:51] <popey> ah ok
[08:54] <popey> didrocks: http://popey.com/~alan/phablet/device-2013-11-26-085434.png
[08:54] <popey> that what you expect?
[08:56] <popey> wlan is down and I am browsing the web, and made a phone call too didrocks
[08:56] <didrocks> popey: yeah \o/
[08:56]  * didrocks hugs popey
[08:56] <popey> \o/
[08:56] <didrocks> popey: this is after a reboot, right?
[08:56] <popey> yes
[08:56] <didrocks> with wlan down?
[08:56] <popey> yes
[08:56] <didrocks> \o/
[08:56]  * didrocks makes a dance
[08:56] <popey> root@ubuntu-phablet:/# nmcli d
[08:56] <popey> DEVICE     TYPE              STATE
[08:56] <popey> /ril_0     gsm               connected
[08:56] <didrocks> thanks a bunch for confirming :)
[08:56] <popey> wlan0      802-11-wireless   unavailable
[08:56] <popey> np
[08:56]  * popey makes tea
[08:57] <popey> you dance, we drink tea. It's our cultural differences I value so much!
[08:57] <didrocks> ahah :)
[08:57]  * didrocks can have tea just after dputing
[09:14] <sil2100> The indicators on my phone confuse me on the yesterday's image ;)
[09:43] <Mirv> so can I ask also autopkgtest failure question on release?
[09:44] <Mirv> or simply here? I mean, this d-jenkins job ended with machine shutting down, which is maybe the only reason it failed? http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ARCH=amd64,label=adt/6/
[09:44] <Mirv> psivaa: ^ any idea?
[09:44] <psivaa> Mirv: i'll take a look
[09:45] <Mirv> thanks
[09:46] <ogra_> ev, could we re-nice whoopsie (and all its sub processes) and make sure it only starts ... say ... 30min after boot for the first time or some such ?
[09:46] <ogra_> -s
[09:47] <ev> ogra_: it doesn't have subprocesses
[09:47] <ev> if you have more than one whoopsie running, that's a bug
[09:47] <ogra_> ah, well, then only whoopsie itself ...
[09:48] <ogra_> what i'm thinking is, if we could make it slow and silent enough that the user doesnt get massively get bothered by having it running ... even if it takes 5x longer then ... i dont think it matters how fast we get the info if we get it at all
[09:48] <ev> the problem with delaying or disabling whoopsie is that it will make us blind to particular types of crashes. What happens if the phone boots, but crashes as soon as unity starts? They're not going to leave it running for 30 minutes.
[09:48] <ogra_> and a phone usually runs for a long time
[09:49] <ev> other platforms have crash reporting end-to-end. I think what we need to be doing is fixing whatever bugs exist in whoopsie, rather than papering over them by hiding it away
[09:49] <ogra_> yes, i dont want to disable it, just make it "silent" enough for the user to not notice it massively
[09:50] <ev> now there may be structural changes here as well. If someone can figure out how to get it to spawn via upstart whenever the same set of conditions are met that it's currently using to process reports, then it doesn't have to be long running
[09:50] <ev> I think renice'ing it or putting it in a cgroup that uses far less CPU is a wise idea
[09:51] <ev> I don't think processing a crash report should take priority over the UI process
[09:51] <ogra_> right ... just make it eat less resources if possible ... even if it takes longer to run
[09:51] <ev> exactly
[09:52] <ogra_> if it doesnt take more than i.e. the browser running ... the user shouldnt massively notice it
[09:52] <ev> but we should also be looking at why it's taking so long to process, and seeing if we can optimise that as well
[09:52] <ev> let's hit the problem from both ends
[09:52] <ogra_> ++
[09:52] <ev> whoop
[09:52] <ogra_> sie :)
[09:53] <Mirv> psivaa: I see also the previous successful run ended in shutdown, so I guess that part is normal but the permission denied etc. not similar to the successful run http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ARCH=amd64,label=adt/5/console
[09:53] <Mirv> psivaa: so the "dsc0t-with-bustle"", whatever it means, was the failure
[09:53] <psivaa> Mirv: yea I see that, permission denied appears to be the cause
[09:55] <didrocks> ogra_: ev: also checking we only run it on wlan :)
[09:55] <ogra_> well
[09:55] <didrocks> I don't think people want to upload on 3G the crash report ;)
[09:55] <ogra_> we should run it at all times ... but only upload on wlan
[09:56] <didrocks> yeah, that's what I meant by "running"
[09:56] <ev> didrocks: we only treat wifi and ethernet as being online
[09:56] <ev> in whoopsie
[09:56] <didrocks> ev: oh nice!
[09:56] <ev> always thinking ahead :-P
[09:57] <didrocks> heh, well done :)
[09:57] <ogra_> funnily i never see .upload files in /var/crash here
[09:58] <ogra_> (i assume i should ?)
[10:01] <ev> yes, though that's the job of apport (via whoopsie-upload-all)
[10:01] <Mirv> psivaa: there was also a new autopkgtest 2.5 released yesterday, maybe you could check with pitti if it's related? and just a few minutes ago some patch release "Fix ownership of test tree with --user option."?
[10:01] <Mirv> https://launchpad.net/ubuntu/+source/autopkgtest/2.5.1
[10:02] <Mirv> so if the error comes from that ownership issue, then it should be just fixed in proposed
[10:02] <ev> I vaguely recall us disabling this around release due to my broken upstart job
[10:02] <ev> slangasek had a bug for it
[10:02] <ogra_> well, /etc/default/apport considers it enabled
[10:02] <ogra_> i dont see it running though
[10:03] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1235436
[10:04] <ogra_> aww
[10:07] <psivaa> Mirv: thanks for the clarification. pitti is tracking and will restart the jobs that failed due to that issue. so i guess i could we are good
[10:08] <Mirv> psivaa: yep, it seems everything's now in order
[10:25] <Kaleo> Mirv,  robru, rsalveti, do you know if there was an image built with the latest toolkit?
[10:25] <ogra_> didrocks, fyi, on maguro the screen doesnt switch on again with r30 ...
[10:25] <ogra_> Kaleo, there was
[10:25] <didrocks> ogra_: really? :/
[10:26] <ogra_> didrocks, i know that davmor2 saw it before ... i can only manage to get it on when i tap or touch the screen after pressing the power button
[10:26] <Kaleo> didrocks, ogra_, rsalveti tried to kick it in the night; hopefully yes
[10:26] <ogra_> smells like Mir input handling
[10:26] <didrocks> ogra_: I was still on 29, let me upgrade
[10:26] <ogra_> Kaleo, yes, it is version r30
[10:26] <didrocks> for mako
[10:26] <ogra_> didrocks, seems to only affect maguro
[10:26] <Kaleo> ogra_, thanks!
[10:27] <ogra_> but if you dont know it it looks like it never wakes up again
[10:27] <didrocks> ogra_: so, in order, what are you doing?
[10:27] <didrocks> pressing the power button
[10:27] <ogra_> Kaleo, the indicator issue seems fixed
[10:27] <didrocks> to get it on
[10:27] <Kaleo> ogra_, thanks :)
[10:27] <didrocks> and then? :)
[10:27] <ogra_> didrocks, pressing the power button leaves me with a black screen ... then touching the screen immediately switches it on
[10:27] <didrocks> so that we can put into a bug report and starts looking at it
[10:28] <didrocks> an, juts pressing shortly
[10:28] <didrocks> just*
[10:28] <didrocks> so, the regression is about "it's turning on when you don't want to"
[10:28] <didrocks> right?
[10:29] <ogra_> no
[10:29] <didrocks> ah no
[10:29] <didrocks> got it
[10:29] <ogra_> its not turning on unless you touch the screen
[10:29] <didrocks> pressing the power button to turn the screen on doesn't seem to work
[10:29] <didrocks> yeah
[10:29] <didrocks> argh
[10:29] <ogra_> right
[10:29] <didrocks> do you think it's the android upload?
[10:29] <ogra_> no
[10:29] <ogra_> i assume its Mir
[10:30] <didrocks> ogra_: did you get that on image 29?
[10:30] <ogra_> (but totally guessing)
[10:30] <didrocks> and 28?
[10:30] <didrocks> Mir didn't change since then
[10:30] <ogra_> didrocks, i know davmor2 saw it before, but not sure which image he was on
[10:30] <ogra_> might have been <28
[10:30] <didrocks> ogra_: I guess your network connection is not good enough to flash an older image?
[10:30] <didrocks> just to confirm if we get it on image 28
[10:31] <didrocks> ogra_: confirming, it's not on mako
[10:31] <ogra_> well, lets wait for davmor2, he usually files bugs immediately
[10:31] <didrocks> yeah
[10:31] <didrocks> ogra_: if it's as reliable on image 28, I would say, let's not block the promotion on that, thoughts?
[10:31] <ogra_> it doesnt seem to be on mako based on a conversation i just had with timppa in #ubuntu-touch
[10:32] <didrocks> yeah, I do confirm
[10:32] <ogra_> didrocks, you know that mark uses a maguro for dogfooding ?
[10:32] <didrocks> ogra_: well, if it's in image 28, it's already there (and he didn't complain about it)
[10:32] <ogra_> at least thats what i was told a while ago (might have changed)
[10:32] <didrocks> ogra_: so, we won't regress from that image
[10:33] <ogra_> well, he might have switched to something performant nowadays :)
[10:33] <didrocks> roh, maguro isn't that bad
[10:33] <didrocks> I was really happy with android 4.x on it
[10:33] <ogra_> did you ever actually use it as your main phone ?
[10:33] <ogra_> (with ubuntu(
[10:33] <didrocks> ogra_: not on touch
[10:33] <didrocks> this was my own phone :)
[10:33] <ogra_> yeah, its dog slow
[10:33] <didrocks> ogra_: right, but seems android can do something fast with it
[10:33] <didrocks> so we shouldn't blame it on the hw
[10:34] <ogra_> starting more thna a few apps makes it go crazy etc
[10:34] <ogra_> i do blame the HW ... but just because it has an awful video chip that has awful drivers
[10:34] <ogra_> (if we had the same driver access google has it wouldnt be an issue)
[10:35] <didrocks> ogra_: but we are using the same driver, right?
[10:35] <ogra_> yes, but we cant look inside ... google can
[10:35] <didrocks> right
[10:35] <ogra_> and the PVR drivers are pretty awful ... that will bite us on intel even more
[10:36] <didrocks> PVR?
[10:36]  * didrocks googles
[10:36] <ogra_> (most of the mobile intel chips have the same PowerVR graphics chip the omaps use)
[10:36] <didrocks> ok ;)
[10:37] <didrocks> Mirv: any progress on the autopkgtests?
[10:37] <didrocks> Mirv: unity-mir is in trusty
[10:37] <ogra_> (using the same binary driver blob ..)
[10:37] <didrocks> Mirv: so just waiting on upstart-app-launch I guess
[10:38] <ogra_> sigh ... the clock is still only randomly running
[10:38] <ogra_> (out of three boots i only get it once nowadays ....)
[10:39] <didrocks> ogra_: I'm more lucky on mako
[10:39] <didrocks> ogra_: but even have it on desktop…
[10:39] <ogra_> that bug is open since months ...
[10:39] <didrocks> I know…
[10:41] <didrocks> final: autopkgtest,upstart-app-launch
[10:41] <didrocks> SUCCESS (263/261)
[10:41] <didrocks> phew!
[10:41] <didrocks> ogra_: almost ready to push the triggered once published in the release pocket?
[10:41] <ogra_> sure
[10:42] <didrocks> hum, maybe I'm reading it wrong
[10:44] <Mirv> didrocks: so the autopkgtest was with dbus-test-runner, and that was because of yesterday's autopkgtest 2.5, now fixed in 2.5.1 and pitti rerunning the tests
[10:45] <Mirv> the rerun seems to be now at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ , but update_excuses still showing it as fails
[10:45] <Mirv> and the upstart-app-launch arm64 rebuild was now done
[10:46] <didrocks> Mirv: yeah, so upstart-app-launch seems to be able to migrate, yeah!
[10:46] <didrocks> (just confirmed on #ubuntu-release)
[10:47] <Mirv> right, so it looks
[10:47] <Mirv> good good
[10:47] <didrocks> yep!
[10:47] <didrocks> ogra_: rmadison says it's published, wasn't there a slight delay with porter?
[10:47] <didrocks> before you kick the image?
[10:48] <ogra_> if rmadison has it it is fine
[10:48] <ogra_> [10:48] <didrocks> \o/
[10:48] <popey> \o/
[10:48] <didrocks> let's cross fingers ;)
[10:49] <didrocks> for the power button issue, let's see if we have it in image 28
[10:49] <Mirv> r31, the famous 'perfect' image
[10:49] <didrocks> will be nice to pinpoint which image it started with
[10:49] <didrocks> Mirv: well, for mako, not maguro :p
[10:50] <Mirv> with small exceptions, then
[10:56] <ogra_> didrocks, bug 1255045
[10:56] <ogra_> waiting for davmor2 to confirm ...
[10:56] <didrocks> ogra_: perfect and all tagged!
[10:57] <ogra_> :)
[10:57] <ogra_> so it shows up on Ursinha's list ;)
[10:57] <didrocks> yep ;)
[10:57] <didrocks> it's a nice addition
[11:00] <Saviq> psivaa, otto runner failing again http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/ :/
[11:00] <psivaa> Saviq: i'll take a look
[11:01] <Saviq> psivaa, the same happened yesterday
[11:02] <Saviq> psivaa, josepht managed to resolve it
[11:02] <psivaa> Saviq: ok, that info helps. i'll see if i can get that information
[11:02] <davmor2> Morning all
[11:03] <Saviq> psivaa, it was "a gpu lockup", josepht said it required kicking a machine
[11:03] <Saviq> psivaa, can get you the IRC log if wanted
[11:03] <psivaa> Saviq: that you grately help
[11:05] <davmor2> ogra_, didrocks: I confirmed your bug, I got the it wasn't always waking part but nobody else could confirm it, so I didn't write a bug initially while I dug into it some more but pressing the screen after a power button press does seem to wake it :)
[11:05] <didrocks> davmor2: can you try to pinpoint on what image this starts to occur?
[11:05] <didrocks> that would be really helpful
[11:05] <Saviq> psivaa, there's not that much http://pastebin.ubuntu.com/6478423/
[11:06] <didrocks> davmor2: especially between image 26 and 27
[11:06] <didrocks> (27 has a new Mir stack)
[11:07] <davmor2> didrocks: Let me play catchup on my email and I'll install 26 and then 27
[11:08] <didrocks> davmor2: thanks, keep us in touch!
[11:16] <psivaa> Saviq: the job appears progressing now: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/1004/console
[11:19] <didrocks> ogra_: can you put the workaround in the bug itself?
[11:19] <ogra_> workaround ?
[11:20] <didrocks> ogra_: like, touching the screen after pushing the button
[11:20] <didrocks> so that people being impacted by it know what to do
[11:20] <ogra_> did you read the bug ? :)
[11:20] <didrocks> ah "unless…"
[11:20] <didrocks> wasn't obvious to my broken head
[11:20] <ogra_> "when putting the phone to sleep by pressing power it will not wake up the screen when pressing power again unless the screen gets touched."
[11:20] <ogra_> yeah
[11:21] <didrocks> mind if I edit? :)
[11:21] <ogra_> feel free
[11:21] <didrocks> done
[11:24] <dpm> hi psivaa, could you help us with this issue in Jenkins? It seems to fail building reminders-app because of "virtual memory exhausted: Cannot allocate memory" -> http://91.189.93.70:8080/job/generic-mediumtests-trusty/248/console
[11:25] <psivaa> dpm: i'll take a look
[11:26] <dpm> cool, thanks
[11:29] <Saviq> psivaa, ok, will report back
[11:30] <psivaa> Saviq: ack, that jobs has finished success.
[11:35] <Ursinha> good morning :)
[11:35] <didrocks> hey Ursinha!
[11:36] <Ursinha> didrocks, ogra_, so I assume you want me to update that report periodically :)
[11:36] <ogra_> Ursinha, yes please :)
[11:36] <Ursinha> it was only an example, if you want other information or think that one isn't useful, let me know
[11:37] <didrocks> Ursinha: I think it's fine, just put it in the cron
[11:37] <psivaa> dpm: http://91.189.93.70:8080/job/reminders-app-ci/21/ has succeeded.
[11:37] <Ursinha> all right, will do
[11:37] <didrocks> and we look in particular to the avenger regression list
[11:37] <Ursinha> good
[11:37] <didrocks> Ursinha: btw, the 2 regressions with other like the GSM are fixed
[11:37] <didrocks> just waiting for the image to finish buildings
[11:37] <didrocks> building*
[11:37] <didrocks> tests to run
[11:37] <psivaa> dpm: do you happen to see virtual memory issue often?
[11:37] <didrocks> and davmor2 confirming the maguro issue isn't new
[11:37] <didrocks> to promote it
[11:37] <Ursinha> didrocks, awesome :) I was subscribed to the bug reports so I saw people worked hard yesterday
[11:38] <didrocks> and today :)
[11:41] <Ursinha> didrocks, ogra_, I'd suggest us adding to the bug policy to add the image number as a tag
[11:41] <davmor2> didrocks: emails covered rev 26 installing now
[11:42] <didrocks> Ursinha: very good idea, that's what I didn't really like in the current presentation
[11:42] <didrocks> Ursinha: we have the date, but we have can have cases like the one ogra mentioned
[11:42] <didrocks> and it seems to be more days older
[11:42] <didrocks> so yeah, all +1 for a tag
[11:42] <Ursinha> didrocks, I noticed that while testing/filing bugs myself
[11:43] <didrocks> Ursinha: for the cherry on top of the cake, if there can be a summary image by image (latest on top) with the bugs tagged to them :)
[11:44]  * didrocks tried to translate a French expression, let's see how it goes :p
[11:44] <dpm> psivaa, I've seen it happening in a few MPs: https://code.launchpad.net/~mzanetti/reminders-app/html2enml/+merge/196616 (it seems to not happen in the latest build), https://code.launchpad.net/~mzanetti/reminders-app/create-edit-delete-notes/+merge/196500 (could we retrigger this build?)
[11:44] <didrocks> "icing on the cake" it seems
[11:44] <mzanetti> dpm: I got permissions to retrigger those jobs...
[11:44] <dpm> ah, cool
[11:44] <Ursinha> didrocks, :)
[11:45] <mzanetti> dpm: done
[11:46] <davmor2> didrocks: do you happen to know what image was released on a specific date?
[11:46] <didrocks> davmor2: well, we can collerate that in some way, why?
[11:46] <dpm> mzanetti, great, thanks! Also, could you have a look at this MP and top-approve if it's ok? It should then allow Jenkins to upload to the PPA. Right now it's failing because it's trying to upload an older version that we had in the PPA (which was created by the daily recipe, which I've now deactivated) -> https://code.launchpad.net/~dpm/reminders-app/fix-dependencies/+merge/196696
[11:47]  * didrocks reboot on r31
[11:47] <didrocks> ogra_: ^
[11:47] <ogra_> ôh
[11:47] <didrocks> psivaa: please watch closely the test runs ;)
[11:47]  * ogra_ didnt notice it was done 
[11:48] <ogra_> sorry
[11:48] <ogra_> too many conversations today
[11:48] <didrocks> ogra_: no worry, I was like a kid rebooting it :p
[11:48] <didrocks> retrying it*
[11:48] <psivaa> didrocks: ok, will do
[11:49] <Ursinha> we had two images today, sweet
[11:49] <Ursinha> the amount of changes in the first one is overwhelming :/
[11:49] <ogra_> yeah
[11:50] <ogra_> we need cronned builds back
[11:50] <Ursinha> we really need to produce images using cron
[11:50] <Ursinha> that :)
[11:50] <ogra_> as manny as the infrastructure can handle per day
[11:50] <mzanetti> dpm: added some comments
[11:50] <didrocks> ogra_: do you know how to revert to vanilla image?
[11:50] <ogra_> so the changeset gets as small as possible
[11:50] <didrocks> I remember stgraber telling us some files to remove
[11:50] <didrocks> from a rw one
[11:50] <ogra_> didrocks, nope, ask stgraber, i know there is an easy way
[11:50] <Ursinha> ogra_, I think that we already have the image promotion thing that filters what's good and what's not, so I really don't see a reason to have two checkpoints
[11:51] <psivaa> dpm: which one of the above would you want me to rebuild?
[11:51] <ogra_> Ursinha, right, proposed will make sure images are always buildable ...
[11:51] <ogra_> cjwatson actually did put a lot of thought into it, its a shame we dont really use it
[11:52] <psivaa> dpm: both of them passed on ci
[11:52] <Ursinha> didrocks, if we have the image promotion process, why don't we build images regularly?
[11:53] <dpm> psivaa, thanks, mzanetti took care of that
[11:53] <psivaa> dpm: ack, thanks
[11:53] <Ursinha> I think it would be easier to find a regression with more images, do we keep previous versions?
[11:53] <davmor2> didrocks: iirc the first time I hit it was on the friday before I broke up for my holidays so the 16th  I spent an age running through things with pmcowan and kgunn (mostly) as I couldn't get my phone up then
[11:53] <ogra_> Ursinha, we kepp a week of images around usually
[11:54] <ogra_> (on cdimage, not sure what system-image.u.c does, stgraber can tell
[11:54] <didrocks> Ursinha: I already told I was in favor of that :) I'm not the blocking one here
[11:55] <ogra_> didrocks, oh ?
[11:55] <ogra_> when did you say that ?
[11:55] <didrocks> ogra_: well, when we discussed about it
[11:55]  * ogra_ was under the impression you wactually wanted manual builds 
[11:55] <Ursinha> didrocks, my question was what exactly is preventing us from doing that, I wasn't really implying you were the blocker :)
[11:55] <didrocks> ogra_: but you read half of the conversation it seems or didn't listen to me :)
[11:55] <didrocks> ogra_: I kept repeating you I was in favor, you didn't read though :p
[11:55] <ogra_> Ursinha, i was ... since i had that impression :)
[11:55] <dpm> mzanetti, happy to change the order of dependencies, but can't Jenkins fetch the packages from the PPA while they're not in the archive? That's what we used to do in the last cycle for plugins which were not yet in the archive, and it helped us with making them available for stable releases (e.g. saucy, I'm pretty certain none of the reminders app devs are on trusty yet)
[11:56] <didrocks> Ursinha: I guess asac doesn't like it
[11:56] <ogra_> didrocks, heh, sorry then
[11:56] <didrocks> ogra_: I was just telling, the most we can do is every 8 hours
[11:56] <didrocks> unfortunately
[11:56] <ogra_> thats 3 per day
[11:56] <didrocks> to give the time to test + rekick the tests that failed
[11:56] <Ursinha> I guess "doesn't like it" is the weakest reason ever :)
[11:56] <ogra_> right
[11:56] <mzanetti> dpm: well, one of them is on trusty :D
[11:56] <mzanetti> dpm: anyways... not sure what to do
[11:57] <mzanetti> dpm: I guess we'd need to change the jenkins setup to include some ppa
[11:57] <Ursinha> didrocks, we need to work on that part of the infrastructure, that affect us now and will continue to affect when the CI Airline is in place
[11:57] <Ursinha> the problem will be the same, maybe we need to add a Critical tag to this piece
[11:58] <didrocks> Ursinha: oh yeah, in fact, there are two issues:
[11:58] <didrocks> the first one is the mpt issue
[11:58] <didrocks> that disconnects the phone
[11:58] <didrocks> and so we loose adb shell
[11:58] <didrocks> (and so all tests are stopped)
[11:59] <didrocks> this one is supposed to be fixed if I read correctly
[11:59] <didrocks> I asked to get pinged if plars or psivaa still see it
[11:59] <dpm> mzanetti, yeah, I'd guess so, I'm not sure how fginther did it last cycle, but I could imagine that the coreapps PPA was added to the Jenkins setup. psivaa, could you give us a hand with this? In summary, it's about the last comment on https://code.launchpad.net/~dpm/reminders-app/fix-dependencies/+merge/196696 -> those packages are only available on a PPA right now, and we're wondering if that PPA can be added to the Jenkins setup so that it finds them
[11:59] <didrocks> Ursinha: the other are just utah flackyness which is mostly over
[11:59] <didrocks> Ursinha: we need to be able to run the tests in multiple phones in parallel as well IMHO
[11:59] <didrocks> so that we don't block on a solid 3h
[11:59] <didrocks> and be able to run the tests on any image #
[11:59] <mzanetti> didrocks: which ppa is it?
[11:59] <didrocks> (not only the latest)
[11:59] <ogra_> the emulator will help here
[12:00] <didrocks> mzanetti: hum? sorry, out of context
[12:00] <mzanetti> dpm: which ppa is it?
[12:00] <didrocks> ah ok :)
[12:00] <mzanetti> didrocks: sorry... damn tab completion
[12:00] <didrocks> ogra_: right
[12:00] <didrocks> mzanetti: happens to me all the time :)
[12:00] <Ursinha> didrocks, cool :) so down from 8 to 3 hours is a hell of an improvement
[12:00] <dpm> mzanetti, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily
[12:01] <davmor2> hmmm am I the only one seeing the indicators out of sync?
[12:01] <psivaa> dpm: looking
[12:01] <Ursinha> didrocks, is there a bug for the phone disconnection?
[12:01] <didrocks> Ursinha: something to ask to the CI team, I don't really know TBH
[12:02] <ogra_> Ursinha, i dont know if there is a bug, but sergio is actuvely working on fixes around all this
[12:02] <davmor2> ogra_: image 26 had the gsm/wifi issue once you connect to the wifi gsm appears
[12:03] <Ursinha> ogra_, we definitely should have a bug for such things
[12:03] <didrocks> davmor2: I think all those are fixed, we are only interested in the black screen one :)
[12:03] <ogra_> Ursinha, we do ... but badly tagged
[12:03] <Ursinha> ogra_, let's work on that :)
[12:04] <ogra_> Ursinha, bug 1233613
[12:04] <davmor2> didrocks: is that to the gsm/wifi issue or the  out of sync indicators?
[12:04] <didrocks> ogra_: urgh, I'm getting no indicator content
[12:04] <didrocks> ogra_: do you?
[12:04] <ogra_> actually assigned to me ... but sergio does all the work atm
[12:05] <ogra_> didrocks, on r30 i did ...
[12:05] <Ursinha> ogra_, so why the hell is that assigned to you? lol
[12:05] <didrocks> davmor2: it's another one: https://launchpad.net/bugs/1255045
[12:05]  * ogra_ needs to get his phone from the office 
[12:05] <didrocks> ogra_: let me reflash from scratch
[12:05] <ogra_> Ursinha, because i worked on the upstart jobs ... but that wasnt sufficient
[12:05] <davmor2> didrocks: yeah these were just things I noticed while I was waiting from my phone to sleep :)
[12:06] <didrocks> davmor2: yeah, so, we are just interested in knowing when that one started :)
[12:06] <davmor2> didrocks: so on 26 from a normal sleep it wakes up
[12:07] <didrocks> davmor2: let's hope it's 27 screwing it, that will give some hint :)
[12:07] <ogra_> Ursinha, sergio is currently doing a complete redesign of the wholesetup ... involving android changes etc ... i'm fine to operate as bug contact
[12:07] <ogra_> *whole setup
[12:07] <davmor2> didrocks: from power button sleep it also wakes up
[12:07]  * ogra_ thinks it is a Mir issue 
[12:07] <Ursinha> ogra_, I think you meant bug 1249162
[12:07] <Ursinha> ?
[12:07] <davmor2> didrocks: I'll let it sleep now and give it 10 minutes to test deep sleep too and then I'll move onto 27
[12:08] <ogra_> Ursinha, they are the same
[12:08] <didrocks> ok :)
[12:08] <didrocks> thanks davmor2
[12:08] <Ursinha> ogra_, oh? this one is actually assigned to sergio... and why do we have two? (they aren't marked as duplicates)
[12:08] <ogra_> davmor2, i put my bets on image 27
[12:08] <ogra_> davmor2, Mir was the only change between 26 and 27 and i bet you will see it there
[12:09] <Ursinha> didrocks, I booted on r31 and the indicators are here
[12:09] <Ursinha> and the bug seems fixed, yay
[12:09]  * Ursinha hugs Kaleo 
[12:09] <didrocks> Ursinha: hum, I have hope in my reflashing then :)
[12:09] <ogra_> Ursinha, i would even bet we have more than two :) yes, they should be duplicated
[12:09] <Kaleo> Ursinha, :D
[12:09] <didrocks> ogra_: feel earning more money this month? :)
[12:10]  * didrocks keeps betting on things he's sured to win :)
[12:10] <Ursinha> ogra_, you know, launchpad isn't a miracle shrine, people actually need to do stuff for it to work as expected :)
[12:10] <ogra_> didrocks, not sure what your contract says, mine isnt bound to the amountof bugs :)
[12:10] <didrocks> ahah :)
[12:11] <didrocks> come on mako, flash, FLASH! :)
[12:11] <ogra_> Ursinha, well, it would be good to have some community bug triagers looking at it... doing an ubuntu touc bugday once a month or so
[12:11] <davmor2> ogra_: I wish mine was I'd be a millionaire
[12:11] <ogra_> heh
[12:12] <ogra_> oh, look r31 is all green ... http://ci.ubuntu.com/smokeng/trusty/touch/
[12:12] <Ursinha> ogra_, can I mark the first bug as duplicate of the second? it has a better description of the problem...
[12:12] <ogra_> (only has run 11 tests indeed)
[12:12] <didrocks> ogra_: I bet if you wait a little bit… :p
[12:12] <ogra_> Ursinha, go ahead
[12:13] <didrocks> we really need to work on boot speed at some point…
[12:13] <didrocks> or at least, boot feedback
[12:14] <Ursinha> DONE
[12:14] <Ursinha> didrocks, +1 yes please
[12:14] <didrocks> waow, indicators \o/
[12:14] <didrocks> showing up content this time :)
[12:14] <Ursinha> this image feels much better than the previous, thanks everyone :)
[12:14]  * davmor2 paints the right hand side of didrocks screen green so he loses the bet :D
[12:15] <didrocks> Ursinha: not done yet, we need to wait for the test results and dogfood before promoting :)
[12:15] <didrocks> davmor2: rohhh
[12:15] <Ursinha> didrocks, I was actually talking about marking the bug as duplicate, hehe
[12:15] <didrocks> and ensuring that the maguro issue isn't a new one
[12:15] <didrocks> heh :)
[12:15]  * didrocks reboots
[12:16] <didrocks> and hope for no /var/crash/*unity8*
[12:16] <davmor2> didrocks: right 26 is waking from deep sleep moving onto r27
[12:16]  * didrocks waits on davmor2's phone explosion due to Mir :)
[12:16] <didrocks> and reboots -> nothing in /var/crash
[12:17] <didrocks> popey: can you start dogfooding image 31 please?
[12:17] <didrocks> so that once we have the test results, we don't block on that
[12:17] <popey> didrocks: sure thing
[12:17] <didrocks> thanks!
[12:17] <davmor2> didrocks: it's a maguro it hates mir at the best of time, sneeze in the wrong direction and the fb gets touched and you have to remove the battery to fix it
[12:18] <didrocks> davmor2: well, at least, you can remove the battery in it :)
[12:18] <didrocks> can't say the same for other devices. /me looks at his mako
[12:18] <didrocks> davmor2: so, we can say that Mir is using *all* functionalities of your phone :)
[12:19] <davmor2> didrocks: on the n4 and n5 you get minute long power button press to fix the universe though right :D
[12:19] <didrocks> yeah, I had to find that the hard way :)
[12:23] <didrocks> psivaa: hum, is it because it's running that we end up in that state? http://ci.ubuntu.com/smokeng/trusty/touch/maguro/31:20131126.1:20131126/5117/
[12:23] <psivaa> didrocks: we have one issue of network connection failing to become active on maguro soon after the installation, rerunning it again to see
[12:23] <didrocks> ok :)
[12:24] <didrocks> I like asking a question and getting the exact answer 2s later!
[12:24] <didrocks> this is "pre-emptive question answering" :)
[12:24] <psivaa> :)
[12:29] <psivaa> dpm: still working on it but most probably i would wait for fginther to sort that out (adding ppa' packages for core app MP)
[12:29] <psivaa> does not look that straight forward
[12:29] <dpm> ok, thanks psivaa
[12:36] <didrocks> davmor2: you are flashing image 27? /me still crosses finger we have the guilty guy :)
[12:37] <davmor2> didrocks: 27 just finished I'm just waiting for it sleep now
[12:37] <ogra_> why do you wait
[12:37] <ogra_> just press power to put it to sleep
[12:38] <ogra_> its not like it behaves any different between auto/manual sleep
[12:38] <davmor2> ogra_: because I'm QA I ran three tests for 26 so I'm running the same three for 27 for comparison :P
[12:38] <ogra_> heh, k
[12:39] <davmor2> didrocks, ogra_ : and bingo dead screen till touched
[12:39] <didrocks> \o/
[12:39]  * didrocks is loaded
[12:39] <ogra_> yeah
[12:39]  * didrocks goes to #ubuntu-unity
[12:39] <ogra_> asi said ... Mir
[12:39] <didrocks> ok, so not an image 31 blocker
[12:39] <didrocks> (for promotion)
[12:40] <didrocks> as latest promoted image already has it
[12:40] <didrocks> now, let's get the right team fixing it :)
[12:40] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131120.2.changes
[12:40] <ogra_> thats the changeset in question
[12:40] <didrocks> ogra_: clearly click-apparmor's fault :)
[12:40] <ogra_> haha
[12:40] <ogra_> yeah, lets blame jdstrand
[12:40] <didrocks> exactly!
[12:41] <didrocks> davmor2: ogra_: mind putting that information (with the link as well between the images) on the bug?
[12:41] <davmor2> ogra_: power button test only works if I leave it for a minute, for me if I press the power button so it sleeps then press it again it wakes.  so not sure if there are 2 levels on power button press for sleep going on
[12:42] <didrocks> ah, better to get the description with the full rationale so that they don't close it with "can't reproduce"
[12:44] <davmor2> added the tests and results
[12:45]  * didrocks targets Mir
[12:45] <didrocks> thanks davmor2, ogra_
[12:53] <Ursinha> didrocks, ogra_, all: if you touch a bug today that you know the image number when it was spotted, please tag the bug as such
[12:53] <ogra_> k
[12:53] <ogra_> Ursinha, probably add that to the mail thread too
[12:53] <didrocks> yeah, adding to the tread with an example, that would be nice
[12:53] <Ursinha> ogra_, I will, am currently updating the Avengers page to have these instructions
[12:54] <ogra_> would be good if we could set up a wikipage "Touch/bugPolicies" or some such, once we're done with discussiong it
[12:54] <Ursinha> ogra_, oh yeah :)
[12:54] <Ursinha> we have to, emails disappear hehe
[12:54] <ogra_> yeah
[12:54] <Ursinha> and it's ubuntu policy to document processes using wiki pages
[12:54] <ogra_> obviously :)
[12:54]  * ogra_ is still 100% sure we had such a mail 
[12:57] <davmor2> ogra_, didrocks: right installing r31 now I'm going to keep an eye out for the issues with wifi/gsm and indicator displacement
[12:58] <didrocks> davmor2: yeah, an additional confirmation won't hurt :)
[13:02] <didrocks> so, as tests are running and it's the only thing we are waiting on for promoting, let's get some exercise while it's still time
[13:02] <didrocks> psivaa: all waiting on you now :-)
[13:03] <didrocks> (seeing that maguro passed installed and friends, nice!)
[13:04] <psivaa> didrocks: ok, the failed one has come alright, and the rest are also going fine.
[13:04] <psivaa> didrocks: to have that all tests completed might take some time due to the running time :)
[13:05] <didrocks> psivaa: 2h30?
[13:05] <didrocks> or maybe 3 for maguro?
[13:05] <psivaa> didrocks: roughly, if everything goes well without reruns
[13:05] <didrocks> I have all the time needed for running my 15 kms then!
[13:05] <didrocks> see you around guys
[13:09] <popey> https://www.youtube.com/watch?v=zK8nRvf2yAU anyone else get this popup when searching?
[13:09] <popey> I have seen it on other images, so not a regression in #31
[13:12] <rsalveti> morning
[13:12] <didrocks> popey: you are asking for trouble as well :)
[13:12] <popey> I am? oh good.
[13:12] <didrocks> popey: but yeah, seeing it if I reproduce what you are doing, worth a bug IMHO :)
[13:13] <didrocks> come on, launching a search, switching scope
[13:13] <didrocks> knowing how resilient we are :)
[13:13] <didrocks> hey rsalveti
[13:13] <popey> well, i started searching then realised I was on the wrong scope
[13:13] <popey> so swiped and saw the popup
[13:13] <popey> but didn't reproduce it till today
[13:13] <didrocks> popey: oh, so that's not your twisted mind? :)
[13:13] <popey> ☻
[13:14] <ogra_> popey, yes, i see that since forever
[13:20] <popey> ogra_: bug 1255089
[13:20] <rsalveti> ogra_> pressing the power button leaves me with a black screen ... then touching the screen immediately switches it on
[13:20] <ogra_> popey, confirmed
[13:20] <rsalveti> ogra_: is that when charging?
[13:20] <popey> ta
[13:20] <ogra_> rsalveti, nope
[13:21] <ogra_> rsalveti, all the time
[13:21] <rsalveti> ogra_: weird, with 31?
[13:21] <ogra_> yep
[13:21] <rsalveti> probably a unity/mir related issue
[13:21] <ogra_> maguro only
[13:21] <rsalveti> do we have a bug for it already?
[13:21] <rsalveti> oh
[13:21] <ogra_> yeah
[13:21] <ogra_> triaged and all
[13:22] <rsalveti> cool, mind pasting the number?
[13:22] <rsalveti> maybe I can just check Ursinha's nice report
[13:22] <Ursinha> rsalveti, let me upload the updated version
[13:22] <rsalveti> Ursinha: Last updated in Nov. 25, 2013, 11 p.m :-)
[13:22] <rsalveti> Ursinha: yeah
[13:22] <ogra_> rsalveti, bug 1255045 ... a perfect example how small changesets due to more frequent image builds help massively
[13:22] <rsalveti> please
[13:22] <rsalveti> ogra_: yeah
[13:22] <Ursinha> rsalveti, done
[13:23] <ogra_> rsalveti, that would have taken us a day with a twice as big changeset ... but since only Mir and apparmor chaged it was easy to identify
[13:23] <rsalveti> ogra_: cool
[13:23] <rsalveti> Ursinha: thanks, add that a cron, at every 5 minutes :-)
[13:24] <Ursinha> rsalveti, it's in the TODO list, life is happening fast today and still didn't have the time to set this up :)
[13:25] <rsalveti> Ursinha: haha, right :-)
[13:25] <Ursinha> cool, that bug is at the very top of the list :)
[13:27] <rsalveti> didrocks: ogra_: just added phablet-tools to the landing pipeline, please let me know if you need any extra info before moving it to the landing plan
[13:28] <ogra_> k, i'll take care that it lands on the landing plan
[13:28] <rsalveti> thanks!
[13:47] <fginther> morning
[13:55] <davmor2> ogra_, didrocks: Wifi/gsm issue seems to still be in place on a fresh install of r31
[13:56] <ogra_> ouch
[13:56] <davmor2> ogra_: so I just enabled wifi and now I have gsm too
[13:57] <rsalveti> hm, in theory that was fixed with 32
[13:58] <rsalveti> ops
[13:58] <rsalveti> 31
[13:58] <rsalveti> but yeah, just flashed 31 with -b, no signal
[13:58] <rsalveti> crap
[13:58] <davmor2> rsalveti: I'd say not then ;)
[13:59] <rsalveti> at least the keyboard issue is fixed
[13:59] <rsalveti> the loud sound issue :-)
[13:59] <davmor2> ogra_: on a plus side the indicators are back in sync
[13:59] <rsalveti> yeah
[13:59] <ogra_> yep
[13:59] <ogra_> since r30
[14:00] <rsalveti> didrocks: ^
[14:00] <ogra_> he knows :)
[14:00] <Ursinha> didrocks, ogra_, that "GSM not working because wifi is disabled" problem is a regression? it's still happening on r31, I believe that's expected?
[14:00] <rsalveti> it's not
[14:00] <ogra_> its not
[14:00] <Ursinha> not expected or not a regression? :)
[14:01] <ogra_> and yes, it is a regression vs r10 which was the last good one we published
[14:01] <rsalveti> bug 1252737
[14:01]  * Ursinha tags the bug accordingly
[14:01] <davmor2> Ursinha: no it was meant  to be fixed that's why I specifically looked for it
[14:01] <rsalveti> seems didrocks created the workaround
[14:02] <Ursinha> ogra_, do we know the image where the problem started? or it's somewhere between 11 and twenty-something?
[14:03] <Ursinha> I see there's r24 in the bug
[14:04] <rsalveti> Ursinha: seems a change in telepathy-mission-control-5 that caused it
[14:04] <rsalveti> new version was uploaded at nov 13, by seb128
[14:05] <rsalveti> so it's probably around that date
[14:05] <Ursinha> right
[14:05] <Ursinha> don't forget tagging the bug "regression"
[14:08] <ogra_> Ursinha, we had some unbootable and heavily broken images between 20 and 25
[14:08] <ogra_> iirc 26 was the next usable one
[14:08] <Ursinha> :/ I see
[14:10] <davmor2> ogra_: so are you going back to landing update twice daily?
[14:10] <ogra_> davmor2, you mean image builds ?
[14:10] <davmor2> ogra_: yeah sorry
[14:11] <ogra_> davmor2, wel, sounds like the infrastructure can cope with a build every 8h
[14:11] <ogra_> so yes, i would like to switch cron on and have the builds automatic again
[14:11] <ogra_> back to back
[14:12] <davmor2> ogra_: the system might I'm not sure I can though :D
[14:12] <ogra_> you dont need to test every build
[14:12] <ogra_> in the future i would even like us to go to an image every 2h
[14:12] <ogra_> but thats only after we have the infra to copy with that
[14:12] <ogra_> *cope
[14:12] <davmor2> ogra_: haha
[14:13] <ogra_> davmor2, what you should test are the images that look good on the dashboard
[14:13] <ogra_> not just blindly every image
[14:13] <davmor2> ogra_: No blindly is more fun you find way more bugs that way ;)
[14:16] <Ursinha> I have to agree with davmor2 :)
[14:17] <ogra_> well, as you like
[14:17] <ogra_> but you wont be able to test them all :)
[14:17] <davmor2> ogra_: says you :P
[14:18] <ogra_> well, we want to also catch th bugs that only show up after i.e. 10h usage
[14:19] <davmor2> ogra_: No the reason I'm asking is so I can update each morning and run tests etc based on that daily image etc
[14:19] <ogra_> right, you can still do that ... but will miss some builds once we go to a faster frequency
[14:22] <davmor2> ogra_: yeah it's just nice to know that if there is a major breakage I might get a working phone again latter that day which means I can leave it in the broken state and ensure that updates/fresh flash still work :)
[14:23] <fginther> sil2100, can you review: https://code.launchpad.net/~fginther/cupstream2distro-config/add-unity-voice/+merge/196633
[14:25] <fginther> dpm, question about the reminders-app dependencies, how are those dependencies being updated to the PPA?
[14:27] <dpm> hi fginther, thanks for coming back to me on this. For authentication-plugin-evernote, it's built on a daily recipe, for signon-plugin-oauth2, it was a one-off build from a branch, so that we could use it for testing. It's on the pipeline for landing in Trusty, so it will soon not be needed, but I'd like to see if we can keep it in the PPA for the reminders-app developers who are not yet on trusty
[14:28] <fginther> dpm, would it be possible to add a raring package?
[14:29] <fginther> dpm, for all of the core apps, we've been building raring, saucy, and trusty
[14:29] <fginther> dpm, if raring is a no go, we can drop it, but it's a nice to have
[14:29] <sil2100> fginther: yes! Looking!
[14:29] <dpm> fginther, sure, I think it shouldn't be a problem. The account plugin should not be a problem in terms of dependencies, I'll just need to check for signon-plugin-oauth2
[14:30] <sil2100> fginther: oh, unity-voice is back? :)
[14:30] <fginther> dpm, I noticed that signon-plugin-oauth2 didn't build for i386/saucy
[14:30] <fginther> in the ppa
[14:30] <fginther> sil2100, it was requested by pete woods
[14:30] <sil2100> fginther: I remember we had it in the past, but IIRC it was removed because it was just a fallback in the past
[14:30] <sil2100> fginther: ok!
[14:30] <sil2100> fginther: approving
[14:30] <fginther> sil2100, thanks
[14:31] <dpm> fginther, hm, let me check. I'm using that package on saucy now
[14:31] <psivaa> didrocks: ogra_: sil2100: not sure if messaging app test failure is on the radar, looks to have started on r29.
[14:31] <psivaa> http://ci.ubuntu.com/smokeng/trusty/touch/mako/29:20131125:20131125/5091/messaging-app-autopilot/526645/
[14:31] <ogra_> ah, thats bad
[14:31]  * ogra_ didnt notice them due to being distracted by all that other stuff 
[14:32] <psivaa> the same with me :(
[14:32] <sil2100> fginther: while we're at such things: https://code.launchpad.net/~sil2100/unity-scopes-api/enable_unity-scopes-api/+merge/196724
[14:33] <dpm> fginther, looking here it seems it built? -> https://code.launchpad.net/~ubuntu-touch-coreapps-drivers/+recipe/account-plugin-evernote-daily
[14:33] <sil2100> fginther: could you review as well? :)
[14:33] <dpm> fginther, sorry, wrong package
[14:34] <fginther> dpm, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5234666
[14:34] <fginther> sil2100, looking
[14:40] <sergiusens> fginther, I can't seem to get any of these guys online http://s-jenkins.ubuntu-ci:8080/label/saucy/?
[14:46] <dpm> fginther, no idea why the build failed for signon-plugin-oauth2-daily i386/saucy, as there appears to be no build log. In any case, I've requested builds for raring now, and a new build for signon-plugin-oauth2-daily i386/saucy
[14:46] <fginther> sil2100, I think you selected the wrong target for that MP
[14:46] <fginther> dpm, thanks, I'll have the job config updated shortly to add the ppa
[14:47] <fginther> sergiusens, looking
[14:47] <dpm> awesome, thanks fginther!
[14:51] <sil2100> fginther: oh shit, how is that possible ;/
[14:51] <sil2100> fginther: aargh!
[14:51] <sil2100> fginther: ok, I think all this context switching just makes me go bonkers ;)
[14:53] <sil2100> fginther: https://code.launchpad.net/~sil2100/cupstream2distro-config/enable_unity-scopes-api/+merge/196729 <- here please!
[14:59] <didrocks> rsalveti: ack on phablet-flash
[15:06] <sergiusens> fginther, fwiw I can't get new click apps built until that is fixed
[15:07] <cjohnston> sergiusens: we are in a meeting, what can I attempt to help you with
[15:08] <sergiusens> cjohnston, none of these come up http://s-jenkins.ubuntu-ci:8080/label/saucy/?
[15:08] <cjohnston> the nodes I assume?
[15:08] <sergiusens> yup
[15:09] <fginther> sergiusens, ack, there's something broken with the libvirt connections
[15:10] <fginther> sergiusens, the pieces are working, but jenkins can't talk to it for some reason
[15:13] <awe_> didrocks, ping
[15:13] <cjohnston> awe_: he's also in a meeting
[15:13] <awe_> ah, ok
[15:14] <didrocks> awe_: pong
[15:14] <didrocks> awe_: yeah, I'm lost why the dummy workaround worked for popey and I
[15:14] <didrocks> and not for other it seems
[15:14] <awe_> dummy workaround?
[15:15] <awe_> you mean the GSM/Wi-Fi bug?
[15:15] <awe_> didrocks, ping me when you're done with your meeting
[15:16] <didrocks> awe_: right, I tried that (while pinging upstream to get the real fix): http://launchpadlibrarian.net/157638860/telepathy-mission-control-5_1%3A5.16.0-1ubuntu1_1%3A5.16.0-1ubuntu2.diff.gz
[15:17] <dpm> fginther, re: reminders-app again, I'm trying to figure out why signon-plugin-oauth2 i386/saucy cannot be uploaded to the PPA, but after trying to build raring packages, it looks like both (signon-plugin-oauth2, account-plugin-evernote) have dependencies not available on raring. Rather than spending too much time on getting those dependencies backported to raring on the PPA, I think for now it might be best to just drop raring packages from the Jenkins
[15:17] <dpm>  reminders-app jobs, what do you think?
[15:17] <awe_> didrocks, the Wi-Fi portion of the bug has nothing to do with it
[15:17] <awe_> didrocks, apparently the settings changed, so telepathy-ofono doesn't activate the modem automatically
[15:18] <fginther> dpm, that's acceptable, we'll just drop the raring build
[15:18] <didrocks> awe_: yeah, and it doesn't pick when you set it to false at reboot
[15:18] <awe_> my guess is that when WiFi is activated NM onlines the modem
[15:18] <dpm> ok, thanks fginther
[15:18] <didrocks> awe_: hence my patch?
[15:18] <didrocks> to ignore again the connection
[15:19] <awe_> yea, it seems like the inverse of what should happen, but if that's what tiago told us to change, +1
[15:19] <awe_> I've never really looked too deeply at the telepathy code
[15:21] <awe_> didrocks, that said, just read tiago's latest comment, so it's a bit clearer now
[15:22] <didrocks> one sec :)
[15:22] <awe_> np
[15:23] <rsalveti> didrocks: your patch didn't fix it
[15:23] <rsalveti> just flash 31 with -b and you'll see :-)
[15:24] <didrocks> awe_: oh, the correct value is set during startup
[15:24] <rsalveti> it'll be off-line after boot
[15:24] <ogra_> rsalveti, it was a dummy patch :P
[15:24] <didrocks> rsalveti: well, I installed my package and popey confirmed as well…
[15:24] <didrocks> but ok, not sure what happens, so, let's take upstream patch
[15:24] <didrocks> seb128: are you doing it or want me?
[15:25] <seb128> didrocks, I can do it
[15:25] <robotfuel> retoaded: ping
[15:25] <didrocks> seb128: please :)
[15:25] <seb128> didrocks, doing ;-)
[15:25] <seb128> didrocks, yw!
[15:25] <retoaded> robotfuel, pong
[15:25] <awe_> didrocks, hey so my original ping was about an email I sent awhile back about the ofono bug list, and how I get permission to assign bugs, change importance, ...
[15:26] <rsalveti> didrocks: right, but did you remove all your nm connections and rebooted?
[15:26] <awe_> I've been working on cleaning up the bug list, and my abilities are a bit limited
[15:26] <didrocks> rsalveti: well, I stopped wifi
[15:26] <robotfuel> retoaded: the systems that m-jenkins was running tests on don't seem to have dns names
[15:26] <didrocks> and rebooted
[15:26] <robotfuel> retoaded: like ps-intel-3000
[15:26] <rsalveti> didrocks: so it might have half-fixed the issue
[15:27] <didrocks> rsalveti: yeah, seems so
[15:27] <awe_> didrocks, did you read tiago's latest comment?
[15:27] <didrocks> awe_: in the downstream bugs?
[15:27] <awe_> ofono (Ubuntu)
[15:27] <didrocks> awe_: hum, I need to find who can now subscribe you to the right team
[15:27] <awe_> ok
[15:27] <robotfuel> retoaded: unless cobbler needs to be updated to ps-intel-3000.ubuntu-ci?
[15:27] <didrocks> awe_: looking for it, will ping you back (probably tomorrow)
[15:28] <awe_> thanks!
[15:28] <retoaded> robotfuel, are you talking about the system itself doesn't have the correct hostname because it resolves in DNS for me.
[15:31] <robotfuel> retoaded: maybe I read the logs incorrectly http://m-jenkins.ubuntu-ci:8080/job/nexuiz-benchmark-trusty-ps-nvidia-gt440-le-xmir/19/console
[15:39] <retoaded> robotfuel, reading thru the output now. Also need to check in on the cobbler instance on m-jenkins.
[15:51] <retoaded> robotfuel, it appears that cobbler wasn't reconfigured to work with the hosting server's new IP address. that has been resolved and it is functioning now.
[15:52] <robotfuel> retoaded: \o/ thanks!!
[15:52] <retoaded> robotfuel, rerun one of the tests and let me know if it fails
[15:56] <robotfuel> retoaded: will do thanks
[15:59] <dpm> fginther, re:reminders-app PPA dependencies signon-plugin-oauth2 is now built for all arches, so I think we're good to go to drop raring from the reminders-app Jenkins jobs and to add the core apps PPA to the Jenkins set up. Let me know if that's all you need or if I can do anything else on my side
[16:04] <fginther> psivaa, Can you review this: https://code.launchpad.net/~fginther/cupstream2distro-config/reminders-app-deps/+merge/196741
[16:04] <psivaa> fginther: 1 sec
[16:05] <fginther> psivaa, wait 1 moment, I forgot something
[16:05] <psivaa> fginther: ack
[16:05] <doanac> robotfuel, retoaded: let me know how that test works. I suspect the job will still be broken. I don't think UTAH and cobbler are going to work when the cobbler server is located on another physical machine
[16:06] <retoaded> doanac, they were originally (and still are) pointed at a cobbler instance on m-jenkins
[16:08] <doanac> retoaded: correct. utah expected a cobbler to be running locally
[16:08] <doanac> if we point at a remote IP its going to fail for a new different reason
[16:10] <retoaded> doanac, it is running locally; it was running prior to the tests but was still configured with the old IP (I wasn't looking for a cobbler instance on m-jenkins so it didn't get changed) addresses so I changed it to the correct IP.
[16:10] <doanac> retoaded: oh. so the cobbler instance on that host is still going to work?
[16:11] <doanac> ie - it doesn't have to point at cobbler.ubuntu-ci?
[16:11] <fginther> dpm, should be ready soon, then I'll rebuild that job that failed.
[16:12] <retoaded> doanac, it will work on that host much like it did before. It just gets away from centralizing everything.
[16:12] <doanac> ah - that's good news.
[16:12] <dpm> perfect, thanks fginther
[16:17] <psivaa> fginther: let me know when you want me to review the MP for that
[16:18] <fginther> psivaa, I have it updated now: https://code.launchpad.net/~fginther/cupstream2distro-config/reminders-app-deps/+merge/196741
[16:21] <robotfuel> retoaded:  doanac fence_cdu -a "10.97.0.15" has probably changed?
[16:21] <robotfuel> retoaded: doanac it's still failing...
[16:21] <retoaded> robotfuel, most definitely.
[16:23] <psivaa> fginther: approved
[16:23] <doanac> robotfuel, retoaded: i think i need to make a utah sqllite db change for that. let me take a look
[16:23] <retoaded> robotfuel, give me  a little bit and I can track down the new IPs and port names/numbers
[16:23] <doanac> retoaded: share that ip with me and I'll try and update utah
[16:24] <retoaded> doanac, ack. you'll probably wind up needing it for all of the MIR systems correct?
[16:24] <robotfuel> retoaded: yes
[16:24] <retoaded> ack
[16:26] <balloons> sergiusens, how did the landings go for file manager, calendar, and rssreader?
[16:27] <sergiusens> balloons, they didn't, read above about the builders not working ( fginther was dealing with it)
[16:27] <balloons> sergiusens, ack, ty
[16:28] <sergiusens> balloons, I'll keep you posted
[16:42] <didrocks> psivaa: thanks for relaunching notes-app :)
[16:43] <psivaa> didrocks: that was plars actually :), sorry got distracted. still looking at what might have caused the messaging app regression
[16:43] <plars> didrocks: I'm happy to see the crash got fixed
[16:43] <plars> didrocks: trying to get the numbers a bit better
[16:44] <psivaa> plars: not sure you've noticed, messaging app has a regression starting from image 29
[16:44] <psivaa> on mako
[16:45] <plars> psivaa: yes, it looks like it added a test too
[16:47] <psivaa> plars: the failure looks like something related to uitoolkit but the uitoolkit new package landed only with image 30
[16:49] <didrocks> thanks plars!
[16:49] <didrocks> plars: yeah ;)
[16:49] <didrocks> psivaa: what regression on messaging app?
[16:49] <didrocks> only the tests?
[16:50] <psivaa> didrocks: http://ci.ubuntu.com/smokeng/trusty/touch/mako/31:20131126.1:20131126/5115/messaging-app-autopilot/529644/
[16:52] <psivaa> i dont see no change in ui-toolkit neither in AP between image 28 and 29
[16:52] <psivaa> neither in messaging
[16:52] <psivaa> s/i dont see no/i dont see any
[16:53] <plars> didrocks, psivaa: maguro doesn't run that test
[16:53] <plars> maguro only runs 1 autopilot test, I guess the others are skipped for maguro
[16:53] <psivaa> plars: on maguro those connected tests are intentionally skipped
[16:54] <psivaa> plars: http://bazaar.launchpad.net/~phablet-team/messaging-app/trunk/view/head:/tests/autopilot/messaging_app/tests/test_messaging.py#L39
[16:54] <psivaa> the reason is interesting :)
[16:58] <didrocks> plars: I wonder if it's a flacky one
[16:58] <didrocks> roh
[16:58] <plars> didrocks: apparently it caused unity crashes?
[16:58] <didrocks> yeah, something for jfunk_'s team ^
[16:58] <didrocks> for maguro
[16:58] <didrocks> well, it's a bug that should be referenced
[16:59] <didrocks> bfiller: do you know about it? ^
[16:59] <plars> apparently pitti added that?
[17:00] <didrocks> plars: notes-app seem to be blocked
[17:00] <bfiller> didrocks: I don't know about tat
[17:00] <plars> didrocks: I think notes-app is stuck on mako, it's about to timeout
[17:01] <didrocks> plars: yeah, can we retry retry retry it? :)
[17:01] <plars> didrocks: yes
[17:01] <didrocks> thanks!
[17:01] <didrocks> cyphermox: kenvandine: robru: joining?
[17:10] <plars> balloons: do you know who's looking at the calendar app fixes? http://q-jenkins:8080/job/trusty-touch-mako-smoke-calendar-app-autopilot/
[17:11] <balloons> plars, in a meeting, sorry. but new fixes are intending to land asap
[17:12] <plars> balloons: cool, would be nice to see them working again :)
[17:13] <balloons> plars, indeed. fixes for fm and rss reader are on tap too
[17:16] <didrocks> ogra_: tell me whenever you are free
[17:18] <fginther> sergiusens, the VMs are working again, can you retrigger those jobs?
[17:21] <sergiusens> fginther, thanks, let me check
[17:22] <rsalveti> didrocks: ogra_: can we spin another image now that the telephony-mission fix is in place?
[17:22] <didrocks> rsalveti: I was waiting on talking to ogra_ for that, but yeah, +1
[17:22] <ogra_> rsalveti, if didrocks doesnt wait for anything else
[17:23] <didrocks> rsalveti: don't want to spoil my talk to ogra_ but basically, the plan is:
[17:23] <ogra_> didrocks, we're almost done with this meeting, i'll swap over
[17:23] <didrocks> - promote #31
[17:23] <didrocks> - promote #32 during my night if the test results are good
[17:24] <ogra_> oh, you are already done with the call ?
[17:24]  * ogra_ sees an empty hangout
[17:24] <ogra_> didrocks, lets leave the promotion for tomorrow morning
[17:25] <ogra_> (of r32)
[17:25] <didrocks> ogra_: coming in the hangout
[17:25] <didrocks> easier to talk :)
[17:26] <robru> didrocks, ugh, sorry for missing the meeting, seems my alarm didn't go off :-/
[17:27] <didrocks> robru: you can sync with ken
[17:38] <kenvandine> just did :)
[17:39] <rsalveti> I'd just trigger 32 and see if we can promote it later today
[17:39] <rsalveti> should be as good as 31 and with the telephony-mission issue fixued
[17:41] <didrocks> rsalveti: yeah, ogra_ is still going to promote 31 meanwhile, it's still better than 28
[17:42] <didrocks> for 32, I think ogra_ wants to wait tomorrow morning (EU time)
[17:42] <ogra_> right
[17:42] <didrocks> so that we have more dogfooding
[17:42] <ogra_> get some more dofooder feedback
[17:42] <ogra_> *dog
[17:42] <rsalveti> right, that's fine
[17:42] <rsalveti> go for it
[17:43] <didrocks> ogra_: email sent FYI
[17:43] <ogra_> promotion running ...
[17:43] <ogra_> (takes a few mins)
[17:43] <didrocks> well, time for launchpad to treat the mail in the ML queue :)
[17:45] <ogra_> done
[17:46] <ogra_> [17:49] <Ursinha> ogra_, alright :D
[17:51] <didrocks> \o/
[17:55] <jdstrand> didrocks: hey, I've not been upgrading my phone cause of the gsm issue. if I upgrade to 31, will the workaround give me phone if I have to reboot while I am away from wifi?
[17:56]  * jdstrand doesn't want to get in a situation where there is an emergency and can't make the call
[17:56] <jdstrand> the way I understand the telephony workaround, it should, but I'd like confirmation
[17:57] <didrocks> jdstrand: depends, seems that 32 will really fix it, my workaround only fixed it for me and popey
[17:57] <didrocks> jdstrand: so better for you to wait on 32
[17:57] <jdstrand> hmm, ok
[17:57] <jdstrand> thanks
[17:58] <jdstrand> I'm not sure how it would be instrumented, but a test case for gsm after reboot would be a good thing :)
[18:40] <doanac> robotfuel: i got the CDU information for the mir job. I'm going to create a one-off test to see if things work now
[18:41] <robotfuel> doanac: ack
[18:41] <fginther> sergiusens, is the click app building working now?
[18:41] <doanac> retoaded: can you make me a jenkins admin on m-jenkins?
[18:45] <robotfuel> doanac: you are now
[18:45] <doanac> excellent.
[18:48] <sergiusens> fginther, yes, triggered them a couple minutes ago, seems to build fine now
[18:48] <sergiusens> thanks
[18:51] <doanac> robotfuel: it failed on first run. i've got to dig around into configs to figure out what's missing. i'll let you know once its sorted out
[18:58] <slangasek> ev: bug #1235436
[18:59]  * ev nods
[19:27] <robotfuel> fginther: ping
[19:27] <fginther> robotfuel, hey
[19:28] <robotfuel> fginther: I have a new project I need to build in CI what node should I use? (qtpim-opensource-src) it's the contacts for the platform api
[19:30] <fginther> robotfuel, is that a launchpad project?
[19:31] <fginther> oh looks git-ish
[19:31] <robotfuel> fginther: yeah it's from git
[19:31] <robotfuel> apt-get source qtpim-opensource-src is the way do get it currently
[19:33] <fginther> robotfuel, I have some questions, can you do a hangout?
[19:33] <robotfuel> fginther: sure
[19:34] <robotfuel> fginther: https://plus.google.com/hangouts/_/7acpi7bt2fmhvtj786qguphs60?authuser=0&hl=en
[20:26] <doanac> robotfuel: ps-nvidia-gt440-le is now working with a basic utah job: http://m-jenkins.ubuntu-ci:8080/job/tmp-andy-xmir/5/consoleFull
[20:26] <doanac> i didn't try your test or preseed.
[20:27] <doanac> and I think ps-nvidia-gt440-le  is going to be working also: http://m-jenkins.ubuntu-ci:8080/job/tmp-andy-xmir/6/console
[20:27] <doanac> i'll start on all the others now
[20:27] <robotfuel> doanac: thanks, it should work now I'll kick off a build on ps-nvidia-gt440-le
[20:28] <doanac> robotfuel: hold of on gt440 i'm finishing a job on that
[20:28] <robotfuel> doanac: ok
[20:32] <doanac> robotfuel: gt440 is ready now
[20:45] <doanac> robotfuel: ps-nvidia-310 http://m-jenkins.ubuntu-ci:8080/job/tmp-andy-xmir/8/console is working
[21:44] <rsalveti> ogra_: popey: another bug which is probably a regression 1253810
[21:44] <rsalveti> bug 1253810
[21:49] <popey> rsalveti: yeah, not seen that before
[21:54] <vila> rsalveti: I've seen that for quite some time but only the indications area
[21:55] <rsalveti> yeah, seems to happen only in the indicator
[21:55] <rsalveti> I'm able to reproduce it easily today though
[21:55] <rsalveti> received 10 sms, got the issue 4 times
[21:55] <rsalveti> the timestamp is also quite interesting
[21:56] <vila> rsalveti: great. Mentioning it so you don't focus on recent changes, it's a shy but old one ;)
[21:56] <vila> rsalveti: epoch ?
[21:56] <rsalveti> well, why would it be 00:00 Jan 01
[21:56] <rsalveti> let me test with mup
[21:56] <Ursinha> and in mine it's 3 hours before (21PM 31 Dec)
[21:57] <Ursinha> as my phone is set to brazilian timezone
[21:57] <Ursinha> (it should be -2 but well)
[21:58] <vila> Ursinha: you lag :-p
[21:58] <Ursinha> haha
[21:59] <rsalveti> the timestamp and the order is fine in the messaging app
[21:59] <Ursinha> yes, it's only in the indicator area
[21:59] <vila> rsalveti: yeah, I thought I had dreamed the first few times
[21:59] <Ursinha> all the 98 times that happened to me I checked
[22:00] <cjohnston> vila: shouldn't you be in bed? :-P
[22:00] <vila> rsalveti: by the way, what needs to be backed up to preserve those messages ?
[22:01] <vila> cjohnston: yeah, I should ;)
[22:01]  * cjohnston pulls vila's internet
[22:02] <vila> cjohnston: .shhhhhhh, <mutter> not so loud, my ISP's modem/infra is quite... susceptible these days </mutter>
[22:02] <rsalveti> vila: not sure
[22:02] <rsalveti> but yeah, message from ofono is correct, so is the one in the messaging app
[22:03] <rsalveti> indeed a bug in the indicator
[22:03] <rsalveti> but don't know how to dump the info contained in there
[22:03] <vila> rsalveti: is this the kind of test you're working on (I've heard you were working on some but no details :-})
[22:04] <rsalveti> vila: we're working on adding a few test cases for ofono
[22:04] <rsalveti> which would not help much in this case
[22:05] <vila> rsalveti: even as a way to provide inputs to the messaging app ?
[22:05] <vila> rsalveti: I have a rather flexible view about tests ;)
[22:05] <rsalveti> vila: well, that can already be done with the ofono phonesim, which pitti was working on
[22:06] <rsalveti> like simulating a bunch of sms messages
[22:06] <balloons> sergiusens, rssreader works fine for me
[22:06] <rsalveti> might be indeed a good thing to add
[22:06] <vila> rsalveti: ha, right, that ! That's what I wasn't sure who was working on
[22:06] <dobey> fginther: ping
[22:06] <balloons> sergiusens, I did get the errors with file manager. I guess the non-tablet layout is different enough to cause it to be failing for some reason (or the app has a bug in non-tablet form)
[22:07] <fginther> dobey, pong
[22:07] <vila> rsalveti: so if pitti hears about that, the bug should be worried ;)
[22:07] <dobey> fginther: hey. have a question about versioning wrt moving a project to daily-releases off trunk, and not sure what to do about it
[22:08] <fginther> dobey, I can try to help
[22:08] <rsalveti> vila: yeah :-)
[22:09] <fginther> dobey, what's the project?
[22:09] <dobey> fginther: as we were previously doing our releases as tarballs, and off a stable branch that we cherry-picked changes into for the release, the trunk version was always higher than the release versions. to avoid having to bump it all the time (and not knowing that we would have to change our releases process and be subsumed into UE), the versions on our trunks were bumped to 99.12, so that nightlies would always be newer, and 
[22:11] <dobey> fginther: but we don't want to use "99.12" as the version for actual releases into ubuntu, so if we're going to daily-release it, we need to make it sensible. is there anything i can do to force and upgrade, that doesn't require an epoch, that you know of? or should i just not worry about upgrading for people who were using the previous nightlies PPA (and subsequently, remove these projects from being built in that PPA)
[22:12] <fginther> dobey, thinking...
[22:18] <fginther> dobey, An alternative would be to use the stable branch as the branch consumed by daily-release and continue using the trunk as you do today.
[22:20] <dobey> i don't think we'd want to do that, though
[22:20] <fginther> dobey, but to directly answer your question, apt upgrades only work when the version is higher, so you would need an epoch to go from 99.X to 1.Y
[22:21] <dobey> seems like that would make things more complex
[22:21] <fginther> dobey, how many users are using the PPA?
[22:22] <fginther> if the answer is "lots" it's going to be hard to ignore upgrading them
[22:22] <sergiusens> balloons, it is rather different, yes
[22:23] <sergiusens> balloons, if rssreader works fine for you, I'll push to the store and get popey to review when he's avail
[22:23] <popey> I am available
[22:23] <balloons> a wild popey appears!
[22:23] <sergiusens> balloons, one improvement on that one would be to add something like the notes app so it doesn't go out to the network (localhost in test server)
[22:23] <dobey> fginther: no idea
[22:23] <balloons> yes, that is an open bug and a point of much discussion sergiusens
[22:24] <balloons> thomi is actually looking at it
[22:24] <dobey> fginther: for ubuntuone-credentials it probably doesn't much matter, as it's not really useful outside the phone image right now
[22:24] <balloons> we want to remove external servers from all the tests
[22:25] <sergiusens> balloons, oh, goodie :-)
[22:26] <fginther> dobey, for that, I agree, an upgrade path from the PPA to the release doesn't sound necessary
[22:26] <sergiusens> popey, https://myapps.developer.ubuntu.com/dev/click-apps/155/changerequest/
[22:26] <popey> ok
[22:26] <sergiusens> popey, also notice that the changelogs are working now :-)
[22:27] <dobey> fginther: ubuntuone-client-data is of slightly more concern, as other things use it as well
[22:27] <popey> done that one
[22:27] <dobey> fginther: yeah, i'm more wondering about upgrading from this PPA to the daily-release PPA, for example
[22:27] <dobey> fginther: we clearly don't support upgrades from the nightlies PPA to release, already. nor to the beta/stable PPAs we have
[22:31] <fginther> dobey, in that case, I personally wouldn't have much concern. The daily-release PPA packages are copied to the archive, so upgrading to the PPA would be the same as upgrading to the release
[22:32] <fginther> dobey, I recommend talking to didrocks, he understands the package versioning nuances much better then I
[22:34] <dobey> sure. i probably do too. just needed to vent it to someone who understands the CI/daily-release stuff, so i can have a better idea of what i need to do. and you're around :)
[22:35] <fginther> dobey, no problem
[22:38] <dobey> thanks
[22:42] <dobey> is there any standard practice for bumpting the versions in a daily-release project? such as bumpting to the target ubuntu release version when the new cycle starts and CI is transitioned to manage trunk on it?
[22:42] <dobey> or does everyone just do "0.1" as a version now, and just rely on daily-release appending the datestamp and such?
[22:43] <fginther> dobey, https://wiki.ubuntu.com/DailyRelease/InlinePackaging
[22:43] <fginther> dobey, looks like just a "dch -i"
[22:43] <fginther> Bump the version number one minor version, a la x.y.z+1-0ubuntu1
[22:45] <dobey> but dch -i would just make that be 0ubuntu2
[22:45] <dobey> and in-line packaging shouldn't have 0ubuntu1 at all
[22:45] <dobey> since they are native packages
[22:45] <fginther> dobey, sorry, I got ahead of myself. the real instruction is to just update the minor version
[22:49] <fginther> dobey, I can't argue the native, non-native point. It may just be for historical purposes
[22:49] <dobey> fginther: but that page seems to also only deal with initial setup, and not ongoing maintenance. ie, if my package is version 0.1 now, what should i change it to in 6 months for the next version of ubuntu?
[22:51] <fginther> dobey, looking for the specific documentation, ll of the daily release docs are here https://wiki.ubuntu.com/DailyRelease/
[22:52] <dobey> fginther: right. i'm presuming there isn't any documentation about this, as the currently daily-released packages don't seem to have any real consistency there :-/
[22:53] <fginther> dobey, I think more specific info is here: https://wiki.ubuntu.com/DailyRelease/FAQ#Versionning_scheme
[22:54] <dobey> fginther: and that seems to be about the content that is appended to the upstream version, rather than maintaining the upstream version number itself
[22:56] <dobey> well, "dpkg -l|grep 13.10" certainly shows a very wide range of version numbers :-/
[22:58] <fginther> dobey, why wouldn't it? Every upstream has it's own version history, these aren't reset just to apply daily-release
[22:59] <fginther> dobey, https://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Diverging_.22trunk.22_and_a_.22maintenance.22_branch discusses more specifically creating a maintainence branch, but it also gets into the gory details of updating the daily-release configuration
[23:00] <fginther> in general, a maintenance branch is created when the release transition takes place, naming is up to the upstream team itself but most use 'lp:foo/saucy' or 'lp:foo/13.10'
[23:01] <popey> i seem to be able to reboot my phone by running alsamixer
[23:01] <popey> oof, ubuntu-bug reboots phone too
[23:01] <popey> this seems very broken
[23:02] <dobey> fginther: right, but i'm not asking about creating maintenance branches
[23:03] <dobey> fginther: i'm talking specifically about updating the version number in trunk, after the maintenance branch has been created, and focus has moved to the new development version of ubuntu
[23:06] <dobey> https://launchpad.net/ubuntu/+source/libappindicator for example shows libappindicator has been 12.10.1 since raring, and was 12.10.0 in quantal
[23:07] <Kaleo> robru, can we get a release of the toolkit again? :)
[23:07] <dobey> seems like best practice would be to match the upstream version to the targeted ubuntu version
[23:08] <Kaleo> robru, it fixes critical regression https://bugs.launchpad.net/bugs/1254888
[23:08] <fginther> dobey, AIUI, daily-release doesn't care about the upstream version, it should continue to be maintained as needed by the upstream team
[23:09] <dobey> fginther: right. but i'd expect there to be some clear recommendation of what people should do, when their project is on daily release. instead the practice seems to be "switch to daily release and never bother touching the version number again" :-/
[23:11] <dobey> just found https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_bumping_the_upstream_version.2C_what_should_I_do.3F which doesn't really answer either, and advises some other bad behavior
[23:11] <dobey> maybe i'll just ping didrocks in the morning and complain and we can get it fixed and have a sane recommendation, and hopefully get people to follow it
[23:12] <fginther> dobey, sorry I can't be of much help
[23:14] <dobey> no worries
[23:14] <dobey> thanks :)
[23:14] <fginther> dobey, good luck :-)
[23:14] <dobey> time for me to get off the computer anyway. later :)