[01:16] <bfiller> robru: you still around?
[01:17] <robru> bfiller, I can be, for a small price ;-)
[01:17] <robru> bfiller, just kidding, what's up?
[01:17] <bfiller> robru: haha :)
[01:18] <bfiller> robru: on silo 8 the MR for address-book-app looks like it was included but for some reason a new versions didn't get pushed to the ppa
[01:18] <robru> hmmm
[01:18] <robru> bfiller, oh is it a no-change rebuild?
[01:18] <bfiller> robru: was basically a dummy MR just to force a rebuild but didn't have any real changes
[01:18] <bfiller> robru: yes
[01:18] <robru> right
[01:18] <robru> ok, i saw the same thing earlier today, there seems to be a new bug that makes no-change rebuilds not get uploaded. i can make it go by forcing it through, one sec
[01:19] <bfiller> ok cool
[01:20] <robru> bfiller, yeah, here we go: https://ci-train.ubuntu.com/job/landing-008-1-build/68/console for future reference I think it's now necessary to check the 'FORCE_BUILD' option when doing no-change rebuilds.
[01:20] <bfiller> robru: got it, thanks
[01:21] <robru> sergiusens, doanac hey what ever happened in silo 3? how did that ci run go? anything i can do to help?
[02:09] <imgbot> [02:41] <sergiusens> robru: I think we are good http://q-jenkins.ubuntu-ci:8080/job/andy-smoke-daily-test/14/console
[02:41] <sergiusens> robru: nothing tool wise broke, so I'm setting testing to done; those test take 4 hours to run btw :-P
[02:42] <robru> sergiusens, sweet, I'll publish it ;-)
[02:58] <plars> thomi: phablet-click-test-setup pulls the branch location and revno by looking at the click package manifest
[02:58] <plars> thomi: also, I had a question for you
[02:58] <thomi> plars: I figured it out in the end, thanks tho :)
[02:58] <thomi> plars: shoot
[02:58] <plars> thomi: hit a very strange subunit2junitxml/autopilot issue recently
[02:58] <plars> thomi: http://q-jenkins.ubuntu-ci:8080/view/Touch/view/Ubuntu%20Touch%20Smoke/job/utopic-touch-flo-smoke-daily/57/console
[02:59] <plars> thomi: or for the pastebin of the interesting bits...
[02:59] <plars> thomi: scroll down to the bottom of: http://paste.ubuntu.com/7463064/
[02:59] <thomi> oooh
[02:59] <thomi> tasty traceback :)
[02:59] <plars> thomi: fortunately it seems to be pretty rare
[03:00] <plars> thomi: but it was slightly annoying since the test had clearly run and produced results, but we couldn't get at them since they didn't convert correctly
[03:00] <thomi> plars: are you able to link me to the subunit file that caused this? is it stuill around?
[03:00] <plars> thomi: yep, I was just digging it out
[03:00] <plars> one sec
[03:01] <plars> thomi: you can pull it from https://jenkins.qa.ubuntu.com/job/utopic-touch-flo-smoke-daily/57/artifact/clientlogs/ubuntu_clock_app/
[03:01] <thomi> plars: and what's the command line you use when running it through subunit2xml?
[03:02] <thomi> hmnmm, it seems to parse it OK for me
[03:03] <plars> thomi: cat ${odir}/test_results.subunit | subunit2junitxml > ${odir}/test_results.xml
[03:03] <thomi> huh
[03:03] <plars> thomi: that's from the script, odir is the output dir
[03:03] <thomi> sure
[03:03] <thomi> I notice that there's some non-subunit-related binary data in the stream, I wonder where that comes from
[03:04] <thomi> plars: I'll talk to lifeless and see what he things
[03:04] <thomi> *thinks
[03:04] <plars> thomi: cool. thanks
[03:05] <thomi> no worries
[03:44] <thomi> plars: still around?
[03:44] <thomi> plars: if so, are you able to tell me what the locale env vars for the machine that crashed are?
[03:48] <Mirv> morning
[03:52] <Mirv> oh hi robru :)
[03:52] <robru> Mirv, hey what's up?
[03:52] <Mirv> I wonder if any core dev is around at this hour
[03:52] <Mirv> robru: just clicking on the same publish
[03:53] <robru> Mirv, oh, funny
[03:53] <robru> Mirv, actually that packaging change was done by ken, he's core dev, so basically auto-approve
[03:53] <robru> Mirv, wow, is it 9PM already? i should sign off ;-)
[03:54] <Mirv> robru: you're correct, it's ok to publish then
[03:54] <Mirv> robru: maybe :)
[03:54] <robru> Mirv, alright, I leave the rest of it in your hands... good night!
[03:54] <Mirv> good night!
[03:56] <Mirv> I think I'll try if I can test the gallery app click package myself and upload
[03:58] <bzoltan1> Mirv: ping
[03:59] <Mirv> bzoltan1: I was pinged already, if I guess correctly
[03:59] <bzoltan1> Mirv:  Yes, sorry for double ping
[04:00] <Mirv> no prob, you have landing-019, and it must be magically good since it was allocated at 04:00:00 according to jenkins
[04:46] <bzoltan1> Mirv: The Silo9 is done with the build. I have tested the package on my desktop and the ubuntu-sdk.desktop file is back in business
[04:46] <bzoltan1> Mirv: let's ask pitti to ack it when he arrives
[04:47] <Mirv> yep, the link is https://ci-train.ubuntu.com/job/landing-019-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.10.20140516-0ubuntu1.diff
[05:35] <bzoltan1> Mirv: do you know anybody form the west coast who might be still active for an ack on that package?
[05:36] <Mirv> bzoltan1: pitti seems now active on #ubuntu-devel
[05:49] <bzoltan1> Mirv:  I pinged him. How can I see that he acked?
[05:50] <Mirv> bzoltan1: by the way that he said "it's fine". publishing.
[06:07] <bzoltan> Mirv: cool
[06:26] <bzoltan> Mirv:  will the she-hoo-hoo ping me if the package is blocked on some black magic?
[06:45] <Mirv> bzoltan: well the choo choo already told that the packages are migrating, I think its visibility stops about there
[06:46] <Mirv> bzoltan: it's migrating to release pocket alright https://launchpad.net/ubuntu/utopic/+source/qtcreator-plugin-ubuntu/3.0.1+14.10.20140516-0ubuntu1
[06:46] <Mirv> so in 15 minutes or so it's available for all
[06:48] <bzoltan1> Mirv:  Of course ... thanks
[06:54] <Mirv> dbarth: just tell which landing you want first, there are so many and so few silos that maybe best to proceed one at a time
[06:55] <Mirv> (and well landing-018 is already there)
[06:55] <bzoltan1> Mirv: I am cleaning up teh silo19, so that will be back at your disposal soon
[06:56] <Mirv> bzoltan1: yeah, but I wouldn't like to give 1/3 of the silos to dbarth alone :)
[06:57] <bzoltan1> Mirv:  is there a protocol or policy to bribe the CI Train? :D
[06:59] <Mirv> naturally it's all non-formal and not admitted :)
[07:00]  * bzoltan1 has still a lot to learn :)
[07:08] <dbarth> hi
[07:09] <dbarth> Mirv: "all you silos are belong to us" ;)
[07:09] <dbarth> so yeah, let me streamline that
[07:19] <mardy> asac: hi! In case you are still not convinced that keeping trunk in sync with what's in the archive is a bad idea, have a look here: https://code.launchpad.net/~mir-team/mir/utopic
[07:20] <mardy> asac: teams are resorting to develop on other branches ("staging", "development", "master"), and then making a MP to merge this development branch into trunk
[07:21] <mardy> asac: and in this way the commit history becomes meaningless, we only see huge commits of many different features, with meaningless commit messages
[07:21] <mardy> like http://bazaar.launchpad.net/~mir-team/mir/utopic/revision/1185
[07:22] <sil2100> mardy: right - I'm not a big fan of this approach, UITK uses staging as well but they prepare a full meaningful changelog on new releases, which is good
[07:27] <sil2100> dbarth: hi! I sadly cannot assign any silos for your landings right now :< All the components are already 'locked'
[07:27] <sil2100> dbarth: would be nice if silo 018 could progress!
[07:28] <dbarth> you can remove line 17 as well
[07:29] <dbarth> so i think i cleaned all of our previous landing requests, and merging all of that into one mega OA silo
[07:29] <sil2100> dbarth: ah! Missed the comment there, ok, let me purge it
[07:29] <dbarth> all on line 43
[07:30] <dbarth> ie line 43 is our mega silo
[07:30] <davmor2> sil2100, ogra_: woke up this morning, mako's wifi was turned off, so I guess there is a problem with the wifi somewhere along the lines
[07:30] <dbarth> the rest, i've commented on the individual lines
[07:30] <davmor2> really not here yet so sods off
[07:31] <sil2100> davmor2: hi! Oh, suddenly it turned off without any intervention?
[07:35]  * Mirv archives landed requests, starts to be too much to scroll all the time
[07:35] <sil2100> Mirv: o/
[07:48]  * sil2100 sighs
[07:48] <ogra_> hmm, you might have noticed that image 33 above never resturned a success command .... this is because it never finished building
[07:48] <ogra_> :(
[07:48] <ogra_> (like all other images that were built tonight for all falvours, all arches)
[07:48] <sil2100> I wonder why installing that jenkins plugin takes so much time
[07:48] <sil2100> oh
[07:49] <sil2100> ogra_: infra problems?
[07:51] <ogra_> looks more like a package problem ... see #ubuntu-devel
[07:51] <sil2100> uh
[07:52] <sil2100> And we seem to be having some jenkins issues
[07:52] <ogra_> well, if that uses fresh chroots that might be related
[07:53] <didrocks> sil2100: hum, you are installing it yourself?
[07:53] <sil2100> didrocks: no, I filled an RT, prepared the charm, but webops somehow 'take a long time'
[07:54] <sil2100> didrocks: I poked yesterday late at night even, there was someone looking at it but only assessed the time required
[07:54] <didrocks> ok
[07:54] <sil2100> And there doesn't seem to be anyone around webops right now
[07:54] <didrocks> yeah, what colin told yesterday, nobody in the morning time this week
[08:15] <sil2100> Mirv: what was the result of you yesterday investigation with failing system-settings tests?
[08:28] <Mirv> sil2100: bug #1319711 , but I seem to have missed answering it. so the thing is that I don't see it either, so it's somehow test infra related.
[08:29] <Mirv> I marked it as incomplete now, since really I don't know what to do next about it
[08:29] <Mirv> I'm running it once more now with #32
[08:30] <sil2100> hm, as per Laney's comment, it doesn't seem to be caused by any specific change - it might be flaky, but it failed again on 32
[08:30] <Mirv> popey: if you happen to have bandwidth for app testing, http://s-jenkins.ubuntu-ci:8080/job/gallery-app-click-from-branch/lastSuccessfulBuild/artifact/out/com.ubuntu.gallery_2.9.1.974_armhf.click would be ready and includes the changes bfiller released as .deb earlier
[08:33] <popey> Mirv: sure thing
[08:34] <Mirv> popey: hmm, maybe to apt-get update + dist-upgrade on top of #32 too, since the other components are otherwise not there..
[08:34] <Mirv> s/to/do/
[08:34] <popey> ok
[08:35] <Mirv> "image download support in browser", webbrowser-app, content-hub, address-book-app. I'm not sure if there's anything in there that'd break the new gallery-app if they're not installed, though.
[08:35] <Mirv> maybe content-hub
[08:38] <Mirv> (yep, no failure on #32 either with u-s-s)
[08:42] <Laney> I don't understand why it started failing or why it doesn't happen locally
[08:43] <ogra_> Laney, well, it clearly started when tzdata got updated ... indeed that might be coincidence ...
[08:44] <seb128> do we have video recording of those failing tests?
[08:44] <ogra_> we have a second failure now, also in a tz related test
[08:44] <Laney> you're still stuck on that?
[08:44] <Laney> it'd reproduce locally if it was something like that surely
[08:46] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/32:20140515.2:20140513.2/8044/ubuntu_system_settings/
[08:47] <ogra_> test_searching_tz_not_found and test_manual_tz_selection
[08:48] <ev> sil2100: always a good idea to test things in the cloud first :)
[08:48] <popey> To the cloud!
[08:49] <ev> hahaha
[08:49]  * didrocks still see a nice blue sky here
[08:50] <sil2100> I usually test run it on the ground, but cloud is the future
[08:50] <sil2100> It's raining heavily here
[08:50]  * ogra_ imagines popey standing in front of a red doubledecker with scarf and leather cap when saying that 
[08:50] <popey> I was thinking more an orange box
[08:50] <ogra_> haha
[08:51] <didrocks> popey: nice orange box talk on linux unplugged btw :)
[08:51] <popey> hehe
[08:52]  * didrocks is always under the impression to run/exercise with popey at lunch time
[08:52] <popey> I'd slow you down.
[08:52] <didrocks> ahah ;)
[08:52] <popey> Mirv: testing gallery now, will let you know outcome..
[08:53] <popey> wow, people are actually leaving comments and ratings on apps!
[08:53] <didrocks> oh nice :)
[08:53] <Laney> Mirv: can someone CIish help us determine what's different?
[08:53] <popey> its turning into a bug tracker
[08:53] <Mirv> popey: ok!
[08:53] <didrocks> ah… :(
[08:53] <didrocks> not unsurprising I guess
[08:53] <Mirv> Laney: psivaa possibly...
[08:54] <asac> mardy: thats a visualization problem, no? you can use bzr log --include-merges or something to see the merged revisions
[08:54] <mardy> asac: yes, but launchpad.net doesn't do that
[08:55] <mardy> asac: the problem is that we have all tools built around the idea of "trunk" as development branch
[08:57] <psivaa> Mirv: Laney: i'm taking a look to see if there is on our side interfering but this wasn't failing up until image 28
[08:58] <sil2100> dbarth: regarding line 11 - that's for utopic, right?
[08:58] <Laney> psivaa: yeah, I'm not blaming your side but it's quite hard to determine what changed
[08:58] <Laney> ci.debian.net gives you a nice summary at the start of its output of the differences between subsequent runs :-)
[08:59] <psivaa> Laney: understand
[08:59] <asac> mardy: its quiet normal tools are trailing reality if there is change. biggest mistake one can make is to put oneself into a "tools cage"
[08:59] <Laney> the latest output says it can't find the field
[08:59] <Laney> which is quite curious indeed
[09:00] <Laney> the objectName seems to be there
[09:00] <asac> e.g. make the tools dictate what and how you do things
[09:10] <Laney> ogra_: the autoreport setting should work properly now btw
[09:10] <dbarth> sil2100: nope, that's primarily for 14.04
[09:10] <ogra_> Laney, so i heard ... waiting for the next promotion to test myself :)
[09:10] <sil2100> dbarth: so, you want a silo for 14.04 for that landing, right?
[09:11] <dbarth> sil2100: yes, please
[09:11] <dbarth> this is SRU material as i was putting in the comment box
[09:11] <popey> Mirv: Ran 37 tests in 853.308s
[09:11] <popey> FAILED (failures=2)
[09:11] <Mirv> popey: add_photo is quite normal, what's the other one?
[09:12] <popey> Mirv: http://paste.ubuntu.com/7472056/
[09:12] <ogra_> oh, wow, the filemanager got pretty useless
[09:12] <popey> victor filed a bug for that last night, but i can't reproduce it
[09:13] <ogra_> it allows you to go to / but doesnt display anything
[09:13] <popey> bug 1320032
[09:14] <ogra_> Laney, confirmed ... on my flo i have a lot of .uploaded files :D
[09:14]  * ogra_ hugs Laney ... thanks so much !
[09:14] <ogra_> hmm
[09:15] <ogra_> but tapping on "Previous error reports" does not open the browser with them
[09:15] <sil2100> :)
[09:15] <ogra_> it used to do that a while ago
[09:15] <Mirv> popey: weird output, there's a bunch of "ERROR: gallery_app...":s, one "FAIL: gallery_app...", and then it says two failures at the end
[09:15] <sil2100> Yay!
[09:15] <Mirv> popey: maybe rerun or then we'll just ping bfiller on testing the click package too
[09:16] <popey> Mirv: ok, reboot and re-run
[09:16] <ogra_> Laney,
[09:16] <ogra_> ** (process:2523): WARNING **: Unable to dispatch url 'http://www.ubuntu.com/aboutus/privacypolicy?crashdb':GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'http://www.ubuntu.com/aboutus/privacypolicy?crashdb' is not handleable by the URL Dispatcher
[09:16] <ogra_> want a bug ?
[09:17] <ogra_> hmm, tapping on previous error reports prints actually nothing like i havent tapped
[09:18] <ogra_> *hasnt
[09:18] <Laney> you clicked privacy policy?
[09:18] <Laney> that works for me
[09:20] <ogra_> privacy policy prints the above ... but doesnt open anything
[09:20] <ogra_> previous error reports prints nothing
[09:22] <dholbach> hiya
[09:22] <ogra_> Laney, bug 1320154
[09:22] <dholbach> does anyone know how to fix this? https://code.launchpad.net/~dpm/reminders-app/fix-1317683-update-template/+merge/219669 - does it just need to be re-run?
[09:25] <popey> dholbach: W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ppa.launchpad.net_ubuntu-touch-coreapps-drivers_daily_ubuntu_dists_utopic_main_binary-amd64_Packages  Hash Sum mismatch
[09:25] <popey> looks odd, psivaa may be able to investigate
[09:25] <dholbach> cool, thanks popey and psivaa
[09:25] <popey> looks like network cut during apt-get update
[09:32] <popey> Mirv: Ran 37 tests in 852.997s
[09:32] <popey> FAILED (failures=3)
[09:32] <popey> http://paste.ubuntu.com/7472115/
[09:36] <ogra_> Wellark, do you have a silo for the icon already ?
[09:37] <ogra_> would be nice to have that landed before the next image build
[09:37] <ogra_> (since its so trivial)
[09:43] <Mirv> popey: bah. maybe we need a reassurance from bill before putting it to store then at least.
[09:48] <sil2100> Wellark: are you up already?
[09:58] <psivaa> Mirv: Laney: sil2100: So you might have seen the next run on ubuntu_system_settings has finished all passing.
[09:58] <psivaa> Laney: It does appear to be flaky/ racy when click_tz_search_field being used
[09:58] <Laney> psivaa: that's without any changes?
[09:59] <psivaa> yes. given the fact that rev 702 in ubuntu_system_settings is about improving performance in  tz search, i'd be more inclined to suspect that commit for this flakiness.
[09:59] <Laney> no
[09:59] <psivaa> there is also 'Autopilot test refactoring: add emulators and helpers' in rev700. which includes click_tz_search_field
[10:00] <sil2100> psivaa: thanks for the analysis
[10:00] <Laney> The failures are about autopilot not beingn able to find elements
[10:01] <Laney> It's probably going to be in the tests themselves
[10:01] <Laney> thanks
[10:03] <psivaa> Laney: sil2100: np. sorry, i could not find any other reasons :)
[10:04] <psivaa> popey: i've kicked rebuild on that MP.
[10:24] <Mirv> psivaa: oh! so it's indeed flaky. I've never had a run locally though with success so far.
[10:24] <sil2100> Mirv: you mean, system-settings?
[10:25] <sil2100> didrocks: do you still have your scripts for rolling-back changes easily? ;)
[10:25] <psivaa> Mirv: yea, i dint expect it to pass tbh, but it did :)
[11:31] <didrocks> sil2100: sure, it's in lp:cupstream2distro
[11:32] <didrocks> citrain/manual/reverter
[11:32] <greyback> sil2100: hey, am testing silo17, functional testing works fine, but the autopilot tests are out of date and fail with recent unity8. What's the policy there? We deny landing until AP fixed, or allow?
[11:32] <didrocks> sil2100: you need upload rights though
[11:40] <sil2100> uh!
[11:40] <sil2100> greyback: silo17 you say? I just published it as it was marked 'testing done', ouch
[11:41] <greyback> sil2100: ah, I had added the comment underneath, then came here to ask you. Oww
[11:41] <sil2100> greyback: but it's a keyboard landing so I guess it shouldn't affect unity8 autopilot tests normally? Or how do the tests look?
[11:41] <sil2100> hm
[11:42] <greyback> sil2100: it shouldn't affect unity8 AP tests. OSK test are just out of date, need updating for the new scopes stuff in unity8
[11:42] <sil2100> greyback: how did you do the autopilot testing? It shouldn't all fail
[11:42] <sil2100> Ah
[11:42] <greyback> sil2100: they all fail
[11:42] <sil2100> You mean OSK AP tests
[11:42] <greyback> sil2100: yes
[11:43] <sil2100> greyback: ah, don't worry about that, so... not sure what's the *exact* situation with OSK tests, but from my OSK-development experience those are completely out-of-date and for now not being taken into consideration
[11:43] <sil2100> greyback: we don't run them on smoketesting as well
[11:43] <greyback> sil2100: ah ok, good to know. Thanks!
[11:43] <sil2100> Actually, I think it's finally time to start thinking about updating them and running on every image!
[11:44] <sil2100> greyback: anyway, phew, thanks for testing - no worries, usually running the 'test plan' for the component is enough to check if nothing is broken
[11:45] <greyback> sil2100: ok  noted, thank you
[11:47] <sil2100> greyback: np and thank you for picking up the responsibilities of a lander :)
[11:47] <ogra_> sil2100, sysvint autopkgtest failed ... seems we have to wait longer
[11:48] <sil2100> ogra_: crap, well, this way our first-built image today might actually fix the segfault as well
[11:48] <sil2100> I mean, have the fix for the segfault
[11:48] <ogra_> sil2100, right, but it will have 100 other changes ... i would have liked a dedicated image for the indicator
[11:49] <ogra_> there landed a ton of stuff last night
[11:49] <cjwatson> eh, don't panic yet
[11:49] <ogra_> which isnt in any image yet
[11:49] <ogra_> cjwatson, i dont panic :)
[11:49] <sil2100> ;)
[11:49] <cjwatson> I'm waiting for a response from pitti; if it's a testbed failure near the end, as it looks, I might force it
[11:51] <cjwatson> however as it happens I'm testing image builds locally with -proposed at the moment, and you're going to have another failure
[11:51] <cjwatson> ./live-build/ubuntu-touch/hooks/70-reconfigure-autopilot.chroot:10:dpkg -l python-autopilot >/dev/null 2>&1 && dpkg-reconfigure python-autopilot
[11:52] <ogra_> hmm why is that
[11:53] <ogra_> we didnt have it in 32 yesterday evening
[11:53]  * ogra_ chacks -changes 
[11:53] <cjwatson> Didn't python-autopilot get removed?
[11:53] <cjwatson> Note that dpkg -l may return zero even if a package is not installed
[11:53] <ogra_> nope, autopilot-qt still keeps it
[11:54] <cjwatson> My test build against -proposed didn't include it, but I guess I can investigate that
[11:54] <ogra_> ah, bah, xnox dropped the dep last night
[11:54] <ogra_> i guess we can drop that line from livecd-rootfs then
[11:54] <cjwatson> dpkg -l returning zero just means that dpkg has heard of the package, not that it's actually installed
[11:54] <ogra_> or move it to python3
[11:55] <cjwatson> we should fix the buggy test if we keep it
[11:55] <xnox> ogra_: cjwatson: why should python-autopilot required to be configured?
[11:55] <cjwatson> to get the phablet user into the autopilot group
[11:55] <cjwatson> see the comments in the file
[11:56] <ogra_> xnox, thats legacy code i think ... but i'm a bit scared to just wipe it ... we need some usable image for the weekend and have a lot other breakage atm
[11:56] <cjwatson> I'll fix it to be more tolerant
[11:56] <ogra_> thanks !
[12:01] <sil2100> cjwatson: thanks!
[12:01] <cjwatson> ogra_: Does http://paste.ubuntu.com/7472656/ look OK to you?  It calls the right dpkg-reconfigure command here in a stripped-down test, at least
[12:02] <cjwatson> ogra_: Sorry, make that http://paste.ubuntu.com/7472658/
[12:02] <ogra_> cjwatson, looks fine, yep
[12:05] <cjwatson> ogra_: OK, uploaded.  Lucky I happened to be testing locally ...
[12:06] <ogra_> yeah, thanks for doing that for touch actually :)
[12:06] <cjwatson> Well, only on i386 since I don't have a handy armhf builder locally, but good enough
[12:35] <mardy> would it be possible to setup Jenkins to run on every MP targetting ubuntu-system-settings-online-accounts/master?
[13:01] <thostr_> sil2100: line 27 is the network crash fix
[13:01] <sil2100> thostr_: excellent!
[13:01] <sil2100> Assigning
[13:02] <ogra_> sil2100, lets refrain from landing until we have an image built with the reaminings from the night though
[13:02] <ogra_> so that the indicator bits get a clean image on their own
[13:03] <ogra_> livecd-rootfs should migrate with the next publisher run, then i'll trigger an image build right away
[13:04] <sil2100> ogra_: sure, but a silo for testing is a good idea in overall
[13:04] <sil2100> No hurry
[13:04] <ogra_> sil2100, oh, yeah, i just mean the final switch :)
[13:04] <sil2100> ogra_: right ;) No worries!
[13:04] <ogra_> i just want to get the piled upp mess out of the way first
[13:09] <ogra_> ok, livecd-rootfs migrated ... triggering an image
[13:10]  * ogra_ crosses fingers
[13:10] <sil2100> Now this is one of the busiest Fridays ever
[13:10] <sil2100> Ok, maybe not ever
[13:10] <sil2100> ;p
[13:10] <sil2100> Busiest since like 3 weeks!
[13:12] <ogra_> yeah, at least
[13:12] <ogra_> actually busy week ... i didnt get any of my own stuff done
[13:13] <ogra_> bah, the bot was offline when the build started ...
[13:13] <ogra_> just imagine it said something :P
[13:13] <sil2100> ;p
[13:13] <ogra_> oh, wait, no
[13:13] <ogra_> it still waits for 33 to finish .P
[13:13] <sil2100> [13:14] <popey> sil2100 is now a bot
[13:14] <sil2100> popey: I prefer the term 'non-organic human'
[13:14] <ogra_> it will pick it up
[13:14] <sil2100> ;)
[13:14] <popey> ☻
[13:14] <ogra_> in 6min when the checker job runs next
[13:14] <ogra_> it was just still waiting for 33 to appear :P
[13:15] <sil2100> Ok, I guess it's time for me grabbing some lunch
[13:21] <plars> ogra_: yeah, I was just wndering... what happened on 33?
[13:21] <ogra_> plars, the builders exploded
[13:21] <ogra_> all of them ... all flavours all arches
[13:21]  * plars whistles
[13:21] <ogra_> :)
[13:22] <plars> ogra_: any idea why?
[13:22] <ogra_> yep, sysvinit was borked
[13:22] <ogra_> packages that have upstart job failed to install
[13:23] <ogra_> *an upstart job
[13:23] <plars> ouch
[13:23] <ogra_> sysvinit is fixed now ... then we found another issue with the dropping of the python2 autopilot bits ... which was hardcoded in livecd-rootfs
[13:23] <ogra_> both are fixed now
[13:24] <ogra_> an image is building ... cross your toes :)
[13:26] <ogra_> oh
[13:26]  * ogra_ just notices that we are actually *building 33*
[13:27] <ogra_> because of the failed build system-image indeed never had a 33
[13:37] <bfiller> Mirv: do you know if a click for gallery-app got released into the store based on silo 8 from last night?
[13:40] <Mirv> bfiller: not yet. popey had some mixed AP results (also 1-2 other failures besides the often happening add_photo one), so we were wanting to get a confirmation from you on whether to upload it
[13:40] <Mirv> bfiller: I did build it at http://s-jenkins.ubuntu-ci:8080/job/gallery-app-click-from-branch/ (974)
[13:40] <thostr_> Wellark: davmor2: packages for indicator crash ready to be tested in silo 11
[13:41] <bfiller> Mirv: right, I'm seeing the same failed AP tests but those are all the result of this bug https://bugs.launchpad.net/gallery-app/+bug/1319927
[13:43] <bfiller> Mirv, popey : I think we're good to upload it as the failures are known and unrelated to this change, and being worked on
[13:43] <Mirv> bfiller: ok then, I can upload it
[13:43] <ogra_> thostr_, hmm, i have a romaing icon ... but at least wlan is there
[13:43] <ogra_> (on flo)
[13:43] <bfiller> Mirv: thank you :)
[13:44] <ogra_> Wellark, ^^
[13:45] <popey> Mirv: bfiller ack
[13:45] <Mirv> gallery-app done (https://myapps.developer.ubuntu.com/dev/click-apps/507/)
[13:45] <ogra_> (assuming the triangle with R means roaming)
[13:45] <Mirv> and with that, see you on Sun/Mon
[13:45] <popey> Mirv: bfiller approved
[13:45] <popey> Mirv: safe travels
[13:45] <bfiller> Mirv: see you soon
[13:45] <bfiller> popey: thanks
[13:47] <Mirv> thanks
[13:54] <davmor2> thostr_, Wellark: http://davmor2.co.uk/~davmor2/screenshots-phone/indicator.png that is mako
[13:54] <davmor2> manta sorry
[13:55] <davmor2> thostr_, Wellark: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-145440.png and this is flo
[13:56] <davmor2> Wellark: do you want me to see what happens if I turn on manta's wifi?
[14:00] <ogra_> grmbl
[14:02] <davmor2> ogra_: see your network was only kept up by the lack of devices connecting due  to this bug ;)
[14:02] <ogra_> haha
[14:02] <davmor2> ogra_: http://davmor2.co.uk/~davmor2/screenshots-phone/indicator.png manta and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-145440.png flo
[14:02] <ogra_> my dhcp server died
[14:03] <davmor2> ogra_: E:TOO_MANY_CONNECTIONS
[14:03] <ogra_> davmor2, my flo connects fine here ...
[14:03] <ogra_> but i also see the roaming triangle
[14:03] <davmor2> ogra_: mine was bootstrapped so no network was setup
[14:03] <davmor2> ogra_: so in that respect it is correct
[14:03] <ogra_> ah, but if you tap one you get the dialog etc
[14:03] <ogra_> ?
[14:04] <davmor2> ogra_: manta on the other hand Wrong
[14:04] <ogra_> yeah, but thats definitely not the indicators fault
[14:04] <davmor2> ogra_: yeah I'm connected on flo now
[14:04] <ogra_> perfect
[14:04] <ogra_> now we need to get rid of the roaming thingie :)
[14:05] <Wellark> davmor2, ogra_: I'm back
[14:05] <Wellark> where are we?
[14:05] <ogra_> Wellark, looks fine but we see a roaming icon additionally
[14:05] <ogra_> Wellark, http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-145440.png
[14:06] <ogra_> manta doesnt work at all, but i blame NM here
[14:06] <ogra_> the indicator is there and looks fine
[14:06] <davmor2> ogra_: hang on I haven't tried turning the wifi on yet
[14:07] <davmor2> I was waiting patiently to see if anyone want info from it in it's current state first
[14:07] <ogra_> well, it should come up switched on by default ...
[14:07] <ogra_> and i suspect there is some lower level issue
[14:07] <davmor2> ogra_: indeed
[14:07] <ogra_> the mantas in the lab started failing before the indicator landed
[14:08] <davmor2> I blame rsalveti bound to be his fault
[14:08] <ogra_> haha
[14:08] <ogra_> yeah
[14:08] <rsalveti> what?
[14:08] <rsalveti> lol
[14:08] <Wellark> hmm..
[14:08] <ogra_> they already have the worldcup ... they can take some extra blame :P
[14:08] <rsalveti> oh, sure
[14:08] <rsalveti> hahah
[14:08] <ogra_> heh
[14:08] <Wellark> ogra_, davmor2: OK, so indicator came alive but tells you are roaming..
[14:08] <ogra_> rsalveti, well, manta NM seems to misbehave since a while
[14:09] <davmor2> rsalveti: you looked at android on manta didn't you, I'm not saying you changed anything you just looked ;)
[14:09] <ogra_> Wellark, right
[14:09] <Wellark> whoops.. seems I'm not initializing the roaming boolen properly
[14:09] <ogra_> better than the segfault though
[14:09] <ogra_> :)
[14:09] <Wellark> should I include the roaming fix to that silo as well?
[14:09] <ogra_> yeah
[14:09] <ogra_> we still have to wait for the image thats currently building
[14:10] <ogra_> so you have time
[14:12] <Wellark> uh, oh
[14:13] <Wellark> my wife just informed me that our son is missing..
[14:13] <Wellark> have to go look for him
[14:13] <Wellark> thostr_, ogra_: --^
[14:13] <Wellark> will ping you once he is found
[14:13] <ogra_> ok
[14:13] <ogra_> good luck
[14:13] <Wellark> if I don't make it back before you guys start to make images, could we still land with the roaming icon?
[14:13] <ogra_> yeah
[14:14] <ogra_> as long as it is functional and we know it will be fixed soon we're fine
[14:14] <Wellark> have to go now..
[14:17] <ogra_> argh !!!
[14:17] <ogra_> build failed again
[14:17] <bzoltan1> robru: may I get a Silofor line 28?
[14:17] <bzoltan1> rsalveti: ^
[14:18]  * ogra_ curses madly
[14:21] <sil2100> ogra_: ?!
[14:21] <bzoltan1> sil2100: may I get a Silofor line 28?
[14:22] <sil2100> bzoltan1: sure, assigning right now :)
[14:22] <bzoltan1> sil2100:  you read my mind :)
[14:22] <sil2100> bzoltan1: 17 for you o/
[14:22] <sil2100> :)
[14:22] <ogra_> sil2100, looks like some lockfile issue
[14:22] <ogra_> it finished successfully but didnt publish
[14:23]  * sil2100 really likes boiko's landing which will be published just now
[14:23] <sil2100> ogra_: uh ;/
[14:23] <boiko> sil2100: :)
[14:28] <sil2100> thostr_: I'm m&c'ing your silo if anything o/
[14:29] <thostr_> sil2100: which one?
[14:29] <sil2100> thostr_: 13
[14:29] <thostr_> yes, go forward
[14:32] <sil2100> ogra_: so, will you have to build the image from 0 or can you somehow push the already built one through publishing?
[14:33] <Wellark> ogra_, davmor2. thostr_: found our son. crisis over :)
[14:33] <ogra_> sil2100, we have to start over i fear
[14:33] <sil2100> ogra_: grrrr
[14:33] <sil2100> Wellark: what's up? Any news?
[14:33] <ogra_> stgraber is investigating
[14:36] <Wellark> sil2100: news on what?
[14:36]  * ogra_ triggers another build 
[14:37] <Wellark> sil2100, ogra_, davmor2, thostr_: pushed a fix for the incorrect roaming indication
[14:37] <ogra_> cross your fingers,toes, arms, legs ...
[14:37] <ogra_> Wellark, cool
[14:37] <ogra_> with the image build delay we have now you have a lot of time :)
[14:38] <Wellark> now just rebuild silo11 :)
[14:38] <Wellark> ogra_: I don't need any more time. now it's perfect and I can have my beer ;)
[14:38] <ogra_> haha, ok
[14:38] <davmor2> opifdgrewrasdad ← ogra (that's your nick with fingers crossed) but it's too hard to type on irc then
[14:39] <ogra_> use tab with a toe ;)
[14:39] <davmor2> ogra_: you said cross toes and legs though ;)
[14:39] <ogra_> be flexible ;)
[14:39] <ogra_> oh, right ... nose it is then
[14:40] <Wellark> davmor2: so, you got the indicator showing on manta?
[14:40] <ogra_> Wellark, yeah, indicator is fine ... NM/driver isnt
[14:41] <Wellark> ogra_: ok. so you now have concluded that there is a problem with either driver or NM
[14:41] <ogra_> Wellark, on manta, yes
[14:41] <Wellark> what about "wifi being offline on boot" ?
[14:41] <davmor2> Wellark: yeah shows on manta and flo there is an additional issue on manta though that cyphermox king of all the troublesome things is looking at
[14:41] <ogra_> but we dont care to much for manta ... thats low prio stuff
[14:42] <ogra_> (needs fixing ... but if there is more important stuff it moves down the TODO ;) )
[14:42] <Wellark> ogra_: so is there anything now that I need to look at still today?
[14:43] <ogra_> nope, get your beer (well, if the roaming fix works)
[14:43] <ogra_> (but even that i wouldnt mind to get fixed next week ...)
[14:45] <Saviq> sil2100, hey, not sure if you saw us discussing it... could we get "Approved by: " back in commit messages? can file a bug if you want
[14:46] <sil2100> Saviq: hm, I probably missed that - in commit messages committed to trunks you mean?
[14:46] <sil2100> Saviq: please fill in a bug and assign it to me, I'll try working on that once I have a moment :)
[14:46] <Saviq> sil2100, yeah
[14:48] <Saviq> sil2100, you got it: bug #1320264
[15:02] <Wellark> ogra_, davmor2, sil2100, thostr_: I updated the MP description of silo11. It now contains the specific testing instructions for this particular landing.'
[15:02] <Wellark> once the packages are ready, could you just run through that list of 6 items and make a comment to the MP so we get the test results documented.
[15:09] <thostr_> sil2100: is jenkins down???
[15:10] <thostr_> sil2100: something/someone aborted the build
[15:10] <Wellark> whee..
[15:10] <sil2100> Ouch
[15:10] <ogra_> more beer !
[15:10] <sil2100> So, I guess the jenkins plugin addition might have broken the workflow
[15:10] <thostr_> sil2100: Wellark: just kicked off another build
[15:11] <sil2100> thostr_, Wellark: could you re-kick a build?
[15:11] <sil2100> Sorry about that, didn't know that would happen
[15:11] <Wellark> the packages are on LP already
[15:11] <Wellark> no need to rebuild
[15:11] <Wellark> only arm64 was still building
[15:11] <thostr_> Wellark: but those are the old ones, no?
[15:11] <Wellark> should be the new ones
[15:12] <Wellark> Published
[15:12] <Wellark> 13 minutes ago
[15:12] <thostr_> yes, looks like it...
[15:12] <Wellark> and the arm64 package was built as well
[15:12] <Wellark> so we have full set
[15:12] <Wellark> if no code changes are required then those can be landed
[15:12] <Wellark> I'm flashing my mako right now
[15:13] <thostr_> Wellark: so, I'll cancel the build
[15:13] <Wellark> davmor2 and ogra_ can probably take care of flo and manta
[15:13] <ogra_> yep ... after my meeting runs ...
[15:16] <davmor2> indeed
[15:16] <davmor2> +1 on the after meetings though
[15:20] <Wellark> sure. no hurry
[15:20] <Wellark> I'be got plenty of beer
[15:23] <davmor2> Wellark: I suppose it's like 18:30 there
[15:26] <Wellark> davmor2: yep.
[15:26] <Wellark> I comleted testing on mako. works like magic.
[15:29] <ogra_> thostr_, Wellark are you guys in malta the second week ?
[15:29] <thostr_> ogra_: yes
[15:29] <ogra_> sil2100, ok. looks like we finally have a rootfs so feel free to land indicators etc :)
[15:29] <bzoltan> Mirv: sil2100: the QtC plugin in the Silo17 is good to go
[15:29] <ogra_> (though i guess i'm up for testing)
[15:29] <sil2100> ogra_: oh!
[15:30] <didrocks> sil2100: is the plugin installed now?
[15:30] <ogra_> system-image not done yet
[15:30] <sil2100> ogra_: did you have to rebuild or got the previous one published?
[15:30] <ogra_> but the rootfs is on cdimage
[15:30] <sil2100> didrocks: ye
[15:30] <sil2100> yes
[15:30] <ogra_> sil2100, had to rebuild
[15:30] <didrocks> sweet, let's check we have the right infos
[15:30] <didrocks> info*
[15:30] <sil2100> didrocks: took a really really reaaally long while ;p
[15:31] <didrocks> hum
[15:31] <didrocks> is it really enabled?
[15:31] <didrocks> sil2100: https://ci-train.ubuntu.com/job/cyphermox-test/7/console
[15:31] <didrocks> I'm running "env"
[15:31] <didrocks> (you can use this job to test)
[15:31] <sil2100> didrocks: you can check the config page of jenkins, it's enabled there
[15:32] <sil2100> https://ci-train.ubuntu.com/pluginManager/installed
[15:32] <didrocks> oh, there is a parameter
[15:32] <didrocks> see the page
[15:32] <didrocks> did you enable them?
[15:32] <didrocks> this "Set jenkins user build variables"
[15:34] <sil2100> Ah! Right, enabling that
[15:35] <didrocks> you need to do that in the xml
[15:35] <didrocks> and republish I guess
[15:35] <Wellark> hey!
[15:35] <didrocks> yeah, works in the test job :p
[15:35] <Wellark> I can't call out with image 32 + apt-get dist-upgrade
[15:35] <Wellark> BAAAD!!
[15:36] <didrocks> https://ci-train.ubuntu.com/job/cyphermox-test/8/console
[15:36] <didrocks> BUILD_USER_ID=didrocks
[15:36] <Wellark> didrocks: is this a known issue?
[15:36] <cyphermox> moo?
[15:36] <didrocks> Wellark: I'm not responsible with the image anymore, sil2100 will be way more up to date
[15:36] <didrocks> cyphermox: hijacking your test job :p
[15:36] <cyphermox> haha :)
[15:36] <Wellark> didrocks: ah, ok :)
[15:36] <Wellark> sil2100: !! --^
[15:37] <didrocks> cyphermox: no harm was done to it, I promise :p
[15:37] <sil2100> didrocks: will redeploying cancel all currently working jobs?
[15:37] <cyphermox> bah, no worries
[15:37]  * Wellark has to visit a grocery store quickly
[15:37] <didrocks> sil2100: it doesn't anymore it seems
[15:37] <sil2100> Wellark: uno momento ;p
[15:37] <sil2100> Wellark: hm, you mean, cellular is broken for you with that?
[15:38] <davmor2> sil2100: it's working for me on 32
[15:38] <ogra_> Wellark, did you make sure to not have ofono-pühonesim-autostart installed ?
[15:39] <davmor2> Wellark: yeah ofono-phonesim-autostart will screw you over
[15:40] <Laney> oh god that package
[15:40] <bzoltan1> sil2100: the Silo17 says that it needs some manual acking ... I just get ready with an other MR, do you think it would make sense to add that MR to the landing and reconfigure-rebuild in an hour, or should I wait for that ack and do an other landing?
[15:42] <ogra_> xnox, fyi ... the dropping of py2 only gained us 5M on the tarball
[15:42] <didrocks> ogra_: all is dropped now?
[15:42] <davmor2> Wellark, thostr_, ogra_: flo looks good connected and no /r\
[15:42] <didrocks> ogra_: like, no more python2 module at all?
[15:42] <ogra_> didrocks, http://people.canonical.com/~ogra/touch-image-stats/20140516.3.changes
[15:42] <ogra_> well, all autopilot related bits at least
[15:43] <xnox> ogra_: what do you mean "gained" ? as in reduced?
[15:43] <ogra_> xnox, it went from 508 to 503MB
[15:43] <didrocks> ogra_: that's sad, all that effort for it
[15:43] <sil2100> bzoltan1: one moment
[15:43] <xnox> ogra_: tarball is compressed very well, we also care about total sized the rootfs image takes up.
[15:43] <ogra_> xnox, i would have expected more ... slangasek raved about that a while ago :)
[15:43] <sil2100> bzoltan1: no no, I'll get it ACKed in a moment, too many things happening
[15:44] <xnox> ogra_: we should have gained more in terms of available disk spcae for pictures and stuff.
[15:44] <ogra_> xnox, well, dropping webkit would gain us more, even compressed :)
[15:44] <xnox> ogra_: ture, i think if we are happy with this, i'll be able to proceed in dropping qt4.
[15:44] <sil2100> bzoltan1: although I don't understand the packaging change there ;p
[15:44] <ogra_> (but thats part of the 13.10 framework ... so needs to stay alongside oxide :/ )
[15:45] <xnox> ogra_: well, we don't have testing results for this image yet do we?
[15:45] <ogra_> xnox, oh, and for reference http://people.canonical.com/~ogra/touch-image-stats/20140516.3.changes
[15:45] <davmor2> Wellark, thostr_, ogra_: Looks like manta is the same obvious just with no networking :)
[15:45] <ogra_> xnox, nope ... we dont even have a system-image yet ... still building
[15:46] <xnox> ogra_: camera, gallery, sudoku are all good =))))))so it must mean it should be golden.
[15:46] <ogra_> davmor2, yeah, ignore for now ... cyphermox is on the driver issue
[15:46] <didrocks> xnox: hum… do you know off hand what makes qt4 stikcing?
[15:46] <ogra_> xnox, haha
[15:46] <didrocks> sticking*
[15:46] <sil2100> bzoltan1: do you know why the author cleans the debian/tmp/usr/usr/tests directory twice?
[15:46] <ogra_> high hopes :)
[15:46] <ogra_> didrocks, in the past there were some dbus rdeps
[15:46] <ogra_> not sure thats still the case though
[15:46] <didrocks> do we really uses those?
[15:46] <ogra_> no
[15:46] <xnox> didrocks: yes, libautopilot-qt currently builds both qt4 & qt5 dlopen so-libraries in the single package. But since it gets dlopened by the running app, all qt4 deps can be dropped to suggests.
[15:46] <ogra_> but they are in the packaging
[15:47] <bzoltan1> sil2100: :) LOL ... to be very sure
[15:47] <didrocks> xnox: yeah, suggests sounds good for that use case
[15:47] <xnox> didrocks: as the qt app that is running under qt4 will have qt4 deps to dlopen autopilot-qt-testability module.
[15:47] <didrocks> xnox: it's compiz all over again! :)
[15:47] <xnox> =)))))))))))
[15:47] <ogra_> we should just obey and get compiz into the image
[15:47] <ogra_> if it wants that hard ...
[15:47] <davmor2> didrocks: on your device do sudo apt-get purge qt4 see what it reports ;)
[15:48] <bzoltan1> sil2100:  that asks for a fix in the MR
[15:48] <xnox> didrocks: if i just do it for qt4 module, i only need to make sure that e.g. qt4 based ap tests are still working which is not that large subset.
[15:48] <sil2100> bzoltan1: yeah, I would prefer this to be fixed - it seems to be something small, but I don't want to anger core-devs
[15:48] <ogra_> with compiz there would come X11 ... and you could finally play flightgear on your phone !!!
[15:48] <sil2100> bzoltan1: or if you can ask, maybe there is some reason for that :)
[15:48] <didrocks> xnox: making sense, I don't think though that we have qt4 based AP tests AFAIK…
[15:48] <didrocks> but I may be wrong :)
[15:49] <didrocks> we have checkbox at some points
[15:49] <didrocks> but not on the image
[15:49] <sil2100> bzoltan1: we could publish that anyway if it's a priority, but otherwise you can add some more merges to this one
[15:49] <bzoltan1> sil2100: Of course, that is wrong and I will fix it.
[15:49] <ogra_> if we had that would be massive legacy
[15:49] <ogra_> like from pre-official images
[15:49] <bzoltan1> sil2100:  it is priority, but can wait an extra hour or so ... and the ack is required because it is always required when the debian/ is touched
[15:50] <sil2100> bzoltan1: so let's get this fixed, quickly rebuilt and I guess we can proceed :)
[15:53] <sil2100> didrocks: hm, how can I get the name of the 'tick field' in XML to update it in our templates?
[15:54] <didrocks> sil2100: yeah, it's always hard… you have to:
[15:54] <didrocks> - either read the code
[15:54] <didrocks> - or cat one job .xml file that you changed
[15:54] <didrocks> I usually do the 2
[15:55] <didrocks> 2 as in "second"
[15:55] <sil2100> hm, but how can I access the .xml file? ;p
[15:55] <didrocks> well ssh to… oh! :)
[15:55] <sil2100> It's like, on prodstack!
[15:55] <didrocks> use cyphermox's script :p
[15:55] <sil2100> AH
[15:55] <sil2100> Right, damn, that's... geh, hacky ;)
[15:55] <didrocks> you have access through the job
[15:55] <didrocks> let me look at the canonistack instance
[15:55] <didrocks> so that I can get you the path :p
[15:56] <didrocks> sil2100: ~jenkins/jobs/landing-000-2-publish/config.xml
[15:56] <sil2100> No worries, I'll find it - I have the PWD, have the templates, I'll somehow reach the final destination ;p
[15:56] <didrocks> for instance
[15:57] <didrocks> I enabled it on cyphermox's job
[15:57] <didrocks> so maybe use that one
[15:57] <didrocks> and I would advise to add it to all build/publish/merge jobs
[15:57] <didrocks> to prepare for the future
[15:57] <didrocks> and beyond :p
[15:58] <Wellark> sil2100: I don't have phonesim-autostart installed
[15:59] <ogra_> Wellark, do you have a PIN you fogot to put in ?
[15:59] <Wellark> ogra_: no. I can receive calls
[15:59] <Wellark> but when placing one
[15:59] <ogra_> aww
[15:59] <Wellark> the dialer shows up
[16:00] <Wellark> and after ~2secs throws me to call log
[16:00] <ogra_> well, thats either dialer or ofnon then
[16:00] <ogra_> talk to either bfiller or awe_
[16:00] <Wellark> I'm just raising it
[16:00] <sil2100> Wellark: it's the same after a reboot?
[16:00] <Wellark> I'm way past eod :)
[16:01] <Wellark> sil2100: I will try
[16:01] <bfiller> Wellark: that bug was fixed a few days ago
[16:01] <awe_> thanks bfiller!
[16:01] <Wellark> bfiller: is it in archive?
[16:01] <awe_> was just going to mention that I didn't think ofono was involved
[16:01] <bfiller> Wellark: yes should be
[16:02] <Wellark> well, I will try again with fresh 32 + apt-get dist-upgrade
[16:02] <bfiller> Wellark: how are you starting the call? from the dialer or address book or is it an incoming call?
[16:02] <Wellark> bfiller: incoming call works
[16:03] <Wellark> can't call from either inputting the number through the pad or selecting a number from call log
[16:03] <Wellark> ogra_, davmor2: could you paste the test results to the MR?
[16:03] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/no-ofono-fix/+merge/219833
[16:04] <Wellark> bfiller, awe_: flashing again with 32
[16:04] <awe_> Wellark, on make?  32 works fine
[16:04] <awe_> s/make/mako/
[16:04] <Wellark> mako, yes
[16:04] <awe_> just made an outgoing call with no issues
[16:04] <Wellark> althrough I did also run dist-upgrade
[16:04] <imgbot> [16:04] <awe_> fresh flash
[16:04] <imgbot> [16:04] <Wellark> ok, let's see how 333 goes
[16:04] <Wellark> *33
[16:05] <awe_> using apt to upgrade isn't advised
[16:05] <awe_> use the system update, or re-flash
[16:05] <Wellark> awe_: well, have to do a dist-upgrade to do pull stuff from silos..
[16:06] <Wellark> awe_: but let's see what this 33 now says
[16:07] <Wellark> ogra_: I thought you said there is plenty of time before new image :)
[16:07] <ogra_> Wellark, yeah, that time is up now :P
[16:07] <ogra_> an image build takes 2h
[16:07] <ogra_> and since it failed half way though i had to re-build ... so this build took ~3h
[16:08] <Wellark> ogra_: well, if you just would add your test results we could land silo11 :)
[16:08] <ogra_> Wellark, i just set it to testing done (we're just in the landing team meeting, it is all taken care of now)
[16:08] <Wellark> ogra_: ok. cool.
[16:08] <Wellark> ogra_: thanks!
[16:09] <Wellark> awe_, bfiller: ok. I will test with stock 33 to see if I can place phone calls
[16:10] <Wellark> my connecction is just so damn slow..
[16:10] <Wellark> 2.31 MB/s
[16:19] <davmor2> popey: do you have weather app to update on 33, If so can you install it and see if the main settings app window still say Updates available 1
[16:19] <popey> davmor2: too late, already have that installed
[16:19] <davmor2> meh
[16:19] <popey> why? wassup?
[16:20] <popey> i do have an update waiting
[16:20] <popey> the weather app _will_ show as an update
[16:20] <popey> it landed in the store after image 33 was built
[16:22] <Wellark> awe_: are we now sending some sort of complementary service message each time modem gets online or something?
[16:22] <davmor2> popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-172026.png
[16:22] <sil2100> Ah, and btw.!
[16:22] <popey> whats wrong with that?
[16:22] <Wellark> I before wondered what was the empty popup I received each time I unlock the SIM
[16:22] <sil2100> robru: those tools look nice, good work ;)
[16:22] <davmor2> popey: weather installed no issues but that is what the main setting page still says
[16:22] <Wellark> but now with 33 I acctually got a message in that popup
[16:22] <popey> oh, its not refreshing?
[16:22] <popey> yes, I see that
[16:22] <Wellark> which makes it clear it's a balance request
[16:23] <davmor2> popey: it looks like it isn't updated after the click apps are installed
[16:23] <popey> yup, bug
[16:23] <davmor2> popey: nice I'll write up a bug I only just spotted it
[16:23] <awe_> Wellark, I'm not sure I understand your question.  There have been zero changes to the ofono SIM code recently
[16:25] <awe_> Wellark, did the silo for the 3g indicator fix land in 33?
[16:25] <Wellark> awe_: I wasn't thinking it's ofono.. I just though you might know which component might be sending requests to my operator
[16:25] <ogra_> awe_, will be in 34
[16:26] <awe_> Wellark, AFAIK none of our components send USSD requests on their own
[16:26] <ogra_> awe_, we wanted one image with all the cruft from the night before doing one specifically for the indicator
[16:26] <awe_> ogra_, ok
[16:26] <awe_> ETA for 34?
[16:26] <davmor2> awe_: asap
[16:26] <ogra_> once 33 testing is done i'll start a build
[16:26] <ogra_> 2-3h
[16:26] <awe_> k
[16:27] <ogra_> awe_, imgbot will announce it here
[16:27] <ogra_> (start and end of build)
[16:27] <awe_> yup
[16:32] <plars> ogra_: sil2100: starting to see results: http://ci.ubuntu.com/smokeng/utopic/touch/mako/33:20140516.3:20140513.2/8054/
[16:33] <ogra_> yeah
[16:36] <sil2100> plars: awesome
[16:39] <Wellark> plars: are those autopilot tests?
[16:40] <Wellark> could we get indicator-network-autopilot added there as well?
[16:40] <plars> Wellark: open a bug to ubuntu-ci-services-itself and I'll take a look. The tests are in a good state I hope?
[16:41] <Wellark> plars: well, there is just one at the moment :)
[16:41] <Wellark> plars: what do you mean by good shape?
[16:42] <plars> Wellark: if you tell me the tests are broken all over the place and need to be fixed, then we should probably wait. But if they are passing, or at least failing on real problems, then it would be great to have them in there
[16:43] <Wellark> plars: yes, the test is working and meaningful and actually verifies that the user can unlock his SIM
[16:43] <plars> Wellark: does it require we actually have a sim in the device? or does it mock that?
[16:43] <Wellark> plars: ubuntu-ci-service lists many projects
[16:44] <Wellark> plars: it does not require any hardware
[16:44] <plars> cool
[16:44] <Wellark> it uses ofono-phonesim just as the dialer app
[16:44] <plars> Wellark: here https://bugs.launchpad.net/ubuntu-ci-services-itself
[16:45] <Wellark> oh, I thought the "-itself" was a typo :D
[16:47] <Wellark> plars: feel free to modify the summary and description.
[16:47] <Wellark> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1320295
[16:49] <Wellark> ogra_: did silo11 land yet? should we wait for it to land before plars adds the autopilot tests?
[16:49] <robru> sil2100, what's going on with the publish jobs? I thought you said it would default to my own username? why does it fail when i leave it blank?
[16:49] <sil2100> robru: wait one moment :)
[16:50] <sil2100> Need to redeploy jobs, uno momento
[16:50] <plars> Wellark: I don't know that I'm going to have time to get to the tests today anyway
[16:50] <robru> sil2100, thanks
[16:51] <Wellark> plars: ok. fair enough :)
[16:51] <sil2100> robru: yeah, so, it was supposed to be enabled a long time ago, but actually getting the plugin installed on our ci-train jenkins took some time
[16:51] <sil2100> robru: try now?
[16:52]  * sil2100 wonders if didrocks tested his functionality
[16:52] <sil2100> ;)
[16:52] <robru> sil2100, oh i don't have anything to publish right now...
[16:53] <sil2100> Curses
[16:53] <sil2100> ;)
[16:53] <robru> sil2100, oh, i did a non-acked publish of silo 17, seems to have not failed
[16:53] <robru> sil2100, would be nice if the log mentioned it was using my name in launchpad though, it's silent about that right now
[17:03] <slangasek> ogra_, xnox: I certainly expect the impact to be more on the unpacked footprint than the compressed tarball.  What's the improvement to unpacked size?
[17:03] <slangasek> (and when can I have it? :)
[17:07] <xnox> well it's in image 33
[17:10] <Wellark> awe_, bfiller: I can't place a call with image 33
[17:11] <Wellark> awe_: any ofono scripts you want me to try?
[17:12] <awe_> hmmm, is this a fresh flash or a dist-upgrade?
[17:12] <Wellark> awe_: fresh.
[17:12] <awe_> w/out your packages, correct?
[17:12] <Wellark> awe_: yes. plain stock 33
[17:13] <Wellark> without making it even writable
[17:13] <awe_> ok
[17:13] <awe_> so a couple things
[17:13] <Wellark> panic time! :P
[17:13] <awe_> first, list-modems is your friend
[17:13] <Wellark> I can receive calls
[17:13] <awe_> all the ofono scripts are stored in /usr/share/ofono/scripts
[17:13] <Wellark> and send SMS
[17:13] <Wellark> placing a call fails
[17:13] <awe_> what do you see from the dialer?
[17:13] <xnox> slangasek: i wonder if we really need 132MB of icons.
[17:14] <slangasek> xnox: I guess someone does? :)
[17:14] <awe_> hmm, if incoming calls works & sms too, then this is something new
[17:14] <Wellark> I enter the number, hit the green button, the dialer turns to the call UI and then after 1 sec it throws me to call log
[17:14] <Wellark> then selecting a number from call log
[17:14] <awe_> 1) grep for ofono in /var/log/syslog, see if there's anything obvious
[17:15] <awe_> 2) try the ofono dial-number script
[17:15] <Wellark> it switches to call ui
[17:15] <awe_> see if it works
[17:15] <Wellark> and throws me back to call log immediately
[17:15] <awe_> I only tested 32
[17:15] <awe_> which worked fine
[17:15] <awe_> bfiller, ^^
[17:15] <Wellark> ugh.. healthd spams the syslog..
[17:15] <awe_> I'll flash 33 here
[17:15] <slangasek> xnox: so how much have you been using the armhf emulator lately?  I've been consistently seeing for a couple of weeks the problem that was reported on the list, of a white screen instead of scope output
[17:16] <xnox> slangasek: /usr/lib/python2.7 is still on the image, but it only has 66k -> 3 gi-overrides + debconf.py somehow.
[17:16] <plars> ogra_: I still only have 2 of the 3 makos going, I've retried twice now on that one that had the jenkins slave die originally, and both times the network failed to come up
[17:16] <awe_> slangasek, are you referring to the app scope?  That's been broken for awhile on both armhf and x86 ( emulator )
[17:17] <plars> [  625.753731] wlan: [1346:E :SME] csrMoveTempScanResultsToMainList: 2908: 11d AP Bssid 74:91:1a:28:c5:dd chan= 161, rssi = -51, countryCode US
[17:17] <xnox> slangasek: i mostly use my mako these days only.
[17:17] <Wellark> awe_: this is the relevant messages from syslog when trying to make a call
[17:17] <Wellark> http://pastebin.ubuntu.com/7473964/
[17:17] <Wellark> that "incoming call" looks suspicious
[17:17] <slangasek> xnox: and system-image-cli also doesn't want to work for me, bleh
[17:17] <slangasek> awe_: I don't know what I'm referring to, I just know that after I slide to unlock, everything is white except for the indicators
[17:18] <awe_> Wellark, there's no ofono errors in that log snippet; nothing looks too suspicious to me either
[17:18] <awe_> yea, that's the app scope bug
[17:18] <awe_> rsalveti, any status on ^^
[17:18] <slangasek> ok
[17:18] <awe_> rsalveti mentioned it in his recent x86 emulator email
[17:22] <Wellark> awe_: so powerd claiming an "incoming call" instead of outgoing is OK?
[17:22] <plars> ogra_: sil2100: results are not looking great so far
[17:24] <plars> seems mako is having a lot of network problems now :(
[17:24] <sil2100> oh?
[17:24] <sil2100> plars: network problems?
[17:25] <plars> sil2100: yeah, take a look at http://q-jenkins.ubuntu-ci:8080/job/utopic-touch-mako-smoke-daily/114/console (still in progress)
[17:25] <awe_> Wellark, nothing's changed recently in powerd AFAIK; they could just mean a call has been created.   I don't powerd cares if the call is incoming or outgoing
[17:25] <plars> sil2100: also, see above, I've had 2 consecutive mako runs fail so far because the install could never see thet network come up
[17:25] <xnox> HM!? why do we have unity-control-center on the image?!
[17:25] <awe_> it just cares that there's an active call as the proximity sensor logic is contained in powerd currently
[17:26] <Wellark> awe_: ok. any other log to look into?
[17:26] <awe_> so pretty sure "incoming" really just means "new"
[17:26] <awe_> other than syslog, no not really
[17:26] <xnox> oh, we don't.
[17:26] <awe_> did you try "dial-number" as I suggested?
[17:26] <awe_> I'm mid-flash of 33 myself
[17:27] <awe_> which just finished and I have no signal bars
[17:27] <awe_> ;(
[17:27] <awe_> so I can't dial at all
[17:27] <Wellark> no signal bars..
[17:27] <Wellark> awe_: do you have indicator-network?
[17:28] <Wellark> in the panel?
[17:28] <awe_> yes, wifi-disconnected
[17:28] <Wellark> awe_: so you are not seeing any cellular strength icons?
[17:29] <awe_> no, cause the modem is offline
[17:29] <awe_> cyphermox, ^^
[17:29] <Wellark> awe_: oh, that explains it
[17:29] <ogra_> plars, well, lets see with 34
[17:29] <plars> ogra_: ok
[17:30] <Wellark> awe_: btw
[17:30] <Wellark> dial-number
[17:30] <ogra_> might be caused by the indicator issues
[17:30] <Wellark> just outputs
[17:30] <Wellark> Using modem /ril_0
[17:30] <Wellark> /ril_0/voicecall01
[17:30] <Wellark> and exits
[17:30] <awe_> and does the remote number ring?
[17:30] <Wellark> awe_: nope.
[17:31] <Wellark> awe_: calling dial_number
[17:31] <Wellark> seems to switch to the call ui
[17:31] <Wellark> and the behaviour is the same
[17:31] <Wellark> in about 1sec after the call ui shows
[17:31] <awe_> Wellark, well unsure as on my phone the modem doesn't come online
[17:31] <cyphermox> moo?\
[17:31] <Wellark> it switches to call log
[17:32] <awe_> dude, can you try flashing 33?  My phone came up, no flight-mode enabled, but the modem is offline
[17:32] <cyphermox> sure, but give me a minute to finish testing this, I was just about to reboot with a new kernel
[17:32] <awe_> cyphermox, http://pastebin.ubuntu.com/7474037/
[17:33] <ogra_> awe_, 33 with the indicator fix added ?
[17:33] <Wellark> awe_: you can get it online by going in to the system settings -> cellular -> mobile data enabled ;)
[17:33] <awe_> just 33
[17:33] <ogra_> thats known broken
[17:33] <Wellark> that indeed toggles the powered property
[17:33] <cyphermox> well sure, but between 32 and 33 urfkill certainly hasn't changed
[17:33] <Wellark> ogra_: this has nothing to do with the indicator
[17:34] <ogra_> are you sure ?
[17:34] <cyphermox> if things came up on 32, they should still come up on 33
[17:34] <awe_> ogra_, what is broken in 33?  Looks like the set-online operation failed
[17:34] <ogra_> awe_, we are missing the fixed indicator ... but if Wellark is 100% sure it isnt related ... well, you are the experts :)
[17:34] <awe_> and I can't manually online the modem either
[17:35] <awe_> did we land any new android bits?
[17:35] <ogra_> nope
[17:35] <ogra_> it had no-change rebuilds twice this week though
[17:35] <ogra_> platform-api changed, android didnt
[17:36] <awe_> hmmm, well I can't online the modem, so something changed
[17:36] <awe_> lemme try a reboot
[17:36] <Wellark> well, this just sounds a lot like the "wifi disabled by default"
[17:36] <Wellark> which also seemed to be flaky between images that changed nothing
[17:36] <Wellark> regarding that
[17:37] <Wellark> who is feeding /dev/rand to our images?
[17:37] <Wellark> awe_: can I enable ril debugging somehow?
[17:38] <awe_> not easily
[17:38] <Wellark> seems everything is working "properly" when I'm doing outgoing call
[17:38] <Wellark> would be great to see if ofono gets a disconnect from ril
[17:38] <Wellark> that would point the problem to be on the android side
[17:39] <awe_> you can export OFONO_RIL_TRACE=y before starting ofono
[17:39] <awe_> that'll give you a RIL trace
[17:39] <Wellark> awe_: where is that outputted?
[17:39] <awe_> syslog, or stdout if you run from the cmdline
[17:40] <Wellark> awe_: ok. enabled the trace
[17:40] <ogra_> Wellark, depends when /dev/rand shows up ... initrd uses devtmpfs and udev ... then udev shuts down and hands over to android ... ueventd loads firmware and initializes devices, once ueventd is done and shot down udev takes over again so it can set permissions on the ubuntu side (note we have two /dev's)
[17:40] <Wellark> placing call.
[17:40] <Wellark> ogra_: I was trying to make a joke on $random stuff happening :)
[17:41] <Wellark> but thanks for the info!
[17:41] <ogra_> lol ok
[17:41] <awe_> ogra_, something else is definitely broken in 33
[17:41] <ogra_> did you try 32 ?
[17:41] <awe_> yea, it worked fine
[17:41] <ogra_> to see if thats definitely 33 only
[17:41]  * awe_ suspects that urfkill is trying to online the modem too early
[17:42] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/33.changes
[17:42] <ogra_> thats the change set
[17:43]  * ogra_ sees libphonenumber ... 
[17:43] <ogra_> iirc thats a new dep from dialer
[17:43] <ogra_> well and the ofono silo for the AP fixes
[17:43] <Wellark> awe_: http://pastebin.ubuntu.com/7474101/
[17:43] <Wellark> enjoy the trace
[17:44] <ogra_> hmm, not a dep of dialer ... i was wrong
[17:44] <Wellark> awe_: seems it's the ril side that hangs up
[17:44] <awe_> I'm trying to diagnose the !online problem first
[17:44] <Wellark> awe_: ofonod[7804]: [0167]< RIL_REQUEST_LAST_CALL_FAIL_CAUSE {65535}
[17:45] <Wellark> looks like -1 ;)
[17:46] <awe_> when the modem powers on boot, I have no issues with phone calls
[17:47] <awe_> my guess is that this may be related to dialer changes and possibly phone number formatting
[17:47] <awe_> please enter a bug against the dialer and we can go from there
[17:47] <ogra_> plars, i must say 33 tests look less bad than i expected (yet)
[17:47] <cyphermox> awe_: when the modem powers on boot?
[17:47] <ogra_> though dialer and messaging definitely look bad
[17:47] <awe_> ogra_, well so far I see two boots where the modem fails to power, and two where it worked
[17:48] <Wellark> is ril using two byte integers?
[17:48] <plars> ogra_: is that like expecting the worst so that you won't be disappointed? :)
[17:48] <awe_> cyphermox, does urfkill startup wait for ofono to start?
[17:48] <awe_> Wellark, don't ask such complicated questions!
[17:48] <awe_> ;D
[17:48] <ogra_> plars, yeah, i was waiting for all red ... possibly 45% overall :P
[17:48] <awe_> http://androidxref.com/4.4.2_r1/xref/hardware/ril/include/telephony/ril.h
[17:49] <Wellark> i'm just looking at that error code
[17:49] <awe_> https://wiki.mozilla.org/B2G/RIL
[17:49] <cyphermox> awe_: no, but urfkill will not online the modem until it has appeared in ofono, that is, until ofono has started, exposed itself on the dbus, and exposed a modem on the dbus
[17:49] <awe_> I wouldn't look too hard
[17:49] <awe_> cyphermox, ok
[17:49] <Wellark> 65535 is 0xffff
[17:49] <ogra_> awe_, well, if 32 worked for you i'd try rolling back suspicious packages to their former version
[17:49] <Wellark> which is -1 on two byte two's complement
[17:49] <awe_> Wellark, please open a bug, I'm not going to look at this right now
[17:50] <awe_> modem power takes priority
[17:50] <ogra_> piece by piece til it works
[17:50] <Wellark> awe_: sure. understood.
[17:50] <awe_> thanks
[17:50] <cyphermox> well since you all have a good handle on this, I'll keep working on bt
[17:51] <awe_> I wouldn't say we have a good handle, but I'll keep debugging for now
[17:51] <awe_> cyphermox, we probably need to add retry logic to urfkill
[17:51] <awe_> if set-online fails, we can't just leave it in that state
[17:52] <cyphermox> well how do you decide whether it will continue to fail or when to stop retrying?
[17:52] <cyphermox> it's not something that should fail at all
[17:52] <ogra_> should :)
[17:53] <cyphermox> i mean, in other words, it would be better to fix the underlying issue than the symptom
[17:53] <awe_> yea, but it's a phone and if it fails in the field, it's not like the user will log into the device and fix it
[17:53] <awe_> cyphermox, sure
[17:53] <awe_> but we don't know what the underlying problem *is*
[17:53] <awe_> and some kind of retry logic
[17:53] <awe_> provides a bit of a buffer
[17:54] <cyphermox> any way to defer exposing the modem on the bus until you know RIL is in a state that you expect it would be able to online the modem?
[17:54] <awe_> this is not different than the code in the rild job
[17:54] <awe_> or the SIM status code in rilmodem
[17:54] <awe_> cyphermox, we're still guessing
[17:54] <awe_> so no not yet
[17:55] <awe_> I've only seen 2 failures out of 6 boots
[17:55] <cyphermox> ok
[17:55] <ogra_> urfkill entered the image in 28 ... which is what we promoted ... nobody reported any issues with it
[17:55] <cyphermox> I didn't get enough log to be able to say anything anyway
[17:55] <awe_> still trying to get a handle on what's going on
[17:55] <ogra_> (and it workds fine for me as well)
[17:56] <Wellark> awe_: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1320319
[17:56] <ogra_> so i'm not sure you can blame urfkill at all here
[17:56] <awe_> well, works fine is all well and good during development
[17:56] <cyphermox> ogra_: could be racy
[17:56] <awe_> however any OEM will probably test this in a hard 300+ boot loop
[17:56] <ogra_> cyphermox, sure, but then the race is new in 28+
[17:56] <ogra_> all avengers use 28
[17:56]  * awe_ recalls the sandybridge hibernation debacle
[17:57] <cyphermox> ogra_: but I'd doing a very standard wait for dbus interfaces to appear before I do set Online, and whatnot, so if at that point things are seen as up but aren't, there isn't much I can do
[17:57] <ogra_> we would have heard loud complaints from management if this would be broken
[17:57] <awe_> ogra_, we *just* released flight-mode support
[17:57] <ogra_> awe_, three days ago in image 28
[17:57] <awe_> which changes the way we online the modem
[17:57] <ogra_> yes, i know
[17:58] <awe_> and we have heard rumours of intermittent failure to come online
[17:58] <awe_> and it's happened to me twice
[17:58] <ogra_> but we have what ... 20 avengers that run the promoted images ... 28 is a promoted one
[17:58] <Wellark> oh. 28?
[17:58] <ogra_> nobody complained
[17:58] <ogra_> Wellark, yep http://people.canonical.com/~ogra/touch-image-stats/28.changes
[17:58] <awe_> sure, that means the race probably has an extremely small window
[17:58] <ogra_> right
[17:58] <Wellark> wasn't that the image where we started to see "wifi disabled upon boot" ?
[17:59] <ogra_> and if you say 32 works for you i would look *only* at the changeset between 32 and 33 for now
[17:59] <ogra_> Wellark, nope, that was 30
[17:59] <Wellark> ok.
[17:59] <ogra_> 28 runs firne for me since three days ... i can make calls it has wifi and all
[17:59] <Wellark> but please note that we did extensive testing yesterday and nobody could repro with image 32
[18:00] <ogra_> right
[18:00] <ogra_> i was here :)
[18:00] <Wellark> although nothing relevant had changed between 31 and 32
[18:00] <awe_> Wellark, can you please include the phone number ( you can change the actual digits, just not the number of them, or any symbols included in the string )
[18:00] <awe_> in your new bug ^^
[18:00] <Wellark> awe_: it's just 0414404187
[18:00] <Wellark> awe_: you want me to add that?
[18:00] <awe_> yes please
[18:00] <Wellark> ok.
[18:00] <Wellark> I will just change one digit
[18:01] <cyphermox> awe_: so I suggest you add --debug to the urfkill command line and just reboot until the failure happens again, and give me the full syslog rather than the urfkill upstart log, which should usually be about empty
[18:01] <Wellark> or actually. I will just put the whole thing. I don't care if somebody calls me
[18:01] <awe_> cyphermox, ack
[18:02] <awe_> so far no more failures ( of course )
[18:02] <Wellark> awe_: added.
[18:02] <awe_> thanks
[18:03] <Wellark> awe_: do you want me to test 32?
[18:03] <awe_> if you'd like
[18:03] <Wellark> or any other number?
[18:03] <Wellark> *image number
[18:03] <awe_> as mentioned, outgoing phone calls work for me
[18:03] <Wellark> on 32?
[18:03] <Wellark> I will test that then
[18:03] <awe_> 32 & 33
[18:03] <Wellark> oh, ok.
[18:04] <Wellark> well, if there has been no changes between them then I don't know if it makes any difference
[18:04] <Wellark> I will give 32 a spin
[18:05] <ogra_> whee, soonsnap is in the store ...
[18:08] <Wellark> ogra_: what is the latest promoted image?
[18:08] <Wellark> I could do a bisect..
[18:08] <ogra_> Wellark, 28
[18:09] <ogra_> this is why we have the chnages i paste here all the time :) and try to keep the amount of changed packages small usually
[18:10] <ogra_> so bisecting between two images is easy ...
[18:10] <Wellark> it's just boring as hell ;)
[18:11] <ogra_> 33 is a pretty special case because we couldnt build one for 24h
[18:11] <ogra_> but obviously it bites us right now :)
[18:12] <Wellark> ok. can't place a call on 32 eithe
[18:12] <Wellark> r
[18:14] <Wellark> thostr_: hi..
[18:14] <bzoltan1> robru: I got the silo17 ready to land. It had a small glitch in the debian/rules pointed out by sil2100, now it is fixed.
[18:15] <awe_> Wellark, I'm really suspecting this new dialer change ( and the previously mentioned libphonenumber )
[18:15] <awe_> as I could make outgoing calls on both images
[18:15] <awe_> and nothing's changed in the ofono voicecall code... ( well other than the voice redirect bug )
[18:15]  * awe_ looks for the bug
[18:16] <awe_> was it a local call on a non-roaming SIM?
[18:16] <Wellark> awe_: yes.
[18:16] <awe_> was an area code specified?
[18:16] <Wellark> don't know what you mean by area code
[18:16] <Wellark> 041 is a cellular prefix
[18:17] <Wellark> awe_: I can not place a call with 32 either
[18:17] <Wellark> now testing 28
[18:17] <awe_> Wellark, can you try a different phone number?
[18:18] <awe_> one bug that was fixed in ofono recently is: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1239869
[18:18] <Wellark> awe_: did you check the log I attached to the bug?
[18:18] <Wellark> ril is giving an error
[18:19] <thostr_> Wellark: no, I just read the landing mail
[18:19] <awe_> sure, but it still could be related to the specific number
[18:19] <Wellark> thostr_: no, what?
[18:19] <awe_> again I can make phone calls on all of the images you've mentioned
[18:19] <Wellark> thostr_: I didn't say anything to you ;)
[18:19] <Wellark> except "hi" :)
[18:20] <Wellark> awe_: umm.. which component even cares for the phone number?
[18:20] <awe_> the voicecall atom
[18:20] <Wellark> it should be passed directly to the modem SoC
[18:20] <Wellark> awe_: what does it do with that?
[18:20] <awe_> did you look at the bug I pasted above?
[18:21] <awe_> the dialer pays attention to the phone number
[18:21] <awe_> and may modify it
[18:21] <awe_> ofono looks at error from rild
[18:21] <awe_> and may choose to ignore them in certain circumstances
[18:22] <awe_> I'm just guessing that this may be related to your operator and/or the phone number you're using because it works fine for me
[18:22] <Wellark> I have been able to call to that number before
[18:22] <Wellark> and there is nothing special with it
[18:23] <Wellark> I can try to use the international version of it
[18:23] <cyphermox> awe_: couldn't it still be related to the onlining? if the modem is not online it won't dial no?
[18:23] <Wellark> +358414404187
[18:23] <Wellark> cyphermox: the modem is online, I can receive calls and SMS
[18:23] <Wellark> thostr_: the silo landed
[18:24] <Wellark> awe_: 28 fails too
[18:24] <cyphermox> Wellark: well then it's dialer
[18:25] <awe_> Wellark, are you sure the SIM works?
[18:25] <cyphermox> awe_: wouldn't he not be able to receive calls then?
[18:25] <awe_> I just updated the bug, I'm able to place calls to both my landline and personal cell with no problems using #33
[18:25] <awe_> cyphermox, probably...
[18:25] <awe_> I'm just guessing
[18:25] <Wellark> well, I can't call with 28 either
[18:26] <Wellark> awe_: has there been a modem firmware upgrade or something?
[18:26] <awe_> no
[18:26] <Wellark> if the modem itself has got hosed
[18:26] <ogra_> i just made a call with 28
[18:26] <awe_> I asked ogra_ about this earlier ( ie. whether or not the android bits were updated )
[18:26] <ogra_> and did so the last two days ... i also reciverd a bunch of calls
[18:26] <Wellark> I'm not claiming 28 would be broken
[18:27] <ogra_> as i said, only no-change rebuilds to pull in platform-api changes
[18:27] <Wellark> I'm just saying my phone is broken
[18:27] <ogra_> twice
[18:27] <Wellark> and the modem socs do keep state
[18:27] <Wellark> they are embedded computers
[18:27] <awe_> understood, and I'm just saying that I think it's related to the dialer app changes and the possibly this new libphonenumber
[18:27] <Wellark> awe_: and that landed before 28?
[18:27] <awe_> I will add a dialer app task and ask tiagosh to take a look
[18:28] <awe_> Wellark, I don't know
[18:28] <ogra_> awe_, make the image writable and roll back the packages :)
[18:28]  * awe_ hears Ozzy in his head
[18:28] <awe_> ogra_, I can't reproduce, so I'm not going to roll back packages
[18:28] <Wellark> awe_: trying the +358 variant does not work either
[18:28] <ogra_> ah, yeah, then Wellark needs to
[18:28] <ogra_> or take 32 and install these packages
[18:28] <ogra_> if 32 is known to work for him
[18:28] <awe_> can you try a variant without "+"
[18:28] <cyphermox> awe_: jono's Severed Fifth is good for coding btw ;)
[18:29] <ogra_> haha
[18:29] <awe_> I love the guitar playing, but the voice, not so much
[18:29] <awe_> ( and
[18:29] <ogra_> makes your code sharp edged
[18:29] <awe_> I've told jono that before )
[18:29] <robru> bzoltan1, thanks for fixing silo 17, publishing
[18:29] <awe_> I much prefer singing to "metal singing"
[18:30] <Wellark> but anway. looking at the trace
[18:30] <Wellark> ofonod[7804]: [0167]< RIL_REQUEST_LAST_CALL_FAIL_CAUSE {65535}
[18:30] <Wellark> that's -1
[18:30] <awe_> yes you pointed that out before
[18:30] <awe_> that means GENERIC_FAILURE
[18:30] <Wellark> how would the dialer make ril side fail?
[18:30] <Wellark> anyway
[18:30] <Wellark> I need to eod
[18:31] <Wellark> have a good weekend!
[18:31] <awe_> yes, let's hold off and discuss when tiagosh is available
[18:31] <awe_> you too!
[18:32] <ogra_> plars, tests still running ? i'm missing about 200 results still
[18:33] <plars> ogra_: 2/3 have finished, the 3rd one I still can't get to run because the network never comes up right after the install (perhaps we just got really lucky with the other two)
[18:33] <ogra_> weird
[18:34] <ogra_> well, i think we should roll a new image then which is known to fix wifi issues ... and see if that helps
[18:35] <ogra_> though it points to awe_ and Wellark's problem above ... 2/3 phones work one doesnt ... with 33
[18:35] <awe_> plars, define "network"
[18:35] <awe_> WiFi or 3G?
[18:35] <ogra_> wifi
[18:35] <plars> awe_: wifi
[18:35] <awe_> ok
[18:35] <awe_> that's cyphermox
[18:35] <awe_> ;)
[18:36] <ogra_> but if teher is a urfkill race ...
[18:36] <awe_> I haven
[18:36] <awe_> I haven't been able to reproduce the modem not coming online again
[18:36] <awe_> I had two failures
[18:36] <awe_> once after the initial flash
[18:36] <awe_> and then again
[18:36] <awe_> since then I've rebooted 10 times and no failures
[18:37] <ogra_> plars, so do you prefer to go on trying ?
[18:38] <plars> ogra_: I can if you like, I've tried it on different devices too though, I may get lucky at some point though
[18:38] <awe_> cyphermox, I'm going to give up on this modem offline problem for now as well
[18:39] <ogra_> well, i'm not in a hurry if you want to go on, go on ... else i can as well just start a build for 34
[18:39] <awe_> note, the first time it happened ( immediately after the flash ), I couldn't even online the modem manually
[18:39] <cyphermox> plars: I absolutely need nmcli dev and a full syslog
[18:39] <cyphermox> and to know whether it's mako or what
[18:39] <ogra_> mako
[18:40] <ogra_> one out of three test devices in the lab
[18:40] <slangasek> cyphermox: is it known that urfkill dies in an endless loop on goldfish?
[18:40] <ogra_> goldfish ?
[18:40] <cyphermox> dies in an endless loop? no
[18:40] <cyphermox> goldfish is the emulator no?
[18:40] <ogra_> goldfish is dead since ages
[18:41] <slangasek> cyphermox: http://paste.ubuntu.com/7474351/
[18:41] <ogra_> generic is the emulator
[18:41] <ogra_> and generic_x86 the x86 one
[18:41] <slangasek> ogra_: it's still "goldfish", whatever it's calling itself in the android properties :)
[18:41] <cyphermox> slangasek: care to run it in a debugger?
[18:41] <cyphermox> OH
[18:41] <cyphermox> I think I know what this might be
[18:41] <ogra_> slangasek, ugh, it shouldnt
[18:41] <ogra_> rsalveti, ^^^is that known ?
[18:41] <cyphermox> I bet it's that pesky input handler that is broken
[18:42]  * rsalveti looking
[18:42]  * cyphermox stabs self and th urfkill input handler for good measure
[18:42] <ogra_> slangasek, it should call itself generic everywhere
[18:42] <ogra_> or generic_x86
[18:42] <rsalveti> no, not known
[18:42] <slangasek> ogra_: yes, it can call itself that, but it's still the same code :-P
[18:42] <rsalveti> let me grab the latest image
[18:44] <rsalveti> awe_: we have a bug for the empty scopes, but don't think we had any progress on it
[18:44] <rsalveti> and that's not necessarily emulator specific
[18:45] <rsalveti> ogra_: the kernel target is indeed called goldfish still :-)
[18:45] <ogra_> yeah
[18:45] <slangasek> cyphermox: so, urfkilld exits immediately on the commandline too, even with -d
[18:45] <cyphermox> -d won't do anythign though
[18:45] <slangasek> (exits 1)
[18:45] <ogra_> but all properties come from AOSP ... and should read "generic"
[18:45] <cyphermox> yeah
[18:45] <slangasek> cyphermox: wut! the --help says it should ;)
[18:46] <cyphermox> I think it's crashing because it can't figure out an input handler
[18:46] <slangasek> ok
[18:46] <cyphermox> syslog would tell you I guess
[18:47] <slangasek> cyphermox: http://paste.ubuntu.com/7474370/
[18:48] <cyphermox> ah, I see the addition of debuging information in my future
[18:48] <slangasek> :-)
[18:50] <slangasek> cyphermox: do you want a bug report?
[19:00] <Wellark> plars, ogra_: (I'm not officially here anymore)
[19:00] <Wellark> just my 2c
[19:01] <Wellark> add a script to the smoketest setup
[19:01] <Wellark> which forces the wifi on
[19:01] <Wellark> before you try to download packages
[19:01] <ogra_> that wont show us wifi issues then
[19:01] <rsalveti> cyphermox: ogra_: yeah, urfill keeps respawning on the emulator
[19:01] <rsalveti> cyphermox: mind check that later?
[19:01] <rsalveti> cyphermox: mind check that later?
[19:01] <rsalveti> argh
[19:01] <rsalveti> wrong window
[19:01] <ogra_> heh
[19:01] <rsalveti> [   42.597226] indicator-netwo[1812]: segfault at 0 ip 08124914 sp bfe1ca3c error 4 in indicator-network-service[8048000+13b000]
[19:01] <rsalveti> [   48.713660] indicator-netwo[2006]: segfault at 0 ip 08124914 sp bfb1090c error 4 in indicator-network-service[8048000+13b000]
[19:01] <rsalveti> as well
[19:01] <Wellark> ogra_: again. we might decide to ship with wifi disabled by defaul
[19:02] <Wellark> t
[19:02] <rsalveti> and there's a crash file
[19:02] <Wellark> our test setup should not rely on it being on
[19:02] <ogra_> Wellark, which is fine as long as the CI team gets told about it to adjust their stuff first
[19:02] <rsalveti> ogra_: I imagine this is also the bug we're seeing in the armhf images?
[19:02] <ogra_> rsalveti, nope
[19:02] <rsalveti> Wellark: indicator-network is broken on the emulator then
[19:03] <ogra_> rsalveti, indicator-network is broken til image 34
[19:03] <ogra_> which i havent started building yet
[19:03] <rsalveti> right, this is image 33
[19:03] <ogra_> the fix is in the archive
[19:03] <rsalveti> alright, will wait 34 :-)
[19:03] <ogra_> plars, yay ...
[19:03] <Wellark> just do dbus-send --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.DBus.Properties.Set string:org.freedesktop.NetworkManager string:WirelessEnabled variant:boolean:true
[19:03]  * ogra_ sees more tests 
[19:03] <plars> ogra_: :)
[19:04] <ogra_> Wellark, once we switch the default we should definitely do that ... as long as wifi is on by default it is a good way to sense wifi issues though
[19:04] <ogra_> a switch of the default cant "just happen"
[19:05] <ogra_> (if it does our processes are broken, involved parties need to be notified)
[19:06] <Wellark> I would again argue that the ci system should not depend the wifi being on or off, but you already know my opinion on this
[19:07] <ogra_> yeah
[19:07] <Wellark> now, i need to really put away my latop
[19:07] <ogra_> :)
[19:07] <ogra_> enjoy your evening
[19:07] <Wellark> I'm really scared my wife will throw it off the balcony soon
[19:07] <Wellark> you too :)
[19:08]  * ogra_ just gave his GF a laptop too ... :P
[19:11] <ogra_> hmm, seems like messaging and dialer also suffer from network issues
[19:12] <ogra_> both couldnt install their tests
[19:12] <plars> hmm?
[19:12] <plars> oh right, those two are still deb
[19:13] <plars> the click ones shouldn't suffer from that
[19:15] <ogra_> right
[19:16] <bzoltan1> robru: thanks!
[19:16] <robru> bzoltan1, you're welcome!
[19:17] <slangasek> so on ubuntu-emulator, I've historically either used system-image-cli for updates, or deleted and redownloaded a new image
[19:17] <slangasek> but since system-image-cli has a bug, I'm trying to do an update from the UI
[19:17] <slangasek> and I'm not being given the option to update from 32 to 33.. can someone tell me how I should expect this to work on the current version?
[19:17] <josharenson> fginther, now that my MP has been merged, can we try running the glmark2 test again? I think its here http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-builder-trusty-armhf/
[19:18] <slangasek> system settings -> about this phone -> check for updates doesn't show me 33
[19:19] <ogra_> it should even show you a "update available" at the top of the system-settings frontpage
[19:19] <slangasek> well, it didn't
[19:19] <ogra_> is the network working ?
[19:19] <slangasek> yes
[19:19] <slangasek> when I did 'check for updates', I got the option to download a bunch of click package updates
[19:19] <ogra_> oh, ok
[19:19] <ogra_> weird
[19:20] <ogra_> might be emulator specific ... my flo just got the update from 32 to 33 offered
[19:20] <slangasek> hmm
[19:20] <ogra_> though i had the fixed indicator-network deb installed manually before
[19:20] <ogra_> (which 34 will finally have)
[19:21] <slangasek> ah; perhaps the indicator-network breakage influences it somehow
[19:21] <ogra_> yeah, thats what i wonder
[19:21] <ogra_> though you are using an eth0 connection on the emulator
[19:21] <ogra_> it shouldnt even bother to manage wired connections
[19:22] <slangasek> right, the connection itself is working, but maybe the indicator-network being offline makes system-settings not check?
[19:23] <ogra_> right ... though why would the click updater not behave the same
[19:23] <ogra_> whats the issue with system-image-cli btw ?
[19:25] <ogra_> oh ! we have a secutity test failure ... thats rare
[19:30] <ogra_> Checking '/usr/share/ufw/check-requirements -f' ... ERROR: could not find valid python
[19:30] <ogra_> !FAIL!
[19:30] <ogra_> bah ...
[19:30] <ogra_> jdstrand, ^^^you need to switch your test to py3 ...
[19:48] <jdstrand> ogra_: yeah, I saw that and plan too
[19:48] <ogra_> great, thanks
[19:54] <slangasek> ogra_: the system-image-cli issue is bug #1320306
[19:55] <ogra_> oh, wow
[19:56] <ogra_> seems to be emulator specific though
[20:11] <renato> fginther, hi,
[20:12] <renato> fginther, for some reason jenkins is testing my packages with a old version of the autopilot
[20:12] <renato> fginther, https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/773/testReport/address_book_app.tests.test_edit_contact/TestEditContact/test_add_new_phone/
[20:13] <renato> fginther, autopilot = my autopilot tests
[20:21] <jdstrand> fyi, security test failure fix is in ufw 0.34~rc-0ubuntu3 which I just uploaded
[20:21] <ogra_> jdstrand, yay, thanks ...
[20:21] <jdstrand> it was a bad test
[20:21] <ogra_> i'll hold back the image build for it then
[20:21]  * ogra_ takes the finger off the trigger again 
[20:21] <jdstrand> heh
[20:21] <slangasek> :)
[20:22] <slangasek> is that the only fallout seen from dropping python2?
[20:22] <ogra_> plars, so seems dialer, addressbook and messaging tests failed due to wifi issues ...
[20:22] <plars> ogra_: not surprised from what I saw
[20:23] <ogra_> slangasek, this one yes, but due to the fact that we couldnt build images for nearly 24h a lot of crap piled up as well ... image 33 is horrid
[20:23] <ogra_> so it is hard to tell which failures are python related and which are due to other stuff that landed ...
[20:23] <ogra_> (and additionally having a broken network indicator doesnt help ...)
[20:24]  * slangasek nods
[20:24] <ogra_> 34 should fix a bunch of that at least
[20:24]  * ogra_ tries to think positive and celebrates that we are down to 3 crashers ... \o/
[20:25] <ogra_> (totally ignoring that we went from 11 to 32 failures indeed ... :P )
[21:15] <elopio> retoaded: I need to enable the click scope tests on MPs. Can you help me or get somebody to help me?
[21:16] <elopio> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1277247
[21:19] <imgbot> [21:23] <retoaded> elpoio, I can take a peek
[21:24] <elopio> retoaded: thanks. They have a development branch on ~unity-team/unity-scope-click/devel
[21:24] <elopio> that's the one that gets MPs.
[21:26] <boiko> robru: hey, is there a free silo available for line 33 of the spreadsheet? renato spotted a regression on address-book-app, and has already fixed it
[21:26] <retoaded> elopio, I will need to ping someone else in CI to see what needs to be done for that.
[21:27] <boiko> robru: s/33/31/
[21:27] <elopio> retoaded: ok. If at all possible, I would like to get a trial run to confirm the tests are passing. I have run them many times, but only on my computer.
[21:29] <cyphermox> rsalveti: yeah, checking into it right now
[22:39] <imgbot> [22:39] <imgbot> [22:40] <popey> \o/
[22:50] <rsalveti> robru: still around?
[22:51] <rsalveti> cyphermox: same for you :-)
[22:51] <rsalveti> basically need a silo for 31
[22:51] <rsalveti> don't remember how to create the request ID
[22:51] <rsalveti> in the spreadsheet
[22:51] <cyphermox> am still around
[22:51] <rsalveti> cyphermox: mind allocating a silo for line 31?
[22:54] <cyphermox> just a second
[22:55] <robru> sorry, just got back
[22:55] <robru> rsalveti, you go "Landing team tools > assign to silo"
[22:55] <robru> but i got it
[22:55] <cyphermox> ah ok
[22:56] <robru> rsalveti, silo 11
[22:56] <rsalveti> cyphermox: robru: great, thanks!
[22:56] <rsalveti> renato: ^
[22:56] <robru> rsalveti, you're welcome
[22:57] <rsalveti> hm, spreadsheet still not up-to-date
[23:00] <renato> robru, rsalveti, cyphermox thanks
[23:00] <robru> you're welcome!
[23:01] <robru> renato, yeah, sometimes the spreadsheet is slow to update. but the jenkins job can be run as soon as you are told of the silo number. you can just click the link to the build job even if the spreadsheet is blank
[23:01] <robru> also http://people.canonical.com/~rbpark/citrain/ often updates before the spreadsheet does
[23:02] <robru> rsalveti, i mean ^
[23:02] <rsalveti> cool