[00:00] lool: ^? [00:00] lool: it does look pretty harmless [00:01] popey: Yeah, or from T [00:01] popey: technically we can still land tomorrow morning in archive or -updates, with paperwork for SRU [00:02] or starting friday or monday in T [00:02] Saviq: unity8-fake-env's new mock dir is harmless, yes? [00:05] Forgot to note it here but I published unity8 to proposed a while ago [00:05] lool: so we'll do system updates for phone? [00:06] I mean, the crucial thing for me is that a sales person or user who has a phone they flash with image 100 (or whatever ends up being 'final') can update to get the fixes [00:06] popey: I'm testing the new qtorganizer5-eds aaand... [00:06] (apologies if this is all well known, I haven't seen many discussions about post-13.10 updates to touch) [00:07] popey: it seems I can save an alarm, but I can't edit it or disable it :| [00:07] popey: yup [00:07] popey: TBH the next days are not crystal clear to me either [00:07] and the update frequency is also unclear [00:08] every week, every month etc. [00:08] but we will update the stable imge [00:08] I dont know whether we'll update *stable* or *devel* every month for instance [00:09] lool, yeah, it's just about AP tests [00:09] right [00:09] so for core apps we're golden because we can deliver updates through the store [00:09] popey: exactly [00:09] but for system components like the ones above we're really stuck [00:10] popey: note that I'd like to tighten the way they get into an image [00:10] hence me being keen to get them in 100 [00:10] popey: it shouldn't stop users getting the latest from app store [00:10] popey: via click updater [00:10] yeah, we'll gate core apps [00:10] popey: but right now we have no way to gate [00:10] right [00:10] they can't be updated by the core apps devs [00:10] well we do [00:10] well at the appstore level, right [00:10] sergio has added them all to the store under a separate email account [00:10] so we can manually update [00:10] which is okay for now [00:11] clearly not long term sustainable solution, and doesn't fix the issue in hand [00:11] popey: I'm not really sure about releasing the new qtorganizer5-eds - I set an alarm for like 1 minute ago and it didn't do anything, also, removing, disabling and editing alarms doesn't seem to work [00:11] popey: so clearly there seems to be something wrong here [00:12] it wont do anything [00:12] until you have charles' bits in [00:12] which should trigger a notification [00:12] I thought charles bits were only about informing about alarms on the indicator [00:12] Ah, ok [00:12] Still, not being able to disable an alarm is a big problem IMO [00:12] renato fixed saving in eds, charles enabled notification from indicator-datetime [00:13] If we get the bits that charles has, people will be stuck with alarms once they create them [00:13] i dont know where the broken bit is with regards to editing alarms [00:13] whether thats in clock or eds or somewhere else [00:14] Hi charles_ [00:21] lool: what do you think? Should we publish the qtorganizer5-eds fix for saving new alarms, even though there is no possibility of later editing, disabling, deleting of those? [00:21] well, "no possibility" can be fixed ☻ [00:21] Indeed ;) [00:22] sil2100: well... [00:22] But will we be able to do that before release? [00:22] indeed [00:22] sil2100: I'll ask back: what was didrocks recommendation? [00:22] I think he wanted a working story; it seems it's half working [00:22] net improvement [00:22] but still partial, another landing etc. [00:23] lool: I guess, ok, so let's leave that for tomorrow - if Didier ACKs it in the morning, we can instantly publish it since it's tested anyway [00:23] I think we will have to document a known bug in either case [00:23] sil2100: we have it staged; if a 101 goes out tomorrow morning, e.g. for the critical download manager thing, then we can revisit and include this one [00:23] worst case, it comes in the first update [00:23] Sounds reasonable. [00:24] Indeed [00:24] lool: do you need help in anything else right now? [00:25] sil2100: I'm good! [00:25] sil2100: we can test the download-manager in PPA in a few [00:25] for system-updates and for clicks [00:25] I intend to jsut test for click [00:25] as a side thing [00:26] (and with system-image when the next image comes out) [00:26] gosh, unity8 in release pocket from DB, waiting on publisher [00:30] cyphermox: around? [00:33] rsalveti: around? [00:33] Now's the time [00:36] What do we need to test? [00:36] sil2100: Just about to kick #100 [00:36] \o/ [00:36] sil2100: if you like to test download-manager, it just finished: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5110456 [00:37] cyphermox, rsalveti: Last chance! [00:38] lool: yup [00:38] rsalveti: Do you want to kick the build? [00:38] I was seconds away of pressing enter on it :-) [00:38] lool: haha, go for it [00:38] == Building #100 == [00:38] \o/ [00:38] lool: installing and checking! [00:39] I need to agree: \o/ [00:41] ralsina: I tested the change with a click install; it only outputs a (worrying) warning now: 2013-10-17 00:41:19,288 - WARNING - QObject::connect: No such signal SystemNetworkInfo::onlineStateChange(bool) [00:41] ralsina: it used to output it before too [00:42] it's almost not verbose enough [00:42] but we can tweak these [00:42] will see how system-update goes when it's out [00:43] Good night everyone! [00:45] lool: testing here as well, will confirm if I get the same thing [00:45] Ok; gone now! [00:45] lool: goodnight! [00:46] Thanks everyone for the hard work! I'm sure this will be a great image [00:47] lool: good night! [00:49] lool: confirming, I get the same warning - but no other DEBUG messages finally \o/ [00:51] +1 [00:51] well done [00:51] * asac crosses fingers [00:54] Awesome [00:55] Ok guys, see you tomorrow [01:06] will wait and test :-) [01:24] rsalveti: hey! [01:24] I'm back, what's up? [01:25] ah, cool, build 100 === charles_ is now known as charles [01:44] cyphermox: yup [02:25] rsalveti: shouldn't it be done by now? [02:25] rsalveti: oh, it is, nm :) [02:26] plars: flashing :-) [02:27] rsalveti: well, gallery autopilot tests all passed at least on maguro for the first time in a while... that's a good sign, it looks like we still got a systemsettle error [02:27] plars: hm, weird [02:27] plars: the mediaplayer one is an issue with the test itself [02:27] rsalveti: mediaplayer had a crash in maliit-server again :( [02:28] rsalveti: I thought a fix for that was going in already [02:28] plars: where is the crash? [02:28] just saw the systemsettle, but probably because of udev [02:29] rsalveti: on mako: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/100:20131017:20131015/4765/mediaplayer-app-autopilot/ [02:29] oh, ok [02:29] rsalveti: on maguro it just had some failures [02:30] yeah [02:30] hm, is it the same crash? [02:30] let me get some info [02:30] rsalveti: confirmed - system-udevd on the systemsettle [02:31] rsalveti: argh - unity8 23 failures on mako [02:31] wtf [02:32] rsalveti: https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-mako-smoke-unity8-autopilot/ [02:33] looks like couldn't connect? [02:33] let me flash here too [02:33] seems fine for me [02:35] got just _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash [02:40] notes-app still about the same it seems - 1 failure (seems to hover between 1 and 2) [02:40] rsalveti: oh very nice - webbrowser finally down to 0 failures (except systemsettle) on maguro! [02:41] great [02:42] wow, unity8 failed for both mir and SF [02:42] and producing a unity8 crash [02:43] seems something is still not right with unity8 then [02:57] plars: failures with maguro as well [02:58] rsalveti: yeah :( [02:58] plars: did you try running the tests locally? [02:58] rsalveti: not yet, need to check on my flash... I'm flipping back and forth between this and saucy iso tests [02:59] we got a respin a while ago, so everything has to be redone [02:59] ok, starting now [03:00] (the tests, not the flash) [03:00] cool [03:11] rsalveti: ok, found the unity8 problem [03:11] rsalveti: http://paste.ubuntu.com/6249034/ [03:12] plars: hm, but what changed to cause that? [03:17] rsalveti: phablet-click-test-setup is pulling in gi there I guess? not sure why it would need or want to rather than use the one installed on the system though [03:17] right [03:18] rsalveti: let me try something locally, if it works there may be an easy fix [03:18] s/fix/workaround [03:19] because if that's the only thing causing it to fail, then the failure is bogus [03:19] yup [03:20] rsalveti: nm, I think that's just something I'm seeing locally, but I have a newer phablet-tools than what's in the lab [03:21] plars: right [03:21] rsalveti: I removed the /home/phablet/autopilot/gi dir locally and now I'm seeing something more like what we see in the jenkins results, but I see nothing happening on the screen [03:21] plars: I'm just trying to run autopilot locally without phablet-tools [03:21] yeah, seems it just hangs [03:21] boo :( [03:22] plars: and there's a crash [03:22] autopilot unity8 -> crash [03:22] let me get the st [03:23] plars: did you get the maliit-server crash locally? [03:23] rsalveti: not on this run at least, this time I just got unity8 crashing [03:23] right [03:23] same here [03:24] argh, unity8-dbgsym is still based on the older version [03:24] unity8-dbgsym : Depends: unity8 (= 7.83+13.10.20131016.1-0ubuntu1) but 7.83+13.10.20131016.2-0ubuntu1 is to be installed [03:29] plars: do you have the bug number for the previous maliit issue? [03:30] rsalveti: https://bugs.launchpad.net/mir/+bug/1233988 maybe? [03:30] Ubuntu bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] [03:30] BFD: Warning: /home/phablet/crash/gdb/CoreDump is truncated: expected core file size >= 1736704, found: 61440. [03:30] argh [03:31] rsalveti: we may have to get it locally, there are some issues with apport blocking us from using the tool that waits until it knows the crash file is complete [03:31] and uploaded [03:32] right, was able to get it from mako's results [03:32] plars: http://paste.ubuntu.com/6249098/ [03:32] raw = 0xfe3010 "QUbuntu: Could not create application instance" [03:33] seems different [03:33] let me get dbg from qt [03:41] plars: guess this maliit-server could be related with the unity8 crash [03:42] rsalveti: maybe... I think at least one result I looked at (mediaplayer) had maliit crash and not unity8 though [03:42] oh, right [03:42] plars: http://paste.ubuntu.com/6249122/ [03:44] rsalveti: that's the more complete version of the previous one right? [03:44] plars: seems so [03:47] plars: I think after that fix it's now failing without crashing inside mir or platform-api [03:48] qtubuntu refuses to start the app, which causes the crash [03:48] let me try to reproduce it here [03:56] plars: mediaplayer-app is the first test case [03:56] plars: I believe what happened is that unity8 wasn't read yet when maliit-server started [03:56] causing that crash [04:00] there's a sleep 2 in there already, might just not be enough [04:00] let me open the bug at least [04:04] plars: bug 1240793 [04:04] bug 1240793 in ubuntu-touch-session (Ubuntu) "maliit-server crashes when starting because qtubuntu cannot create the application instance" [Undecided,New] https://launchpad.net/bugs/1240793 [04:05] now to debug unity8 [04:07] rsalveti: did you try it with a longer sleep? [04:09] it seems a bit terrible to have to put a sleep in an upstart job to wait for something to start [04:11] plars: yeah, wasn't able to reproduce it yet [04:12] guess it depends on the system load during first boot [04:13] plars: so I guess this is not fatal, but it's annoying as we'll get the crash [04:13] rsalveti: yeah [04:14] rsalveti: one thing to be aware of, even though that's the first test in the chain, it *does* reboot before running the test. So it's already been rebooted once [04:15] plars: hm, ok [04:36] plars: #3 0x41d8aa74 in g_log (log_domain=, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=0x418491c0 "No GSettings schemas are installed on the system") at /build/buildd/glib2.0-2.38.0/./glib/gmessages.c:1025 [04:36] unity8 [04:37] too many changes comparing with 99 [04:37] we should spin more images, not less [04:38] rsalveti: more images with fewer changes you mean [04:38] right? [04:38] plars: yeah [04:38] yes [04:38] otherwise it's hard to track down regressions [04:39] rsalveti: it still seems hard to me to really track what *exactly* changed from one image to the next, especially when you have changes in click, changes in packages, changes might be in android, or scripts... [04:40] indeed [04:40] rsalveti: it takes a while for a change to make it all the way through from a merge proposal to the image, when that process is expensive it encourages trying to get a lot into an image at once [04:41] plars: exactly, but then it's hard to track down differences [04:41] for a good CI we'd have tons of images [04:42] and proper changelog between them [04:42] rsalveti: agree, but what I'm saying is that for that to happen, we need to be able to propagate a change pretty quickly from an approved merge proposal to an image [04:43] plars: yeah, we need to eliminate the current process and replace with a better one [04:43] more automated one [04:43] and try to keep at least the same quality [04:45] plars: finally, the bt http://paste.ubuntu.com/6249310/ [04:45] had to install a few qt dbg packages [04:47] #4 0x417fe118 in g_settings_set_property (object=0x96a818, prop_id=, value=, pspec=) at /build/buildd/glib2.0-2.38.0/./gio/gsettings.c:487 [04:47] schema_id = 0x9042b0 "com.canonical.Unity.Dash" [04:47] #3 0x41d8aa74 in g_log (log_domain=, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=0x418491c0 "No GSettings schemas are installed on the system") at /build/buildd/glib2.0-2.38.0/./glib/gmessages.c:1025 [04:48] now why this only happens with autopilot I'm not yet sure [04:54] plars: bug 1240801 [04:54] bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Critical,New] https://launchpad.net/bugs/1240801 [05:18] plars: weird, it fails for me with 99 as well [05:19] rsalveti: probably something the unity guys are going to need to investigate in the morning [05:19] plars: yeah, how are you testing unity8? [05:19] maybe Saviq? [05:19] just installed 99, installed the autopilot package, stop unity8 and autopilot run unity8 [05:19] plars: yeah, sent an email already [05:20] rsalveti: I don't have anything other than the ap tests and general usage [05:20] what(): bind: Address already in use [05:20] argh, seems it's because of mir now [05:22] yeah, failing hard here, let me do a clean flash again [05:25] rsalveti: thanks for looking at this one, let me flash and have a look as well [05:25] * didrocks looks at unity8 commits [05:26] didrocks: yeah, the results are bad basically because it failed to start the first one already [05:26] for unity8 [05:26] is it the same on the image? unity8 doesn't start at all then? [05:27] didrocks: seems unity8 is working fine, but can trigger the autotest based tests [05:27] interesting [05:27] didrocks: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/100:20131017:20131015/4765/unity8-autopilot/ [05:27] *can't [05:28] hum, no "com.canonical.Unity.Dash" [05:28] fth? [05:29] * didrocks flashes his device [05:29] yeah, didn't get, maybe I'm missing something when starting unity8 here [05:29] just did stop unity8; autopilot run unity8 [05:30] rsalveti: and you can reproduce locally? [05:30] trying to find a crash that's not corrupted from the dashboard [05:30] yeah [05:30] didrocks: flash 100 and test [05:30] rsalveti: download in progress [05:30] rsalveti: gsettings get com.canonical.Unity.Dash scopes is working for you? [05:30] I tested here and got that crash which I reported [05:31] didrocks: reflashing as well [05:31] hum, I don't see anything changing for this in unity8 trunk… [05:32] only libunity is accessing that property, but we didn't change it IIRC [05:32] * didrocks checks [05:38] rsalveti: I didn't get any crash file [05:38] didrocks: with autopilot? [05:38] without right now [05:38] right, it fails only with autopilot it seems [05:39] so, turning the image rw [05:39] gsettings get com.canonical.Unity.Dash scopes [05:39] ['music.scope', 'home.scope', 'applications.scope', 'video.scope'] [05:39] sounds good at least [05:40] good [05:40] (rebooting and launching unity8 AP) [05:43] rsalveti: ok, getting the crash [05:43] the crash file is small though… [05:43] (too small to be valid) [05:43] didrocks: hm [05:43] trying here as well [05:45] at least dbgsym packages are in sync now [05:45] rsalveti: yeah… I'm retracing this crash, but with 4 frames, I have few hopes [05:47] didrocks: what is the size? [05:47] 600k [05:47] mine is 4.6M [05:47] yeah, sounds better [05:47] (got until 11M) [05:48] also got the maliit-server one at the same time [05:48] rsalveti: same, maliit was supposed to be workeded, but not fixed AFAIK [05:48] it's launching after unity8 + 2s [05:48] didrocks: got it [05:48] yeah [05:49] workarounded* [05:50] didrocks: got the same crash at least http://paste.ubuntu.com/6249493/ [05:50] it might be an issue when bringing unity8 down and up or similar [05:50] let me try just one test [05:50] rsalveti: yeah, I wonder if it's not an environment issue [05:52] rsalveti: same crash here [05:52] (not so busted then) [05:52] yeah [05:52] == ProcEnviron ================================= [05:52] LANGUAGE=en_US:en [05:52] LD_LIBRARY_PATH= [05:52] TERM=linux [05:52] PATH=(custom, no user) [05:52] XDG_RUNTIME_DIR= [05:52] LANG=en_US.UTF-8 [05:52] SHELL=/bin/bash [05:52] seems quite small [05:52] indeed [05:52] * didrocks reboots and look at the unity8 autostarted proc env [05:53] missing the QT stuff [05:53] right [05:54] didrocks: way more stuff [05:54] right [05:54] maybe autopilot is cleaning up the env? [05:54] weird [05:54] rsalveti: well, we would have the issue for long ago [05:54] autopilot didn't change [05:54] right [05:54] phablet-tools changed, but for downloading from another server [05:54] nothing in phablet-test-run [05:55] yeah, and autopilot works fine for other test cases [05:55] right [05:55] * didrocks looks at the image diff, just in case [05:56] knowing the changes in, the only ones that can be linked are unity8 and ubuntu-touch-session [05:56] oh, we changed the upstart job for unity8 [05:56] maybe the way phablet-test-run invokes it isn't the right one anymore? [05:57] maybe [05:57] but then it's something in the upstart side [05:57] as I called autopilot run unity8 directly [05:57] as phablet [05:57] rsalveti: "initctl start unity8" [05:57] I don't know upstart session side, but shouldn't it be just start unity8? [05:57] sorry, not upstart side, autopilot side [05:57] my brain is useless already [05:57] "already" :-) [05:58] rsalveti: heh ;) are you using autopilot directly or phablet-test-run? [05:58] I belive so [05:58] autopilot directly [05:58] ah, yeah, can be in autopilot then [05:58] had the same results with phablet-test-run though [05:58] right, so maybe the way autopilot starts unity8 isn't right [05:58] * didrocks really hopes we'll find something around that, it really seems a testing env issue [05:59] thomi: hey, around? [05:59] veebers: as well ^ [05:59] autopilot run unity8.application_lifecycle.tests.test_application_lifecycle.ApplicationLifecycleTests.test_app_moves_from_unfocused_to_focused [05:59] a little bit [05:59] is already enough for the crash [05:59] thomi: we can't start unity8 with autopilot in image 100, we are getting weird crash (like no gsettings schema) [06:00] thomi: the unity8 upstart job changed, can it be autopilot needs to be adapated? [06:00] hmmm. unity8 is crashing, or autopilot? [06:00] thomi: unity8, because of no gsettings schema [06:00] autopilot is triggering a crash in unity8 :-) [06:00] didrocks: the autopilot test suite might need to be changed, yeah [06:00] but it seems a lot of environment variables are missing [06:01] AIUI, the test suite basically does 'initctl set-env QT_LOAD_TESTABILITY=1 && start unity8' [06:01] then looks for the autopilot interface [06:01] so if the upstart job has changed such that that won't work any more, then someone will need up update the test suite [06:01] veebers would know more about hat [06:01] *that [06:01] hum grep -r initctl /usr/lib/python2.7/dist-packages/unity8/* [06:01] (nothing) [06:02] but 1240801 btw [06:02] bug 1240801 [06:02] bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Critical,New] https://launchpad.net/bugs/1240801 [06:02] rsalveti: hum, sorry? ;) [06:02] ah [06:02] :) [06:02] :-) [06:02] rsalveti: my brain isn't wired up as well [06:03] I'm pretty sure it's an env issue, digging… [06:03] didrocks: yeah [06:04] didrocks: tests/autopilot/unity8/shell/tests/__init__.py line 273 [06:04] is where it's launched [06:04] I gotta go now though, but that should get you started :-) [06:04] thomi: yeah, I was just around that place! thanks :) [06:07] rsalveti: even QT_LOAD_TESTABILITY isn't in the env though [06:08] didrocks: right [06:08] oh oh [06:08] let me check something [06:12] (the phone is so long to reboot…) [06:13] hum no, theory busted :/ [06:14] rsalveti: we added a rewpan in the upstart job, I was thinking it can interfere with what autopilot was doing [06:14] but no [06:14] right [06:15] rsalveti: so that we run autopilot the same way, you just log as phablet and autopilot run …? [06:15] yup [06:15] ssh [06:15] autopilot run [06:15] after stop unity8 [06:15] ok, same here [06:16]