[01:16] robru: you still around? [01:17] bfiller, I can be, for a small price ;-) [01:17] bfiller, just kidding, what's up? [01:17] robru: haha :) [01:18] 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] hmmm [01:18] bfiller, oh is it a no-change rebuild? [01:18] robru: was basically a dummy MR just to force a rebuild but didn't have any real changes [01:18] robru: yes [01:18] right [01:18] 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] ok cool [01:20] 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] robru: got it, thanks [01:21] sergiusens, doanac hey what ever happened in silo 3? how did that ci run go? anything i can do to help? [02:09] === trainguard: IMAGE 33 building (started: 20140516 02:10) === [02:41] robru: I think we are good http://q-jenkins.ubuntu-ci:8080/job/andy-smoke-daily-test/14/console [02:41] robru: nothing tool wise broke, so I'm setting testing to done; those test take 4 hours to run btw :-P [02:42] sergiusens, sweet, I'll publish it ;-) [02:58] thomi: phablet-click-test-setup pulls the branch location and revno by looking at the click package manifest [02:58] thomi: also, I had a question for you [02:58] plars: I figured it out in the end, thanks tho :) [02:58] plars: shoot [02:58] thomi: hit a very strange subunit2junitxml/autopilot issue recently [02:58] thomi: http://q-jenkins.ubuntu-ci:8080/view/Touch/view/Ubuntu%20Touch%20Smoke/job/utopic-touch-flo-smoke-daily/57/console [02:59] thomi: or for the pastebin of the interesting bits... [02:59] thomi: scroll down to the bottom of: http://paste.ubuntu.com/7463064/ [02:59] oooh [02:59] tasty traceback :) [02:59] thomi: fortunately it seems to be pretty rare [03:00] 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] plars: are you able to link me to the subunit file that caused this? is it stuill around? [03:00] thomi: yep, I was just digging it out [03:00] one sec [03:01] 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] plars: and what's the command line you use when running it through subunit2xml? [03:02] hmnmm, it seems to parse it OK for me [03:03] thomi: cat ${odir}/test_results.subunit | subunit2junitxml > ${odir}/test_results.xml [03:03] huh [03:03] thomi: that's from the script, odir is the output dir [03:03] sure [03:03] I notice that there's some non-subunit-related binary data in the stream, I wonder where that comes from [03:04] plars: I'll talk to lifeless and see what he things [03:04] *thinks [03:04] thomi: cool. thanks [03:05] no worries [03:44] plars: still around? [03:44] plars: if so, are you able to tell me what the locale env vars for the machine that crashed are? [03:48] morning [03:52] oh hi robru :) [03:52] Mirv, hey what's up? [03:52] I wonder if any core dev is around at this hour [03:52] robru: just clicking on the same publish [03:53] Mirv, oh, funny [03:53] Mirv, actually that packaging change was done by ken, he's core dev, so basically auto-approve [03:53] Mirv, wow, is it 9PM already? i should sign off ;-) [03:54] robru: you're correct, it's ok to publish then [03:54] robru: maybe :) [03:54] Mirv, alright, I leave the rest of it in your hands... good night! [03:54] good night! [03:56] I think I'll try if I can test the gallery app click package myself and upload [03:58] Mirv: ping [03:59] bzoltan1: I was pinged already, if I guess correctly [03:59] Mirv: Yes, sorry for double ping [04:00] 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] 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] Mirv: let's ask pitti to ack it when he arrives [04:47] 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] Mirv: do you know anybody form the west coast who might be still active for an ack on that package? [05:36] bzoltan1: pitti seems now active on #ubuntu-devel [05:49] Mirv: I pinged him. How can I see that he acked? [05:50] bzoltan1: by the way that he said "it's fine". publishing. [06:07] Mirv: cool [06:26] Mirv: will the she-hoo-hoo ping me if the package is blocked on some black magic? [06:45] bzoltan: well the choo choo already told that the packages are migrating, I think its visibility stops about there [06:46] 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] so in 15 minutes or so it's available for all [06:48] Mirv: Of course ... thanks [06:54] 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] (and well landing-018 is already there) [06:55] Mirv: I am cleaning up teh silo19, so that will be back at your disposal soon [06:56] bzoltan1: yeah, but I wouldn't like to give 1/3 of the silos to dbarth alone :) [06:57] Mirv: is there a protocol or policy to bribe the CI Train? :D [06:59] naturally it's all non-formal and not admitted :) [07:00] * bzoltan1 has still a lot to learn :) [07:08] hi [07:09] Mirv: "all you silos are belong to us" ;) [07:09] so yeah, let me streamline that [07:19] 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] 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] 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] like http://bazaar.launchpad.net/~mir-team/mir/utopic/revision/1185 [07:22] 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] dbarth: hi! I sadly cannot assign any silos for your landings right now :< All the components are already 'locked' [07:27] dbarth: would be nice if silo 018 could progress! [07:28] you can remove line 17 as well [07:29] so i think i cleaned all of our previous landing requests, and merging all of that into one mega OA silo [07:29] dbarth: ah! Missed the comment there, ok, let me purge it [07:29] all on line 43 [07:30] ie line 43 is our mega silo [07:30] 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] the rest, i've commented on the individual lines [07:30] really not here yet so sods off [07:31] 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] Mirv: o/ [07:48] * sil2100 sighs [07:48] hmm, you might have noticed that image 33 above never resturned a success command .... this is because it never finished building [07:48] :( [07:48] (like all other images that were built tonight for all falvours, all arches) [07:48] I wonder why installing that jenkins plugin takes so much time [07:48] oh [07:49] ogra_: infra problems? [07:51] looks more like a package problem ... see #ubuntu-devel [07:51] uh [07:52] And we seem to be having some jenkins issues [07:52] well, if that uses fresh chroots that might be related [07:53] sil2100: hum, you are installing it yourself? [07:53] didrocks: no, I filled an RT, prepared the charm, but webops somehow 'take a long time' [07:54] didrocks: I poked yesterday late at night even, there was someone looking at it but only assessed the time required [07:54] ok [07:54] And there doesn't seem to be anyone around webops right now [07:54] yeah, what colin told yesterday, nobody in the morning time this week [08:15] Mirv: what was the result of you yesterday investigation with failing system-settings tests? [08:28] 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:28] bug 1319711 in ubuntu-system-settings (Ubuntu) "test_tz_list_initially_empty started failing in image #29" [Undecided,New] https://launchpad.net/bugs/1319711 [08:29] I marked it as incomplete now, since really I don't know what to do next about it [08:29] I'm running it once more now with #32 [08:30] 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] 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] Mirv: sure thing [08:34] popey: hmm, maybe to apt-get update + dist-upgrade on top of #32 too, since the other components are otherwise not there.. [08:34] s/to/do/ [08:34] ok [08:35] "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] maybe content-hub === ev_ is now known as ev [08:38] (yep, no failure on #32 either with u-s-s) [08:42] I don't understand why it started failing or why it doesn't happen locally [08:43] Laney, well, it clearly started when tzdata got updated ... indeed that might be coincidence ... [08:44] do we have video recording of those failing tests? [08:44] we have a second failure now, also in a tz related test [08:44] you're still stuck on that? [08:44] it'd reproduce locally if it was something like that surely [08:46] http://ci.ubuntu.com/smokeng/utopic/touch/mako/32:20140515.2:20140513.2/8044/ubuntu_system_settings/ [08:47] test_searching_tz_not_found and test_manual_tz_selection [08:48] sil2100: always a good idea to test things in the cloud first :) [08:48] To the cloud! [08:49] hahaha [08:49] * didrocks still see a nice blue sky here [08:50] I usually test run it on the ground, but cloud is the future [08:50] 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] I was thinking more an orange box [08:50] haha [08:51] popey: nice orange box talk on linux unplugged btw :) [08:51] hehe [08:52] * didrocks is always under the impression to run/exercise with popey at lunch time [08:52] I'd slow you down. [08:52] ahah ;) [08:52] Mirv: testing gallery now, will let you know outcome.. [08:53] wow, people are actually leaving comments and ratings on apps! [08:53] oh nice :) [08:53] Mirv: can someone CIish help us determine what's different? [08:53] its turning into a bug tracker [08:53] popey: ok! [08:53] ah… :( [08:53] not unsurprising I guess [08:53] Laney: psivaa possibly... [08:54] mardy: thats a visualization problem, no? you can use bzr log --include-merges or something to see the merged revisions [08:54] asac: yes, but launchpad.net doesn't do that [08:55] asac: the problem is that we have all tools built around the idea of "trunk" as development branch [08:57] 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] dbarth: regarding line 11 - that's for utopic, right? [08:58] psivaa: yeah, I'm not blaming your side but it's quite hard to determine what changed [08:58] ci.debian.net gives you a nice summary at the start of its output of the differences between subsequent runs :-) [08:59] Laney: understand [08:59] 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] the latest output says it can't find the field [08:59] which is quite curious indeed [09:00] the objectName seems to be there [09:00] e.g. make the tools dictate what and how you do things [09:10] ogra_: the autoreport setting should work properly now btw [09:10] sil2100: nope, that's primarily for 14.04 [09:10] Laney, so i heard ... waiting for the next promotion to test myself :) [09:10] dbarth: so, you want a silo for 14.04 for that landing, right? [09:11] sil2100: yes, please [09:11] this is SRU material as i was putting in the comment box [09:11] Mirv: Ran 37 tests in 853.308s [09:11] FAILED (failures=2) [09:11] popey: add_photo is quite normal, what's the other one? [09:12] Mirv: http://paste.ubuntu.com/7472056/ [09:12] oh, wow, the filemanager got pretty useless [09:12] victor filed a bug for that last night, but i can't reproduce it [09:13] it allows you to go to / but doesnt display anything [09:13] bug 1320032 [09:13] bug 1320032 in Ubuntu File Manager App "Filemanager starts in "/" and shortcuts in Places are bad" [Undecided,Invalid] https://launchpad.net/bugs/1320032 [09:14] Laney, confirmed ... on my flo i have a lot of .uploaded files :D [09:14] * ogra_ hugs Laney ... thanks so much ! [09:14] hmm [09:15] but tapping on "Previous error reports" does not open the browser with them [09:15] :) [09:15] it used to do that a while ago [09:15] 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] Yay! [09:15] popey: maybe rerun or then we'll just ping bfiller on testing the click package too [09:16] Mirv: ok, reboot and re-run [09:16] Laney, [09:16] ** (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] want a bug ? [09:17] hmm, tapping on previous error reports prints actually nothing like i havent tapped [09:18] *hasnt [09:18] you clicked privacy policy? [09:18] that works for me [09:20] privacy policy prints the above ... but doesnt open anything [09:20] previous error reports prints nothing [09:22] hiya [09:22] Laney, bug 1320154 [09:22] bug 1320154 in ubuntu-system-settings (Ubuntu) "browser related actions do not work in privacy settings" [Undecided,New] https://launchpad.net/bugs/1320154 [09:22] 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] 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] looks odd, psivaa may be able to investigate [09:25] cool, thanks popey and psivaa [09:25] looks like network cut during apt-get update [09:32] Mirv: Ran 37 tests in 852.997s [09:32] FAILED (failures=3) [09:32] http://paste.ubuntu.com/7472115/ [09:36] Wellark, do you have a silo for the icon already ? [09:37] would be nice to have that landed before the next image build [09:37] (since its so trivial) [09:43] popey: bah. maybe we need a reassurance from bill before putting it to store then at least. [09:48] Wellark: are you up already? [09:58] Mirv: Laney: sil2100: So you might have seen the next run on ubuntu_system_settings has finished all passing. [09:58] Laney: It does appear to be flaky/ racy when click_tz_search_field being used [09:58] psivaa: that's without any changes? [09:59] 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] no [09:59] there is also 'Autopilot test refactoring: add emulators and helpers' in rev700. which includes click_tz_search_field [10:00] psivaa: thanks for the analysis [10:00] The failures are about autopilot not beingn able to find elements [10:01] It's probably going to be in the tests themselves [10:01] thanks [10:03] Laney: sil2100: np. sorry, i could not find any other reasons :) [10:04] popey: i've kicked rebuild on that MP. [10:24] psivaa: oh! so it's indeed flaky. I've never had a run locally though with success so far. [10:24] Mirv: you mean, system-settings? [10:25] didrocks: do you still have your scripts for rolling-back changes easily? ;) [10:25] Mirv: yea, i dint expect it to pass tbh, but it did :) === MacSlow is now known as MacSlow|lunch === seb128_ is now known as seb128 [11:31] sil2100: sure, it's in lp:cupstream2distro [11:32] citrain/manual/reverter [11:32] 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] sil2100: you need upload rights though [11:40] uh! [11:40] greyback: silo17 you say? I just published it as it was marked 'testing done', ouch [11:41] sil2100: ah, I had added the comment underneath, then came here to ask you. Oww [11:41] 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] hm [11:42] 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] greyback: how did you do the autopilot testing? It shouldn't all fail [11:42] Ah [11:42] sil2100: they all fail [11:42] You mean OSK AP tests [11:42] sil2100: yes [11:43] 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] greyback: we don't run them on smoketesting as well [11:43] sil2100: ah ok, good to know. Thanks! [11:43] Actually, I think it's finally time to start thinking about updating them and running on every image! [11:44] 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] sil2100: ok noted, thank you [11:47] greyback: np and thank you for picking up the responsibilities of a lander :) [11:47] sil2100, sysvint autopkgtest failed ... seems we have to wait longer [11:48] ogra_: crap, well, this way our first-built image today might actually fix the segfault as well [11:48] I mean, have the fix for the segfault [11:48] sil2100, right, but it will have 100 other changes ... i would have liked a dedicated image for the indicator [11:49] there landed a ton of stuff last night [11:49] eh, don't panic yet [11:49] which isnt in any image yet [11:49] cjwatson, i dont panic :) [11:49] ;) [11:49] 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] 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] ./live-build/ubuntu-touch/hooks/70-reconfigure-autopilot.chroot:10:dpkg -l python-autopilot >/dev/null 2>&1 && dpkg-reconfigure python-autopilot [11:52] hmm why is that [11:53] we didnt have it in 32 yesterday evening [11:53] * ogra_ chacks -changes [11:53] Didn't python-autopilot get removed? [11:53] Note that dpkg -l may return zero even if a package is not installed [11:53] nope, autopilot-qt still keeps it [11:54] My test build against -proposed didn't include it, but I guess I can investigate that [11:54] ah, bah, xnox dropped the dep last night [11:54] i guess we can drop that line from livecd-rootfs then [11:54] dpkg -l returning zero just means that dpkg has heard of the package, not that it's actually installed [11:54] or move it to python3 [11:55] we should fix the buggy test if we keep it [11:55] ogra_: cjwatson: why should python-autopilot required to be configured? [11:55] to get the phablet user into the autopilot group [11:55] see the comments in the file [11:56] 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] I'll fix it to be more tolerant [11:56] thanks ! === alan_g is now known as alan_g|lunch [12:01] cjwatson: thanks! === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: - [12:01] 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] ogra_: Sorry, make that http://paste.ubuntu.com/7472658/ [12:02] cjwatson, looks fine, yep [12:05] ogra_: OK, uploaded. Lucky I happened to be testing locally ... [12:06] yeah, thanks for doing that for touch actually :) [12:06] Well, only on i386 since I don't have a handy armhf builder locally, but good enough === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [12:35] would it be possible to setup Jenkins to run on every MP targetting ubuntu-system-settings-online-accounts/master? [13:01] sil2100: line 27 is the network crash fix [13:01] thostr_: excellent! [13:01] Assigning [13:02] sil2100, lets refrain from landing until we have an image built with the reaminings from the night though [13:02] so that the indicator bits get a clean image on their own [13:03] livecd-rootfs should migrate with the next publisher run, then i'll trigger an image build right away [13:04] ogra_: sure, but a silo for testing is a good idea in overall [13:04] No hurry [13:04] sil2100, oh, yeah, i just mean the final switch :) [13:04] ogra_: right ;) No worries! [13:04] i just want to get the piled upp mess out of the way first [13:09] ok, livecd-rootfs migrated ... triggering an image [13:10] * ogra_ crosses fingers [13:10] Now this is one of the busiest Fridays ever [13:10] Ok, maybe not ever [13:10] ;p [13:10] Busiest since like 3 weeks! [13:12] yeah, at least [13:12] actually busy week ... i didnt get any of my own stuff done [13:13] bah, the bot was offline when the build started ... [13:13] just imagine it said something :P [13:13] ;p [13:13] oh, wait, no [13:13] it still waits for 33 to finish .P [13:13] === Image build #34 started ... ;p ? === [13:14] sil2100 is now a bot [13:14] popey: I prefer the term 'non-organic human' [13:14] it will pick it up [13:14] ;) [13:14] ☻ [13:14] in 6min when the checker job runs next [13:14] it was just still waiting for 33 to appear :P [13:15] Ok, I guess it's time for me grabbing some lunch === ted is now known as tedg [13:21] ogra_: yeah, I was just wndering... what happened on 33? [13:21] plars, the builders exploded [13:21] all of them ... all flavours all arches [13:21] * plars whistles [13:21] :) [13:22] ogra_: any idea why? [13:22] yep, sysvinit was borked [13:22] packages that have upstart job failed to install [13:23] *an upstart job [13:23] ouch [13:23] 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] both are fixed now [13:24] an image is building ... cross your toes :) [13:26] oh [13:26] * ogra_ just notices that we are actually *building 33* [13:27] because of the failed build system-image indeed never had a 33 [13:37] Mirv: do you know if a click for gallery-app got released into the store based on silo 8 from last night? [13:40] 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] bfiller: I did build it at http://s-jenkins.ubuntu-ci:8080/job/gallery-app-click-from-branch/ (974) [13:40] Wellark: davmor2: packages for indicator crash ready to be tested in silo 11 [13:41] 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:41] Ubuntu bug 1319927 in gallery-app "Adding photo to existing album not working" [Critical,In progress] [13:43] 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] bfiller: ok then, I can upload it [13:43] thostr_, hmm, i have a romaing icon ... but at least wlan is there [13:43] (on flo) [13:43] Mirv: thank you :) [13:44] Wellark, ^^ [13:45] Mirv: bfiller ack [13:45] gallery-app done (https://myapps.developer.ubuntu.com/dev/click-apps/507/) [13:45] (assuming the triangle with R means roaming) [13:45] and with that, see you on Sun/Mon [13:45] Mirv: bfiller approved [13:45] Mirv: safe travels [13:45] Mirv: see you soon [13:45] popey: thanks [13:47] thanks [13:54] thostr_, Wellark: http://davmor2.co.uk/~davmor2/screenshots-phone/indicator.png that is mako [13:54] manta sorry [13:55] thostr_, Wellark: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-145440.png and this is flo [13:56] Wellark: do you want me to see what happens if I turn on manta's wifi? [14:00] grmbl [14:02] ogra_: see your network was only kept up by the lack of devices connecting due to this bug ;) [14:02] haha [14:02] 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] my dhcp server died [14:03] ogra_: E:TOO_MANY_CONNECTIONS [14:03] davmor2, my flo connects fine here ... [14:03] but i also see the roaming triangle [14:03] ogra_: mine was bootstrapped so no network was setup [14:03] ogra_: so in that respect it is correct [14:03] ah, but if you tap one you get the dialog etc [14:03] ? [14:04] ogra_: manta on the other hand Wrong [14:04] yeah, but thats definitely not the indicators fault [14:04] ogra_: yeah I'm connected on flo now [14:04] perfect [14:04] now we need to get rid of the roaming thingie :) [14:05] davmor2, ogra_: I'm back [14:05] where are we? [14:05] Wellark, looks fine but we see a roaming icon additionally [14:05] Wellark, http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-16-145440.png [14:06] manta doesnt work at all, but i blame NM here [14:06] the indicator is there and looks fine [14:06] ogra_: hang on I haven't tried turning the wifi on yet [14:07] I was waiting patiently to see if anyone want info from it in it's current state first [14:07] well, it should come up switched on by default ... [14:07] and i suspect there is some lower level issue [14:07] ogra_: indeed [14:07] the mantas in the lab started failing before the indicator landed [14:08] I blame rsalveti bound to be his fault [14:08]