[00:00] <rsalveti> lool: ^?
[00:00] <ralsina> lool: it does look pretty harmless
[00:01] <lool> popey: Yeah, or from T
[00:01] <lool> popey: technically we can still land tomorrow morning in archive or -updates, with paperwork for SRU
[00:02] <lool> or starting friday or monday in T
[00:02] <lool> Saviq: unity8-fake-env's new mock dir is harmless, yes?
[00:05] <lool> Forgot to note it here but I published unity8 to proposed a while ago
[00:05] <popey> lool: so we'll do system updates for phone?
[00:06] <popey> 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] <sil2100> popey: I'm testing the new qtorganizer5-eds aaand...
[00:06] <popey> (apologies if this is all well known, I haven't seen many discussions about post-13.10 updates to touch)
[00:07] <sil2100> popey: it seems I can save an alarm, but I can't edit it or disable it :|
[00:07] <lool> popey: yup
[00:07] <lool> popey: TBH the next days are not crystal clear to me either
[00:07] <lool> and the update frequency is also unclear
[00:08] <lool> every week, every month etc.
[00:08] <lool> but we will update the stable imge
[00:08] <lool> I dont know whether we'll update *stable* or *devel* every month for instance
[00:09] <Saviq> lool, yeah, it's just about AP tests
[00:09] <popey> right
[00:09] <popey> so for core apps we're golden because we can deliver updates through the store
[00:09] <lool> popey: exactly
[00:09] <popey> but for system components like the ones above we're really stuck
[00:10] <lool> popey: note that I'd like to tighten the way they get into an image
[00:10] <popey> hence me being keen to get them in 100
[00:10] <lool> popey: it shouldn't stop users getting the latest from app store
[00:10] <lool> popey: via click updater
[00:10] <popey> yeah, we'll gate core apps
[00:10] <lool> popey: but right now we have no way to gate
[00:10] <lool> right
[00:10] <popey> they can't be updated by the core apps devs
[00:10] <popey> well we do
[00:10] <lool> well at the appstore level, right
[00:10] <popey> sergio has added them all to the store under a separate email account
[00:10] <popey> so we can manually update
[00:10] <popey> which is okay for now
[00:11] <popey> clearly not long term sustainable solution, and doesn't fix the issue in hand
[00:11] <sil2100> 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] <sil2100> popey: so clearly there seems to be something wrong here
[00:12] <popey> it wont do anything
[00:12] <popey> until you have charles' bits in
[00:12] <popey> which should trigger a notification
[00:12] <sil2100> I thought charles bits were only about informing about alarms on the indicator
[00:12] <sil2100> Ah, ok
[00:12] <sil2100> Still, not being able to disable an alarm is a big problem IMO
[00:12] <popey> renato fixed saving in eds, charles enabled notification from indicator-datetime
[00:13] <sil2100> If we get the bits that charles has, people will be stuck with alarms once they create them
[00:13] <popey> i dont know where the broken bit is with regards to editing alarms
[00:13] <popey> whether thats in clock or eds or somewhere else
[00:14] <sil2100> Hi charles_
[00:21] <sil2100> 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] <popey> well, "no possibility" can be fixed ☻
[00:21] <sil2100> Indeed ;)
[00:22] <lool> sil2100: well...
[00:22] <sil2100> But will we be able to do that before release?
[00:22] <popey> indeed
[00:22] <lool> sil2100: I'll ask back: what was didrocks recommendation?
[00:22] <lool> I think he wanted a working story; it seems it's half working
[00:22] <lool> net improvement
[00:22] <lool> but still partial, another landing etc.
[00:23] <sil2100> 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] <lool> I think we will have to document a known bug in either case
[00:23] <lool> 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] <lool> worst case, it comes in the first update
[00:23] <popey> Sounds reasonable.
[00:24] <sil2100> Indeed
[00:24] <sil2100> lool: do you need help in anything else right now?
[00:25] <lool> sil2100: I'm good!
[00:25] <lool> sil2100: we can test the download-manager in PPA in a few
[00:25] <lool> for system-updates and for clicks
[00:25] <lool> I intend to jsut test for click
[00:25] <lool> as a side thing
[00:26] <lool> (and with system-image when the next image comes out)
[00:26] <lool> gosh, unity8 in release pocket from DB, waiting on publisher
[00:30] <lool> cyphermox: around?
[00:33] <lool> rsalveti: around?
[00:33] <lool> Now's the time
[00:36] <sil2100> What do we need to test?
[00:36] <lool> sil2100: Just about to kick #100
[00:36] <sil2100> \o/
[00:36] <lool> sil2100: if you like to test download-manager, it just finished: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5110456
[00:37] <lool> cyphermox, rsalveti: Last chance!
[00:38] <rsalveti> lool: yup
[00:38] <lool> rsalveti: Do you want to kick the build?
[00:38] <lool> I was seconds away of pressing enter on it  :-)
[00:38] <rsalveti> lool: haha, go for it
[00:38] <lool> == Building #100 ==
[00:38] <rsalveti> \o/
[00:38] <sil2100> lool: installing and checking!
[00:39] <lool> I need to agree: \o/
[00:41] <lool> 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] <lool> ralsina: it used to output it before too
[00:42] <lool> it's almost not verbose enough
[00:42] <lool> but we can tweak these
[00:42] <lool> will see how system-update goes when it's out
[00:43] <lool> Good night everyone!
[00:45] <sil2100> lool: testing here as well, will confirm if I get the same thing
[00:45] <lool> Ok; gone now!
[00:45] <sil2100> lool: goodnight!
[00:46] <lool> Thanks everyone for the hard work!  I'm sure this will be a great image
[00:47] <ralsina> lool: good night!
[00:49] <sil2100> lool: confirming, I get the same warning - but no other DEBUG messages finally \o/
[00:51] <asac> +1
[00:51] <asac> well done
[00:51]  * asac crosses fingers
[00:54] <sil2100> Awesome
[00:55] <sil2100> Ok guys, see you tomorrow
[01:06] <rsalveti> will wait and test :-)
[01:24] <cyphermox> rsalveti: hey!
[01:24] <cyphermox> I'm back, what's up?
[01:25] <cyphermox> ah, cool, build 100
[01:44] <rsalveti> cyphermox: yup
[02:25] <plars> rsalveti: shouldn't it be done by now?
[02:25] <plars> rsalveti: oh, it is, nm :)
[02:26] <rsalveti> plars: flashing :-)
[02:27] <plars> 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] <rsalveti> plars: hm, weird
[02:27] <rsalveti> plars: the mediaplayer one is an issue with the test itself
[02:27] <plars> rsalveti: mediaplayer had a crash in maliit-server again :(
[02:28] <plars> rsalveti: I thought a fix for that was going in already
[02:28] <rsalveti> plars: where is the crash?
[02:28] <rsalveti> just saw the systemsettle, but probably because of udev
[02:29] <plars> rsalveti: on mako: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/100:20131017:20131015/4765/mediaplayer-app-autopilot/
[02:29] <rsalveti> oh, ok
[02:29] <plars> rsalveti: on maguro it just had some failures
[02:30] <rsalveti> yeah
[02:30] <rsalveti> hm, is it the same crash?
[02:30] <rsalveti> let me get some info
[02:30] <plars> rsalveti: confirmed - system-udevd on the systemsettle
[02:31] <plars> rsalveti: argh - unity8 23 failures on mako
[02:31] <rsalveti> wtf
[02:32] <plars> rsalveti: https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-mako-smoke-unity8-autopilot/
[02:33] <plars> looks like couldn't connect?
[02:33] <plars> let me flash here too
[02:33] <rsalveti> seems fine for me
[02:35] <rsalveti> got just _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[02:40] <plars> notes-app still about the same it seems - 1 failure (seems to hover between 1 and 2)
[02:40] <plars> rsalveti: oh very nice - webbrowser finally down to 0 failures (except systemsettle) on maguro!
[02:41] <rsalveti> great
[02:42] <rsalveti> wow, unity8 failed for both mir and SF
[02:42] <rsalveti> and producing a unity8 crash
[02:43] <rsalveti> seems something is still not right with unity8 then
[02:57] <rsalveti> plars: failures with maguro as well
[02:58] <plars> rsalveti: yeah :(
[02:58] <rsalveti> plars: did you try running the tests locally?
[02:58] <plars> rsalveti: not yet, need to check on my flash... I'm flipping back and forth between this and saucy iso tests
[02:59] <plars> we got a respin a while ago, so everything has to be redone
[02:59] <plars> ok, starting now
[03:00] <plars> (the tests, not the flash)
[03:00] <rsalveti> cool
[03:11] <plars> rsalveti: ok, found the unity8 problem
[03:11] <plars> rsalveti: http://paste.ubuntu.com/6249034/
[03:12] <rsalveti> plars: hm, but what changed to cause that?
[03:17] <plars> 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] <rsalveti> right
[03:18] <plars> rsalveti: let me try something locally, if it works there may be an easy fix
[03:18] <plars> s/fix/workaround
[03:19] <plars> because if that's the only thing causing it to fail, then the failure is bogus
[03:19] <rsalveti> yup
[03:20] <plars> 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] <rsalveti> plars: right
[03:21] <plars> 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] <rsalveti> plars: I'm just trying to run autopilot locally without phablet-tools
[03:21] <rsalveti> yeah, seems it just hangs
[03:21] <plars> boo :(
[03:22] <rsalveti> plars: and there's a crash
[03:22] <rsalveti> autopilot unity8 -> crash
[03:22] <rsalveti> let me get the st
[03:23] <rsalveti> plars: did you get the maliit-server crash locally?
[03:23] <plars> rsalveti: not on this run at least, this time I just got unity8 crashing
[03:23] <rsalveti> right
[03:23] <rsalveti> same here
[03:24] <rsalveti> argh, unity8-dbgsym is still based on the older version
[03:24] <rsalveti>  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] <rsalveti> plars: do you have the bug number for the previous maliit issue?
[03:30] <plars> rsalveti: https://bugs.launchpad.net/mir/+bug/1233988 maybe?
[03:30] <rsalveti> BFD: Warning: /home/phablet/crash/gdb/CoreDump is truncated: expected core file size >= 1736704, found: 61440.
[03:30] <rsalveti> argh
[03:31] <plars> 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] <plars> and uploaded
[03:32] <rsalveti> right, was able to get it from mako's results
[03:32] <rsalveti> plars: http://paste.ubuntu.com/6249098/
[03:32] <rsalveti>         raw = 0xfe3010 "QUbuntu: Could not create application instance"
[03:33] <rsalveti> seems different
[03:33] <rsalveti> let me get dbg from qt
[03:41] <rsalveti> plars: guess this maliit-server could be related with the unity8 crash
[03:42] <plars> rsalveti: maybe... I think at least one result I looked at  (mediaplayer) had maliit crash and not unity8 though
[03:42] <rsalveti> oh, right
[03:42] <rsalveti> plars: http://paste.ubuntu.com/6249122/
[03:44] <plars> rsalveti: that's the more complete version of the previous one right?
[03:44] <rsalveti> plars: seems so
[03:47] <rsalveti> plars: I think after that fix it's now failing without crashing inside mir or platform-api
[03:48] <rsalveti> qtubuntu refuses to start the app, which causes the crash
[03:48] <rsalveti> let me try to reproduce it here
[03:56] <rsalveti> plars: mediaplayer-app is the first test case
[03:56] <rsalveti> plars: I believe what happened is that unity8 wasn't read yet when maliit-server started
[03:56] <rsalveti> causing that crash
[04:00] <rsalveti> there's a sleep 2 in there already, might just not be enough
[04:00] <rsalveti> let me open the bug at least
[04:04] <rsalveti> plars: bug 1240793
[04:05] <rsalveti> now to debug unity8
[04:07] <plars> rsalveti: did you try it with a longer sleep?
[04:09] <plars> it seems a bit terrible to have to put a sleep in an upstart job to wait for something to start
[04:11] <rsalveti> plars: yeah, wasn't able to reproduce it yet
[04:12] <rsalveti> guess it depends on the system load during first boot
[04:13] <rsalveti> plars: so I guess this is not fatal, but it's annoying as we'll get the crash
[04:13] <plars> rsalveti: yeah
[04:14] <plars> 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] <rsalveti> plars: hm, ok
[04:36] <rsalveti> plars: #3  0x41d8aa74 in g_log (log_domain=<optimized out>, 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] <rsalveti> unity8
[04:37] <rsalveti> too many changes comparing with 99
[04:37] <rsalveti> we should spin more images, not less
[04:38] <plars> rsalveti: more images with fewer changes you mean
[04:38] <plars> right?
[04:38] <rsalveti> plars: yeah
[04:38] <plars> yes
[04:38] <rsalveti> otherwise it's hard to track down regressions
[04:39] <plars> 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] <rsalveti> indeed
[04:40] <plars> 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] <rsalveti> plars: exactly, but then it's hard to track down differences
[04:41] <rsalveti> for a good CI we'd have tons of images
[04:42] <rsalveti> and proper changelog between them
[04:42] <plars> 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] <rsalveti> plars: yeah, we need to eliminate the current process and replace with a better one
[04:43] <rsalveti> more automated one
[04:43] <rsalveti> and try to keep at least the same quality
[04:45] <rsalveti> plars: finally, the bt http://paste.ubuntu.com/6249310/
[04:45] <rsalveti> had to install a few qt dbg packages
[04:47] <rsalveti> #4  0x417fe118 in g_settings_set_property (object=0x96a818, prop_id=<optimized out>, value=<optimized out>, pspec=<optimized out>) at /build/buildd/glib2.0-2.38.0/./gio/gsettings.c:487
[04:47] <rsalveti>         schema_id = 0x9042b0 "com.canonical.Unity.Dash"
[04:47] <rsalveti> #3  0x41d8aa74 in g_log (log_domain=<optimized out>, 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] <rsalveti> now why this only happens with autopilot I'm not yet sure
[04:54] <rsalveti> plars: bug 1240801
[05:18] <rsalveti> plars: weird, it fails for me with 99 as well
[05:19] <plars> rsalveti: probably something the unity guys are going to need to investigate in the morning
[05:19] <rsalveti> plars: yeah, how are you testing unity8?
[05:19] <plars> maybe Saviq?
[05:19] <rsalveti> just installed 99, installed the autopilot package, stop unity8 and autopilot run unity8
[05:19] <rsalveti> plars: yeah, sent an email already
[05:20] <plars> rsalveti: I don't have anything other than the ap tests and general usage
[05:20] <rsalveti>   what():  bind: Address already in use
[05:20] <rsalveti> argh, seems it's because of mir now
[05:22] <rsalveti> yeah, failing hard here, let me do a clean flash again
[05:25] <didrocks> 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] <rsalveti> didrocks: yeah, the results are bad basically because it failed to start the first one already
[05:26] <rsalveti> for unity8
[05:26] <didrocks> is it the same on the image? unity8 doesn't start at all then?
[05:27] <rsalveti> didrocks: seems unity8 is working fine, but can trigger the autotest based tests
[05:27] <didrocks> interesting
[05:27] <rsalveti> didrocks: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/100:20131017:20131015/4765/unity8-autopilot/
[05:27] <rsalveti> *can't
[05:28] <didrocks> hum, no "com.canonical.Unity.Dash"
[05:28] <didrocks> fth?
[05:29]  * didrocks flashes his device
[05:29] <rsalveti> yeah, didn't get, maybe I'm missing something when starting unity8 here
[05:29] <rsalveti> just did stop unity8; autopilot run unity8
[05:30] <didrocks> rsalveti: and you can reproduce locally?
[05:30] <rsalveti> trying to find a crash that's not corrupted from the dashboard
[05:30] <didrocks> yeah
[05:30] <rsalveti> didrocks: flash 100 and test
[05:30] <didrocks> rsalveti: download in progress
[05:30] <didrocks> rsalveti: gsettings get com.canonical.Unity.Dash scopes is working for you?
[05:30] <rsalveti> I tested here and got that crash which I reported
[05:31] <rsalveti> didrocks: reflashing as well
[05:31] <didrocks> hum, I don't see anything changing for this in unity8 trunk…
[05:32] <didrocks> only libunity is accessing that property, but we didn't change it IIRC
[05:32]  * didrocks checks
[05:38] <didrocks> rsalveti: I didn't get any crash file
[05:38] <rsalveti> didrocks: with autopilot?
[05:38] <didrocks> without right now
[05:38] <rsalveti> right, it fails only with autopilot it seems
[05:39] <didrocks> so, turning the image rw
[05:39] <didrocks> gsettings get com.canonical.Unity.Dash scopes
[05:39] <didrocks> ['music.scope', 'home.scope', 'applications.scope', 'video.scope']
[05:39] <didrocks> sounds good at least
[05:40] <rsalveti> good
[05:40] <didrocks> (rebooting and launching unity8 AP)
[05:43] <didrocks> rsalveti: ok, getting the crash
[05:43] <didrocks> the crash file is small though…
[05:43] <didrocks> (too small to be valid)
[05:43] <rsalveti> didrocks: hm
[05:43] <rsalveti> trying here as well
[05:45] <rsalveti> at least dbgsym packages are in sync now
[05:45] <didrocks> rsalveti: yeah… I'm retracing this crash, but with 4 frames, I have few hopes
[05:47] <rsalveti> didrocks: what is the size?
[05:47] <didrocks> 600k
[05:47] <rsalveti> mine is 4.6M
[05:47] <didrocks> yeah, sounds better
[05:47] <didrocks> (got until 11M)
[05:48] <rsalveti> also got the maliit-server one at the same time
[05:48] <didrocks> rsalveti: same, maliit was supposed to be workeded, but not fixed AFAIK
[05:48] <didrocks> it's launching after unity8 + 2s
[05:48] <rsalveti> didrocks: got it
[05:48] <rsalveti> yeah
[05:49] <didrocks> workarounded*
[05:50] <rsalveti> didrocks: got the same crash at least http://paste.ubuntu.com/6249493/
[05:50] <rsalveti> it might be an issue when bringing unity8 down and up or similar
[05:50] <rsalveti> let me try just one test
[05:50] <didrocks> rsalveti: yeah, I wonder if it's not an environment issue
[05:52] <didrocks> rsalveti: same crash here
[05:52] <didrocks> (not so busted then)
[05:52] <rsalveti> yeah
[05:52] <didrocks> == ProcEnviron [05:52] <didrocks> LANGUAGE=en_US:en
[05:52] <didrocks> LD_LIBRARY_PATH=<set>
[05:52] <didrocks> TERM=linux
[05:52] <didrocks> PATH=(custom, no user)
[05:52] <didrocks> XDG_RUNTIME_DIR=<set>
[05:52] <didrocks> LANG=en_US.UTF-8
[05:52] <didrocks> SHELL=/bin/bash
[05:52] <didrocks> seems quite small
[05:52] <rsalveti> indeed
[05:52]  * didrocks reboots and look at the unity8 autostarted proc env
[05:53] <rsalveti> missing the QT stuff
[05:53] <didrocks> right
[05:54] <rsalveti> didrocks: way more stuff
[05:54] <didrocks> right
[05:54] <rsalveti> maybe autopilot is cleaning up the env?
[05:54] <rsalveti> weird
[05:54] <didrocks> rsalveti: well, we would have the issue for long ago
[05:54] <didrocks> autopilot didn't change
[05:54] <rsalveti> right
[05:54] <didrocks> phablet-tools changed, but for downloading from another server
[05:54] <didrocks> nothing in phablet-test-run
[05:55] <rsalveti> yeah, and autopilot works fine for other test cases
[05:55] <didrocks> right
[05:55]  * didrocks looks at the image diff, just in case
[05:56] <didrocks> knowing the changes in, the only ones that can be linked are unity8 and ubuntu-touch-session
[05:56] <didrocks> oh, we changed the upstart job for unity8
[05:56] <didrocks> maybe the way phablet-test-run invokes it isn't the right one anymore?
[05:57] <rsalveti> maybe
[05:57] <rsalveti> but then it's something in the upstart side
[05:57] <rsalveti> as I called autopilot run unity8 directly
[05:57] <rsalveti> as phablet
[05:57] <didrocks> rsalveti: "initctl start unity8"
[05:57] <didrocks> I don't know upstart session side, but shouldn't it be just start unity8?
[05:57] <rsalveti> sorry, not upstart side, autopilot side
[05:57] <rsalveti> my brain is useless already
[05:57] <rsalveti> "already" :-)
[05:58] <didrocks> rsalveti: heh ;) are you using autopilot directly or phablet-test-run?
[05:58] <rsalveti> I belive so
[05:58] <rsalveti> autopilot directly
[05:58] <didrocks> ah, yeah, can be in autopilot then
[05:58] <rsalveti> had the same results with phablet-test-run though
[05:58] <didrocks> 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] <didrocks> thomi: hey, around?
[05:59] <didrocks> veebers: as well ^
[05:59] <rsalveti> autopilot run unity8.application_lifecycle.tests.test_application_lifecycle.ApplicationLifecycleTests.test_app_moves_from_unfocused_to_focused
[05:59] <thomi> a little bit
[05:59] <rsalveti> is already enough for the crash
[05:59] <didrocks> thomi: we can't start unity8 with autopilot in image 100, we are getting weird crash (like no gsettings schema)
[06:00] <didrocks> thomi: the unity8 upstart job changed, can it be autopilot needs to be adapated?
[06:00] <thomi> hmmm. unity8 is crashing, or autopilot?
[06:00] <didrocks> thomi: unity8, because of no gsettings schema
[06:00] <rsalveti> autopilot is triggering a crash in unity8 :-)
[06:00] <thomi> didrocks: the autopilot test suite might need to be changed, yeah
[06:00] <didrocks> but it seems a lot of environment variables are missing
[06:01] <thomi> AIUI, the test suite basically does 'initctl set-env QT_LOAD_TESTABILITY=1 && start unity8'
[06:01] <thomi> then looks for the autopilot interface
[06:01] <thomi> 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] <thomi> veebers would know more about hat
[06:01] <thomi> *that
[06:01] <didrocks> hum grep -r initctl /usr/lib/python2.7/dist-packages/unity8/*
[06:01] <didrocks> (nothing)
[06:02] <rsalveti> but 1240801 btw
[06:02] <rsalveti> bug 1240801
[06:02] <didrocks> rsalveti: hum, sorry? ;)
[06:02] <didrocks> ah
[06:02] <didrocks> :)
[06:02] <rsalveti> :-)
[06:02] <didrocks> rsalveti: my brain isn't wired up as well
[06:03] <didrocks> I'm pretty sure it's an env issue, digging…
[06:03] <rsalveti> didrocks: yeah
[06:04] <thomi> didrocks: tests/autopilot/unity8/shell/tests/__init__.py line 273
[06:04] <thomi> is where it's launched
[06:04] <thomi> I gotta go now though, but that should get you started :-)
[06:04] <didrocks> thomi: yeah, I was just around that place! thanks :)
[06:07] <didrocks> rsalveti: even QT_LOAD_TESTABILITY isn't in the env though
[06:08] <rsalveti> didrocks: right
[06:08] <didrocks> oh oh
[06:08] <didrocks> let me check something
[06:12] <didrocks> (the phone is so long to reboot…)
[06:13] <didrocks> hum no, theory busted :/
[06:14] <didrocks> rsalveti: we added a rewpan in the upstart job, I was thinking it can interfere with what autopilot was doing
[06:14] <didrocks> but no
[06:14] <rsalveti> right
[06:15] <didrocks> rsalveti: so that we run autopilot the same way, you just log as phablet and autopilot run …?
[06:15] <rsalveti> yup
[06:15] <rsalveti> ssh
[06:15] <rsalveti> autopilot run
[06:15] <rsalveti> after stop unity8
[06:15] <didrocks> ok, same here
[06:16] <didrocks> yeah, so confirm in job logs:
[06:17] <didrocks> __pthread_gettid -2
[06:17] <didrocks> WARNING: QApplication was not created in the main() thread.
[06:17] <didrocks> loaded the dummy plugin
[06:17] <didrocks> loaded the Linux plugin
[06:17] <didrocks> Registered the AalSensorPlugin types
[06:17] <didrocks> Loading testability driver.
[06:17] <didrocks> Missing "com.canonical.Unity.Lenses" schema
[06:17] <didrocks> (process:3161): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
[06:17] <rsalveti> yeah, wrong env
[06:17] <didrocks> so, at least, we know it's trying to load with the right env
[06:17] <didrocks> Loading testability driver.
[06:17] <didrocks> but can't get to schema (probably due to env, right)
[06:18] <rsalveti> wonder if this is because of the setcap hack
[06:18] <didrocks> well, at this point, let's try all possibilities, but nice catch :)
[06:19] <rsalveti> but it was dropped later on
[06:19] <didrocks> we don't have the version with the drop one in the image
[06:19] <didrocks> so let's try dropping it
[06:20] <rsalveti> right, but it's part of lxc-android-config
[06:20] <rsalveti> https://launchpadlibrarian.net/153936414/lxc-android-config_0.113_0.114.diff.gz
[06:20] <didrocks> oh yeah
[06:21] <didrocks> ok, /me rm
[06:21] <rsalveti> holy, that's an ugly hack
[06:21] <didrocks> yeah, it was after the discussion that we can't convey setcap as the filesystem is ext2 and we generate tarballs
[06:21] <didrocks> so doing that on every boot (yeah :/)
[06:21] <rsalveti> right, but in the end we don't need setcaps at all
[06:22] <rsalveti> we decided that all apps should have score 0 (default)
[06:22] <veebers> didrocks: hey I'm kind of around now
[06:22] <didrocks> rsalveti: oh, really?
[06:22] <rsalveti> and just set to a higher value when moving them to background
[06:22] <didrocks> making sense
[06:22] <didrocks> we go to the extreme everytime we do an hack… happy that we have more reasonable values
[06:22] <rsalveti> otherwise unity8 would have a higher priority (from the out of memory killer perspective) than init
[06:23] <rsalveti> it'd kill first upstart and then unity8 :P
[06:23] <veebers> didrocks, rsalveti: hey will this command flash build 100 on my device? phablet-flash ubuntu-system --channel devel-proposed
[06:23] <didrocks> veebers: right, please do it ;)
[06:23] <veebers> I would like to see if I can help with this issue
[06:23] <rsalveti> yeah
[06:23] <didrocks> that would be really appreciated :)
[06:23] <veebers> cool, flashing now
[06:24] <didrocks> rsalveti: heh, well, I keep hearing the shell is the most important piece of the system for 3 years, so I'm unsure (j/k) ;)
[06:24] <rsalveti> didrocks: haha :-)
[06:24] <rsalveti> didrocks: did it help?
[06:26] <didrocks> rsalveti: all tests fail, I don't see unity8 starting but not crashing either
[06:26] <didrocks> let me see if it's not the powerd/display off thing
[06:26] <rsalveti> didrocks: maybe because of the mir socket
[06:26] <rsalveti> check /run/user/32.../mir_...
[06:27] <didrocks> rsalveti: I have no mir socket (without unity8 running)
[06:27] <didrocks> that's not expected?
[06:27] <rsalveti> right it's fine, I just got in a situation where the test was failing because the socket was still there
[06:27] <didrocks> ok
[06:28] <didrocks> interesting, I even don't see anything anymore in .cache/upstart/unity8.log
[06:28] <didrocks> like if it doesn't even try starting unity8
[06:28] <rsalveti> weird
[06:28] <rsalveti> maybe trying removing the respawn now?
[06:28] <didrocks>     self.grid_size = int(os.getenv('GRID_UNIT_PX'))
[06:28] <didrocks> TypeError: int() argument must be a string or a number, not 'NoneType'
[06:28] <didrocks> for all tests running
[06:28] <didrocks> rsalveti: yeah, let's see
[06:29] <didrocks> hum, not better
[06:29]  * didrocks reboots to ensure
[06:29] <rsalveti> in dev mode, you cannot update the unity8 package because of this bind mount
[06:30] <rsalveti> it'll try to replace it and fails with 'busy'
[06:30] <didrocks> yeah, it's annoying for testing
[06:30] <didrocks> ok rebooted
[06:30] <didrocks> so stopping the shell
[06:30] <rsalveti> slow reboots...
[06:30] <rsalveti> so annoying
[06:30] <didrocks> sudo -u phablet -i sh -lc "initctl stop unity8"
[06:31] <didrocks> powerd-cli display on bright
[06:31] <didrocks> (just to ensure it's not getting off)
[06:31] <plars> not sure if you tried it already, but just out of curiosity I tried removing the setcap hook hack, doesn't look like it's making a difference for me
[06:32] <didrocks> plars: yeah, we're just doing that, ok. so you confirm :/
[06:32] <didrocks> plars: you see that in the tests only as well, right? not when using the image?
[06:32] <plars> didrocks: feel free to try it too, I just removed the file under /etc/init/boot-hooks and reran
[06:32] <didrocks> rsalveti: yeah, so really nothing…
[06:33] <didrocks> plars: confirming
[06:33] <didrocks> why I don't see anything in the upstart log to try running unity8?
[06:35] <didrocks> ah, only running one test at least, tried to start it
[06:35] <didrocks> with the same error thugh
[06:35] <didrocks> though*
[06:35] <didrocks> veebers: so, for clarity, the issue seems that unity8 isn't loaded with the same env than the system one
[06:35] <didrocks> we are getting:
[06:35] <didrocks> Loading testability driver.
[06:35] <didrocks> Missing "com.canonical.Unity.Lenses" schema
[06:36] <didrocks> the schema exists if you try by end
[06:36] <popey> morning phabulous people!
[06:36] <didrocks> (and that's what is making unity8 crashing)
[06:36] <didrocks> hey popey
[06:37] <didrocks> popey: can you upgrade to image 100 and test as much as you can it? (we have an issue, but we start thinking it's a test environment issue)
[06:37] <popey> doing right now
[06:37] <didrocks> if you get unity8 disappearing and not reapparing, ring the alarm bell :)
[06:37] <didrocks> thanks!
[06:37] <popey> http://popey.com/~alan/phablet/device-2013-10-17-073526.png \o/ 100
[06:37] <didrocks> :)
[06:37] <popey> although technically we're way beyond 100 given we reset the counter a couple of months back
[06:37] <popey> but lets not mention that ☻
[06:38] <didrocks> sshhhhh ;)
[06:38] <veebers> didrocks: ah ok odd, there is some patching/mocking happening with the autopilot tests but this looks very broken
[06:38] <rsalveti> right guys, guess you're all on top of this issue already
[06:38] <rsalveti> will get some sleep
[06:38] <didrocks> rsalveti: sure, enjoy! we'll have good news when you wake up :)
[06:38] <didrocks> rsalveti: thanks for the initial debugging!
[06:38] <rsalveti> yeah :-)
[06:39] <rsalveti> np, later and good luck :-)
[06:39] <didrocks> thanks ;)
[06:41] <popey> network indicator shows not connected, but i have an ip address in ifconfig
[06:41] <plars> right, I think I'm going to go get some sleep too... back later
[06:41] <popey> (and network works)
[06:41] <didrocks> plars: see you later! thanks :)
[06:41] <didrocks> popey: maybe a crash? It's working here
[06:41] <popey> http://popey.com/~alan/phablet/device-2013-10-17-074119.png
[06:41] <popey> i am connected to that wifi access point
[06:42] <popey> nothing in /var/crash.. hmmm
[06:42] <didrocks> weird
[06:42] <didrocks> popey: on a fresh intall, I connected for the first time (and it worked)
[06:42] <didrocks> ok, let's keep those in mind
[06:42] <popey> this was an upgrade from 99
[06:42] <didrocks> popey: maybe it will be better to have a complete wipe out?
[06:42] <didrocks> as people will install that image (maybe) from scratch :)
[06:43] <didrocks> and we told we don't really support upgrades
[06:43] <popey> yeah, i usually test both
[06:43] <didrocks> ah ok ;)
[06:48]  * popey reflashes clean
[06:56] <jibel> lool, I tested the upgrader, no big problem so far. main issue is you cannot resume or restart an upgrade if you exit system-settings
[06:56] <jibel> lool, but from all the tests I did, I couldn't brick the pohne
[06:56] <jibel> *phone
[06:56] <didrocks> hey jibel ;)
[06:57] <jibel> Bonjour didrocks, ça va?
[06:57] <didrocks> jibel: bof, la folie depuis ce matin, et toi?
[06:57] <jibel> didrocks, ça va mais j'ai testé jusque minuit et demi et n'ai pas entendu le reveil :/
[06:58] <didrocks> jibel: ça va, c'est encore tôt de toute manière là :)
[06:58] <didrocks> jibel: in case you didn't follow, there is no way to run unity8 AP tests on image 100. It seems to work well on the image, but we are getting a crash on a schema not being installed (which is installed)
[06:59] <didrocks> looking at the env of the crashed unity8 process, it's very poor (not a lot of env variable)
[06:59] <didrocks> we tried to disable multiple things between the 2 images (setcap, respawn…)
[06:59] <jibel> didrocks, okay, I'm flashing 100, is there anything you want me to verify?
[07:00] <didrocks> jibel: first, that the image itself is fine
[07:00] <didrocks> then, if you can help on this AP test front
[07:00] <didrocks> veebers: flashing finished?
[07:00] <veebers> didrocks: only just now, now installing tests
[07:00] <popey> didrocks: missing indicator clock on first clean flash
[07:00] <veebers> didrocks: the internet here is slow :-)
[07:02] <didrocks> popey: I guess the same random crash? (it appears here)
[07:02] <popey> yeah, expect so, will reboot and see
[07:05] <jibel> popey, was the date indicator present?
[07:06] <jibel> popey, nm, I read it as no time on screen lock, this is bug 1239710 but we cannot find a way to reporduce
[07:06] <popey> yes, on second boot
[07:11] <veebers> didrocks: right, I know what's causing it in the autopilot code, now to figure out how to fix it'
[07:12] <popey> clean flash, connected to wifi, and again i see no tick next to the access point I am connected to.. http://popey.com/~alan/phablet/device-2013-10-17-081224.png
[07:12] <didrocks> veebers: oh, can you expand it? are you sure it's due to autopilot?
[07:12] <didrocks> veebers: and that we don't have that in the finale image?
[07:12] <didrocks> (and why it's starting to be triggered now)
[07:13] <didrocks> popey: ah, the tick
[07:13] <didrocks> popey: let me check
[07:13] <didrocks> let me get a shell first :)
[07:13] <didrocks> popey: can you try to downgrade indicator-network?
[07:14] <veebers> didrocks: yeah, there was code added that sets some more env details that appear to be incorrect causing it to crash, if I remove that one line, it works fine
[07:14] <popey> ya
[07:14] <popey> do you know what version I need?
[07:14] <didrocks> veebers: any reference/diff to point me to (just removing the line)? I wonder why we didn't get it before though
[07:14] <didrocks> popey: 0.5.1+13.10.20131011-0ubuntu1
[07:14] <popey> k
[07:14] <didrocks> thanks!
[07:14] <popey> np
[07:15] <veebers> didrocks: it looks like the code was introduced unity8 trunk revno 470
[07:15] <didrocks> but I tried to downgrade unity8…
[07:15]  * didrocks looks
[07:16] <didrocks> veebers: we don't ship rev 470
[07:16]  * didrocks checks again
[07:16] <didrocks> oh, we do ship it
[07:16] <veebers> didrocks: phew, I thought I had screwed something up there :-\
[07:16] <didrocks> ;)
[07:17] <didrocks> ah, so I didn't downgrade the autopilot package
[07:17] <didrocks> let me try
[07:17] <veebers> didrocks: I suspect that should work for you
[07:19] <popey> didrocks: downgraded indicator-network, i still see no tick
[07:19] <didrocks> veebers: \o/
[07:19] <didrocks> popey: hum, is that a regression really from image 100?
[07:19] <didrocks> veebers: my hero! I tried downgrading half of the image but the autopilot tests, thinking we didn't ship tihs
[07:19] <popey> seems not
[07:20] <popey> i have a 99 phone next to it
[07:20] <didrocks> ok, ok good news then
[07:20] <popey> also not showing icon
[07:20] <veebers> didrocks: heh no worries. Sorry I didn't catch this earlier. How old is build 100?
[07:20]  * popey reflashes
[07:20] <didrocks> popey: hum, so maybe a toolkit upgrade? Can you try on other apps having the same tick?
[07:20] <didrocks> veebers: well, few hours, no worry :)
[07:20] <veebers> didrocks: you can re-create the unity8 crash with this command: start unity8 XDG_DATA_DIRS=/usr/share/unity8/mocks/data/applications/
[07:20] <didrocks> veebers: this unity8 commit wasn't supposed to land
[07:20] <popey> didrocks: will look
[07:21] <didrocks> veebers: right, wrong XDG_DATA_DIRS :)
[07:21] <veebers> didrocks: ah right, that makes sense why I had 99 then :-)
[07:21] <veebers> didrocks: yeah
[07:22] <didrocks> veebers: you're going to propose a patch?
[07:23] <veebers> didrocks: Yep I could do, do you know what the correct directory is? I was going to hitup Saviq or mzanetti and ask them otherwise
[07:24] <sil2100> Morning
[07:24] <sil2100> Damn, yesterday I upgraded my desktop and I can't properly boot into graphical mode anymore
[07:25] <didrocks> veebers: I think you should append /usr/share/ at least
[07:29] <didrocks> ok, /me reflashes the image
[07:32] <popey> didrocks: reflashing again, this time clock appears fine and so does the network tick
[07:32] <popey> http://popey.com/~alan/phablet/device-2013-10-17-083228.png
[07:33] <didrocks> popey: the network tick?
[07:33] <didrocks> but but but
[07:33] <didrocks> time clock -> ok, it's the crash
[07:33] <didrocks> but the network tick
[07:33]  * didrocks is puzzled
[07:33] <popey> odd isnt it?
[07:33] <didrocks> really puzzled
[07:33] <didrocks> yeah :)
[07:33] <popey> but not a regression
[07:34] <didrocks> right
[07:34] <popey> as my 99 phone has it too
[07:34] <didrocks> popey: TBH, I'm happy, the unity8 issue is figured out
[07:34] <didrocks> it's not the image
[07:34] <didrocks> I can take my coffee after 2h30 of stress :)
[07:34] <popey> heh
[07:40] <Saviq> jeez
[07:40] <Saviq> didrocks, sorted?
[07:40] <veebers> Saviq: I'll have a MR for you in a moment :-)
[07:41] <didrocks> kind of, we know it doesn't impact the image at least :)
[07:41] <Saviq> wth happened there?
[07:41] <didrocks> Saviq: your commit…
[07:41] <didrocks> Saviq: look at the ue-leads ML
[07:41] <Saviq> didrocks, yeah, but what about it? it was just prepending to X_D_D?
[07:42]  * Saviq hates g...
[07:46] <didrocks> Saviq: yeah, I'm puzzled through the code, that's why I didn't think about this commit being a problem at first
[07:46] <didrocks> Saviq: we prepend many directory on the real install
[07:46] <didrocks> directories*
[07:46] <Saviq> didrocks, but it's empty on the phone?
[07:46] <didrocks> and it still look for the last one
[07:46] <didrocks> Saviq: /usr/share/glib-2.0/schemas/ is not empty
[07:47] <Saviq> didrocks, yeah, but XDG_DATA_DIRS is
[07:47] <didrocks> Saviq: oh, but if it's empty
[07:47] <Saviq> didrocks, but as soon as we put *something* there
[07:47] <didrocks> it looks in /usr/share :p
[07:47] <Saviq> yeah exactly
[07:47] <didrocks> welcome to glib ;)
[07:47] <Saviq> so when empty - we need to put both our override *and* /usr/share...
[07:47] <Saviq> eh
[07:47] <didrocks> yep
[07:48] <didrocks> Saviq: you didn't try the AP tests? (nor lool I guess?)
[07:48] <Saviq> didrocks, I did, but obviously on desktop it worked
[07:48] <didrocks> argh, always test on phone please :/
[07:48] <Saviq> didrocks, and on device I must've had some weird env that it went fine
[07:49] <veebers> Saviq: the os.getenv("XDG_DATA_DIRS") returned None, but it's initctl get-env that we're interested in
[07:49] <didrocks> Saviq: at least, it doesn't impact the image, that's all what counts. I got a ton of stress, but at least, I can enjoy coffee now :)
[07:49] <Saviq> veebers, aaah
[07:49] <Saviq> veebers, ap on device doesn't run under upstart...
[07:49] <Saviq> didrocks, sorry about htat
[07:50] <didrocks> Saviq: well, I'm happy about the resolution, a little bit sorry that a fix for desktop screwed us though, but that's fine
[07:50] <didrocks> also, nothing in the landing plan…
[07:50] <didrocks> or maybe #265
[07:50] <didrocks> but not really clear about the other change
[07:51] <Saviq> yeah I dropped the ball there, sorry
[07:51] <Saviq> just wanted to see -ci getting better
[07:51] <didrocks> well, again, the image is good
[07:51] <didrocks> which is what is important :)
[07:51] <didrocks> the tests are running here
[07:51] <didrocks> I'll report the result
[07:51] <Saviq> oh btw
[07:51] <didrocks> Saviq: I just downgraded to previous -autopilot package
[07:51] <Saviq> phablet@ubuntu-phablet:~$ initctl get-env XDG_DATA_DIRS
[07:51] <Saviq> /usr/share/ubuntu-touch-surfaceflinger:/usr/local/share/:/usr/share/
[07:52] <Saviq> wonder what surfaceflinger is doing there ;)
[07:52] <didrocks> ok, so upstart/direct ap launch issue
[07:52] <didrocks> interesting indeed :)
[07:53] <didrocks> Ran 22 tests in 416.930s
[07:53] <didrocks> FAILED (failures=5)
[07:53] <Saviq> didrocks, previous ap might have some failures in notifications
[07:54] <Saviq> didrocks, not sure when stuff got released
[07:54] <didrocks> Saviq: ok, so let me take your latest and adding the env by hand
[07:54] <Saviq> didrocks, yeah, just export it before starting AP
[07:55] <Saviq> didrocks, if you get any .crash that's more than 1MB, I'll be interested, too
[07:55] <didrocks> Saviq: yeah, the only ones I got was the our lovely gsettings schema missing
[07:57] <veebers> Saviq, didrocks: https://code.launchpad.net/~veebers/unity8/ap_env_fix_1240801/+merge/191567 (I'm just running all the tests now locally, the couple I did try worked)
[07:57] <didrocks> veebers: doing the same, running all tests
[07:57] <didrocks> (with just changing the env)
[07:58] <Saviq> veebers, yeah, this looks right
[07:59] <Saviq> if only we had CI automation...
[07:59] <Saviq> oh wait...
[08:00] <didrocks> Saviq: well, I would love to as well not having to be changed in a manual tester running the tests as well. I think we have to cope with it for now and be systematic in our approach meanwhile
[08:00] <didrocks> Saviq: I raised that as a top priority FYI
[08:03] <didrocks> jibel: popey: so, apart from those issues, happy with that image?
[08:04] <popey> so far.. still fiddling
[08:05] <jibel> didrocks, nothing utterly broken so far
[08:05]  * didrocks crosses fingers
[08:05] <didrocks> then, we'll need ogra_ for finale results on maguro
[08:05] <didrocks> Ran 22 tests in 484.981s
[08:05] <didrocks> FAILED (failures=1)
[08:05] <didrocks> Saviq: ^
[08:05] <didrocks> ERROR: unity8.shell.tests.test_lock_screen.TestLockscreen.test_pin_screen_wrong_code(Native Device)
[08:06] <didrocks> it's a flacky test IIRC
[08:06] <didrocks> (or a race, unity8 didn't restart)
[08:06] <didrocks> anyway, it's good enough for me
[08:06] <Saviq> didrocks, what's the ap error?
[08:06] <didrocks> raise NoSuchProcess(pid, None, 'no process found with pid %s' % pid)
[08:06] <didrocks> NoSuchProcess: no process found with pid 8268
[08:06] <didrocks> oh, an unity8 crash
[08:07] <didrocks> hum, was an older one
[08:07] <Saviq> yeah
[08:07] <Saviq> didrocks, but yeah - that means u8 crashed on startup
[08:07] <didrocks> Saviq: yeah, seems to match the time
[08:07] <Saviq> and I didn't get anything from the backtrace yet
[08:07] <didrocks> anyway, we'll figure it out
[08:07] <Saviq> didrocks, how big the .crash file?
[08:07] <didrocks> Saviq: 50k :p
[08:07] <didrocks> not sure you would be interested, 2 frames ;)
[08:08] <Saviq> didrocks, yeah, *not* useful :/
[08:08] <Saviq> didrocks, and both ??
[08:08] <didrocks> well, sure, not retraced yet
[08:08] <didrocks> but for 2 frames, it's probably a loop in the mainloop
[08:08] <didrocks> Saviq: ok, will dogfood now, if I get an interesting stack, I'll keep you posted
[08:08] <Saviq> didrocks, not gonna get retraced I'm afraid
[08:09] <Saviq> didrocks, both of those frames are in android libs afaict
[08:09] <didrocks> yeah
[08:09] <Saviq> for which we don't have dbg symbols
[08:09] <didrocks> anyway, we'll see in the long term, I don't see anything blocking us for now :)
[08:11] <popey> didrocks: yeah, seems okay.
[08:11] <didrocks> popey: not ok, stellar! :)
[08:11] <didrocks> we have less tests in total in the dashboard though
[08:12] <didrocks> jibel: popey: do you know why? ^
[08:12] <popey> nope
[08:13] <jibel> didrocks, don't ask me about the dashboard. Are the tests still running?
[08:13] <didrocks> jibel: if so, they are stuck for a long time
[08:14] <didrocks> maguro is running
[08:14] <didrocks> but not mako
[08:14] <jibel> didrocks, there are jobs call mir-maguro-smoke-something, maybe that's it?
[08:14] <jibel> I don't know
[08:14] <jibel> psivaa, ^^
[08:15] <didrocks> maguro has the right total number
[08:15] <didrocks> not mako
[08:15] <didrocks> ah ubuntu-ui-toolkit
[08:16] <didrocks> same for dialer-app
[08:17] <Saviq> didrocks, confirmed, veebers's fix is working, shall I merge?
[08:17] <didrocks> Saviq: please do (we won't rebuild it though)
[08:17]  * ogra_ might be a few min late to the meeting, my magurto download says it still needs 15min
[08:18] <ogra_> (flashing before the meeting today)
[08:18] <Saviq> didrocks, yeah I know
[08:18] <psivaa> didrocks: jibel: just kicked off the ui-toolkit job, i dont see any issues with mako dialer
[08:19] <didrocks> psivaa: maguro dialer
[08:19] <didrocks> and terminal/rssreader
[08:19] <didrocks> the total of tests ran are 1
[08:19] <psivaa> didrocks: i've kicked them off already :)
[08:20] <didrocks> great :)
[08:21] <didrocks> it's interesting that total tests run: 288
[08:21] <didrocks> total test failed: 39
[08:21] <didrocks> if I count manually, the pass rate is 86.4
[08:21] <didrocks> not 92.4
[08:21] <didrocks> I think they don't use the right total tests run
[08:22] <mardy> hi! Can someone please fix or delete this job? http://10.97.0.26:8080/job/signon-ui-daily/label=pbuilder/53/
[08:22] <didrocks> mardy: that would be for fginther I guess
[08:22] <mardy> didrocks: thanks
[08:22] <mardy> fginther: ^
[08:22] <mardy> fginther: I think it's using some obsolete PPAs for Qt5
[08:22] <Saviq> veebers, hmm did you try your patch on the desktop?
[08:23] <veebers> Saviq: oh, yes I tried at least one test
[08:23] <veebers> Saviq: I'll re-run now
[08:23] <Saviq> veebers, try uninstalled as well, I'm getting some complaints
[08:23] <veebers> Saviq: uninstalled?
[08:23] <veebers> Saviq: oh unity8 uninstalled
[08:23] <Saviq> veebers, not from a package
[08:23] <Saviq> veebers, yeah, after make -C builddir install
[08:24] <Saviq> veebers, and PYTHONPATH=tests/autopilot autopilot run unity8...
[08:24] <veebers> Saviq: trying now
[08:26] <vila> mardy: it's finished already
[08:26] <vila> *it
[08:26] <veebers> Saviq: I'm doing something dumb, "make -C builddir install" doesn't work for me, what do I need to do from a fresh branch?
[08:26] <didrocks> jibel: popey: oh, something to try on that image: opening/closing a lot of apps
[08:27] <Saviq> veebers, ./build
[08:27] <didrocks> jibel: popey: the slowdown should be fixed
[08:27] <popey> k
[08:27] <veebers> Saviq: ah of course
[08:27] <Saviq> veebers, you might need ./build -s if you have a really clean env (like deps not installed)
[08:28] <popey> i have 10 apps open and it feels a bit sluggish
[08:28] <mardy> vila: yes, but I mean to ask to change the job's configuration
[08:28] <veebers> Saviq: ack
[08:28] <mardy> vila: it always fails
[08:29] <t1mp> 22:06:19 < fginther> t1mp, I discovered one problem was the oom killer was killing qmlscene and autopilot before the test completed, the  workaround was to split up the tests
[08:30] <t1mp> fginther: is that something that https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449 might fix?
[08:30] <vila> mardy: ha, you'll need fginther then indeed
[08:30] <vila> mardy: I had a brief look at the job config but no ppa is directly mentioned there so that needs move knowledge that I have for now
[08:31] <mardy> vila: ok, np, thanks for the investigation. I'll follow-up with fginther
[08:31] <vila> mardy: ack
[08:35] <didrocks> lool: ogra_: around?
[08:35] <didrocks> asac: ?
[08:36] <ogra_> didrocks, on my way, it just finished the download
[08:36] <didrocks> ok :)
[08:39] <veebers> Saviq: is this the complaint you're getting? Please install unity8 or copy data/unity8.conf to /home/leecj2/.config/upstart
[08:39] <veebers> well, not with leecj2 of course :-)
[08:39] <Saviq> veebers, no, it can't find the process
[08:39] <veebers> oh :0
[08:39] <Saviq> veebers, maybe my env is broken again...
[08:40] <veebers> Saviq: did you do anything with the unity8.conf for upstart to find it/
[08:40] <Saviq> veebers, yeah, I have unity8 installed
[08:41] <Saviq> veebers, and I had it copied, too
[08:41] <Saviq> veebers, let me restart my terminal, maybe my env is broken again
[08:43] <Saviq> ok that didn't help
[08:43]  * Saviq reboots
[08:49] <Saviq> veebers, http://paste.ubuntu.com/6250028/
[08:49] <veebers> Saviq: I did have to make one line fix to get running, now I see this in the log: Unable to activate  "camera-app.desktop"
[08:49] <veebers> Saviq: yeah, heh that's the oneline I did to fix it
[08:49] <Saviq> veebers, that means the XDG path isn't set up right
[08:49] <veebers> Saviq: did you ok htat previous MR?
[08:49] <Saviq> veebers, not merged yet
[08:49] <veebers> ah ok
[08:50] <veebers> Saviq: I've changed it to needs review
[08:50] <veebers> need to fix this first
[08:50] <Saviq> veebers, k
[08:50] <Saviq> veebers, so it's working installed - from both package and local PYTHONPATH=
[08:50] <Saviq> veebers, but has issues with uninstalled
[08:50] <Saviq> veebers, it's late for you, shall we take over?
[08:50] <Saviq> veebers, thanks for being on guard for the original issue
[08:51] <veebers> Saviq: nw, also thank rsalveti  and didrocks who originally brought it to my attention :-)
[08:52] <veebers> Saviq: I'll see if I can fix it quickly, if not I'll hand over
[08:52] <Saviq> veebers, thanks
[08:55] <didrocks> yw veebers, thanks!
[08:55] <psivaa> popey: didrocks: ive noted down some information about the AP testing of the core apps on 99 in the doc
[08:55] <psivaa> https://docs.google.com/a/canonical.com/document/d/1EepnzbV6b0aqvdevB19_Fp2gmjwLDNEo6F3lcv0VhVY/edit#
[08:56] <didrocks> psivaa: ah, excellent! thanks a lot :)
[08:56] <psivaa> didrocks: yw :)
[08:56] <jibel> didrocks, confirmed, it is faster. I started all the preinstalled apps, but then init uses crazy amount of memory and the system starts swapping
[08:56] <didrocks> jibel: yeah, we still have the upstart mem leak
[08:57] <didrocks> but I'm still happy with have the libunity-mir mem leak under control
[09:02] <veebers> Saviq: d'oh was trivial fix have pushed latest if you would like to try agin
[09:02] <veebers> again*
[09:05] <Saviq> veebers, cool, thanks
[09:06] <lool> Hi
[09:08] <Saviq> veebers, +1
[09:09] <vila> lool: hi ! Slept enough ?
[09:09] <sil2100> Hello!
[09:09] <didrocks> sil2100: you're back \o/
[09:10] <sil2100> didrocks: still on the tty though... doing another reboot in a moment
[09:10] <didrocks> sil2100: good luck with your hunt!
[09:11] <t1mp> psivaa: perhaps https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1239646 should go in the doc as well
[09:11] <t1mp> psivaa: I'm still waiting for a CI run to see if it was fixed by a mir update
[09:11] <lool> vila: lalala
[09:12] <lool> vila: yeah it's ok
[09:12] <vila> lool: :)
[09:12] <lool> but I ignored the alarm clock
[09:12] <psivaa> t1mp: ok, CI run with image 100 has finished
[09:12] <t1mp> psivaa: do you have a url for that?
[09:12] <psivaa> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
[09:13] <t1mp> thanks
[09:13] <ogra_> didrocks, lool, asac, popey, from maguro POV the image looks fine
[09:13] <ogra_> i filed bug 1240875
[09:13] <ogra_> but thats not maguro specific
[09:14] <didrocks> ogra_: \o/
[09:14] <veebers> Saviq: hmm I don't seem to have this dir on my desktop: /usr/share/unity8/mocks/data, I've installed unity8 + fakenv + autopilot tests etc.
[09:14] <t1mp> psivaa: wow. looks like ubuntu-ui-toolkit has 52/52 passes :D
[09:15] <t1mp> hmm 2 fails on maguro
[09:15] <t1mp> on systemsettle-before and systemsettle-after. I don't know what that is
[09:16] <Saviq> veebers, it's in fake-env
[09:16] <Saviq> veebers, from trunk, though
[09:16] <veebers> Saviq: ah ok
[09:16] <Saviq> veebers, as in you need 20131016
[09:16] <Saviq> .1 I think
[09:17] <veebers> Saviq: ah ok, thanks
[09:17] <Saviq> veebers, yeah, just checked - it's there
[09:18] <Saviq> veebers, hrm
[09:18] <Saviq> http://packages.ubuntu.com/saucy/amd64/unity8-fake-env/filelist disagrees
[09:19] <Saviq> veebers, but it's there if you open https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5110290
[09:19] <Saviq> the fake-env deb
[09:19] <Saviq> veebers, aaanyway - we'd know - if it's not there - ap on desktop will fail miserably
[09:20] <psivaa> t1mp: systemsettle failure doesn't look related to ubuntu-ui-toolkit tests
[09:20] <psivaa> the systemsettle test fails before the uitoolkit tests run
[09:20] <Saviq> veebers, and it's fine http://10.97.0.26:8080/job/autopilot-testrunner-otto-saucy/1248/
[09:21] <ogra_> and bug 1240881
[09:21] <t1mp> psivaa: on this MR the tests just failed https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/ci-test/+merge/190906
[09:21] <lool> jibel: thanks for the testing
[09:21] <t1mp> psivaa: do you know how I can see which image was used for those tests? if it is image 100 they should have passed
[09:21] <veebers> Saviq: ok, perhaps I have an older package
[09:21] <Saviq> veebers, thanks!
[09:22] <veebers> Saviq: I ask because of this (probably not urgent) from our discussion yesterday/this morning: https://code.launchpad.net/~veebers/unity8/ap_make_use_of_helpers_in_tests/+merge/191575
[09:22] <psivaa> t1mp: let me take a look
[09:22] <t1mp> psivaa: thanks
[09:22] <Saviq> veebers, yeah, will look at it asap
[09:22] <Saviq> veebers, although we need to take a step back and see what can we abstract / what should move into ap (like all the upstart business) etc.
[09:22] <veebers> Saviq: sweet thanks, it's pre-req branch is still "needs-review" so if you get the chance that would be awesome too :-)
[09:23] <veebers> Saviq: ah, I haven't had the chance to talk to you about that
[09:23] <cjwatson> lool: how's timing looking?  we're looking at releasing everything else in early afternoon (maybe around 1pm local?, but not going to set a fixed time), and it'd be good if the touch images were ready when we do :)
[09:24] <veebers> I was talking with thomi earlier (the other day?) and autopilot 1.4 will handle all/most of the upstart stuff. Which is why I didn't go into the trouble of abstracting etc. that stuff to much at all
[09:24] <Saviq> veebers, ok cool
[09:24] <Saviq> veebers, so, like tomorrow ;D
[09:24] <veebers> so soon we'll be able to go through and update those to be much nicer
[09:24] <veebers> Saviq: ^_^
[09:27] <psivaa> t1mp: both mako and maguro are running image 100
[09:32] <didrocks> ogra_: do you see an improvement thanks to unity-mir?
[09:32] <didrocks> cjwatson: I'm handling it
[09:33] <asac> cjwatson: seems we have our final image, so should be good. check with didrocks etc.
[09:33] <didrocks> cjwatson: image 100 will be the one
[09:33] <t1mp> psivaa: I don't understand why this one passes http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/100:20131017:20131015/4767/ubuntu-ui-toolkit-autopilot/
[09:33] <asac> didrocks: dont say too much :)
[09:33] <asac> lol
[09:33] <didrocks> ;)
[09:33] <t1mp> psivaa: and this fails most of the tests https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2530/?
[09:33] <t1mp> psivaa: shouldn't they be the same?
[09:33] <didrocks> cjwatson: so, we need to discuss release note, we have some infos, where should we paste them?
[09:33] <asac> didrocks: can we retry a few things like notes-app etc.?
[09:33] <asac> maybe the dashboard can look even nicer for 100
[09:33] <didrocks> psivaa: ^
[09:34] <cjwatson> didrocks: can you edit https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes directly (just watch out for edit conflicts as several people are editing on and off)?
[09:34] <psivaa> didrocks: ack, will run them
[09:34] <asac> 100 is running on maguro :)
[09:34] <cjwatson> didrocks: There's an empty section for Ubuntu Touch there waiting for your input :-) (feel free to rename it though)
[09:34] <psivaa> t1mp: not sure why they differ.. need to take a deeper look at the medium tests
[09:34] <didrocks> cjwatson: sure, doing it, a section sounds good
[09:35] <sil2100> didrocks: any testing needed? I'm on with a shell now and flashing my device right now
[09:35] <didrocks> cjwatson: can you tell us when the announce will be made? We are just a promotion away
[09:35] <didrocks> sil2100: please dogfood like crazy ;)
[09:35] <didrocks> thanks psivaa
[09:36] <t1mp> psivaa: is there a way to see if this fix https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449 is present in image 100?
[09:36] <ogra_> eeek !
[09:36]  * ogra_ found an RC bug on maguro :(
[09:36] <cjwatson> didrocks: My aversion to picking a time isn't paranoid secrecy, it's because we've found that if we nominate an exact time then people tend to try to stick to it even if things are going wrong
[09:37] <ogra_> root@ubuntu-phablet:/# ls -lh /var/log/syslog
[09:37] <ogra_> -rw-r----- 1 syslog adm 352M Oct 17 11:37 /var/log/syslog
[09:37] <ogra_> root@ubuntu-phablet:/#
[09:37] <asac> ogra_: thats system updates
[09:37] <ogra_> grows ~100M per minute
[09:37] <cjwatson> didrocks: not before 1pm London time
[09:37] <cjwatson> didrocks: hopefully not long after that
[09:37] <didrocks> cjwatson: right, I mean, just tell us in advance so that we can promote
[09:37] <ogra_> and i cant connect to WIFI anymore
[09:37] <t1mp> psivaa: so if unity-mir has r > 129
[09:38] <ogra_> and in fact syslog gets about 100 lines from NM per second
[09:38] <cjwatson> didrocks: do you have any mirror propagation delays we need to be concerned about?
[09:38] <asac> ogra_: i am connected on wifi
[09:38] <didrocks> ogra_: are you really not connected? there is a bug with the tick not showing randomly
[09:38] <cjwatson> didrocks: (and promote to where?)
[09:38] <didrocks> ah
[09:38] <ogra_> asac, switch wifi off and on a few times
[09:38] <ogra_> at some point it stops listing any networks at all
[09:38] <didrocks> ogra_: can you answer to cjwatson? ^ (I think we don't have mirrors, right?)
[09:38] <ogra_> no, we dont
[09:39] <didrocks> cjwatson: promote to the stable channel
[09:39] <cjwatson> didrocks: so if we just give you ten minutes' warning or something?
[09:39] <ogra_> cjwatson, i also wouldnt know what "promotion" means in case of touch ... since we will just roll forward
[09:39] <didrocks> ogra_: don't you tell "promoting an image"? :)
[09:39] <asac> ogra_: i dont think the fact that NM goes down after stressing it a new issue
[09:39] <didrocks> I heard it from you
[09:39] <asac> or is it?
[09:39] <ogra_> didrocks, right, to the devel channel from devel-proposed
[09:39] <asac> i had this at least one time in previous days
[09:40] <ogra_> asac, definitely new
[09:40] <ogra_> i never had that before
[09:40] <asac> ogra_: i had it :)
[09:40] <ogra_> root@ubuntu-phablet:/# ls -lh /var/log/syslog
[09:40] <ogra_> -rw-r----- 1 syslog adm 595M Oct 17 11:40 /var/log/syslog
[09:40] <asac> didnt wsee th syslog, but the "cant see any wifi network anymore)
[09:40] <ogra_> and my disk will be full in about 30min or so
[09:40] <asac> ogra_: yeah. yo must be in an awful race
[09:40] <asac> or something
[09:40] <didrocks> cjwatson: so yeah, 10 minutes is fine :)
[09:40] <asac> ogra_: can you reboot and see how often you can trigger
[09:40] <asac> ?
[09:40] <didrocks> cjwatson: well, if ogra is around
[09:40] <ogra_> i get 100s of lines into syslog per minute
[09:40] <asac> sure, we know that by now
[09:41] <ogra_> ah, and now i cant wake it up from sleep anymore
[09:41] <ogra_> (it was only on for like 20min)
[09:42] <asac> ogra_: your boot is busted obviously... try if you can reproduce anything like that when you boot again etc.
[09:42] <asac> ogra_: and capture what you see of course
[09:42] <asac> logs etc.
[09:42] <ogra_> and its glowing at the top ... nearly cant touch it
[09:42] <asac> so one can investigate
[09:42] <ogra_> reboot is also not possible
[09:42] <asac> jibel: are you guys on testing #100?
[09:43] <ogra_> http://paste.ubuntu.com/6250220/
[09:43] <asac> jibel: you might want to keep an eye on what ogra is describing above
[09:43] <jibel> asac, yes, we do
[09:43] <ogra_> thats the stream of messages in syslog
[09:43] <jibel> asac, that's what I'm trying to reproduce ATM
[09:43] <asac> ok
[09:43] <jibel> asac, but cannot on mako
[09:43] <asac> ogra_: is that a fresh --no-backup install?
[09:43] <asac> jibel: i dont have it on maguro either, but i did a system update
[09:43] <ogra_> asac, yes
[09:44] <asac> ok let me do that then too
[09:44] <ogra_> i have 2 APs in the house and moved between them (i usually do that for a test) ... and i have a wlan free spot in the house where i usually go to test if it switches back and forth ...
[09:44] <ogra_> after being out of wlan range and getting back into range this started
[09:45] <asac> jibel: ^
[09:45] <asac> well, let me first flash a no-backup one
[09:45] <ogra_> the spam started after being in the wlan free spot and switching wifi off and on again
[09:46] <jibel> asac, ok, I'll have to find a place without wifi
[09:46] <ogra_> when being back in range i got a WPA dialog but no AP listings anymore
[09:46] <asac> jibel: i feel it might be a on/off thing etc.
[09:46] <asac> rather than roam
[09:46] <ogra_> jibel, use tinfoli
[09:46] <ogra_> wrap the phone in it, and leave it for a moment
[09:47] <ogra_> that should shield you from all networks
[09:47] <psivaa> t1mp: i think the devices have unity-mir r 129
[09:48] <psivaa> ahh you needed > 129
[09:48] <t1mp> psivaa: actually I needed >= 129
[09:48] <t1mp> so 129 should be good
[09:49] <ogra_> ok, phone is back up ... let me walk through the house to see if i can trigger it again
[09:52] <jibel> hm, unity8 crashed when I went out of range
[09:52] <didrocks> popey: thanks! I was about adding that one ;)
[09:52] <popey> ☻
[09:53] <popey> didrocks: are you taking from that doc and putting somewhere else?
[09:54] <ogra_> asac, jibel, so i can reproduce the behavior in the UI, but this time it doesnt spam syslog
[09:54] <jibel> ogra_, what exactly do you do, I'll try on mako
[09:56] <didrocks> popey: yeah, putting it on the wiki release page as soon as I can get a lock on it :)
[09:56] <popey> coolio
[09:57] <ogra_> jibel, i have one AP upstartis and one downstairs ... and a WLAN free spot in one bathroom ... i want from upstairs to downstairs, watch the signal degrade and watch it picing up the new AP (wehich makes the signal go to 100% again) ... then i go to the bathroom and watch wlan go away and see the 3G icon appear
[09:57] <ogra_> at that piont i get a WPA PW popup
[09:57] <jibel> ogra_, the unity8 crash I saw might be a duplicate of bug 1239394, I'm uploading the crash and will do more 'out of range' tests
[09:58] <ogra_> typing in the PW doesnt connect (Edge icon stays (little E in the panel)
[09:58] <ogra_> then switching off and on wlan triggers it
[09:58] <jibel> ogra_, okay, I don't have any AP in my bathroom, but it probably doesn't matter :)
[09:59] <ogra_> lol
[09:59] <ogra_> i dont have wlan in one of my bathrooms
[09:59] <didrocks> popey: dpm: feel free to edit it directly as well
[09:59] <ogra_> seems the pipes shield that room very well
[10:02] <sil2100> hm, is there an option to save images in our webbrowser-app?
[10:02] <didrocks> sil2100: maybe ask osomon?
[10:03] <popey> dont think so
[10:03] <didrocks> popey: how do you take all your screenshot btw?
[10:04] <popey> mirfbdump
[10:04] <didrocks> popey: hum, is that installed by default?
[10:04] <popey> no
[10:04] <didrocks> command not found
[10:04] <popey> its a script
[10:04] <popey> one mo
[10:05] <popey> http://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/mirfbdump
[10:05] <popey> Jean-Baptiste wrote it, I modded it so it autouploads to my webspace and opens the image using xdg-open
[10:05] <ogra_> jibel, asac, while i can reproduce the strange UI behavior, i cant really reproduce the syslog spam, lets put that one under "driver hiccup" until we see it again
[10:05] <didrocks> popey: oh nice!
[10:05] <popey> also his script shrinks the image, i wanted full-size ones
[10:06] <didrocks> /dev/$FBDEV ${PICDIR}/fb
[10:06] <didrocks> waow ;)
[10:06] <didrocks> ok, it's really a dump :)
[10:07] <popey> yeah!
[10:07] <lool> cjwatson: sorry I was picking up my son at school
[10:07] <lool> cjwatson: we're good
[10:07] <lool> cjwatson: in terms of images, we're sticking with our latest #100
[10:07] <lool> cjwatson: we've assessed the remaining high prio issues, and they will be delivered in updates now
[10:07]  * popey pops out to run an errand. back in an hour or less
[10:08] <didrocks> popey: enjoy!
[10:08]  * popey doesn't enjoy dentists ☻
[10:08] <jibel> didrocks, http://people.canonical.com/~j-lallement/touch/mirfbdump original version without upload to popey's place :) there is a request to include it into phablet-tools
[10:08] <didrocks> jibel: we definitively should
[10:08] <didrocks> popey: don't enjoy then and good luck!
[10:08] <didrocks> :)
[10:09] <lool> popey: ouch
[10:10] <ogra_> is it expected that my icons under "installed" re-oder themnselves all the time (thats on mako)
[10:10] <ogra_> ah, now it stopped
[10:10] <ogra_> that looked weird
[10:11] <lool> So image 100 is the one with the highest pass rate ever on touch_mir images
[10:11] <ogra_> (wild icon shuffling that stops and starts over etc ... having stock ticker as first icon, then shorts ,, and in the end the browser again)
[10:12] <lool> ogra_: yeah that's painful
[10:12] <lool> ogra_: worst is when the clicks dont show up
[10:12] <ogra_> yeah
[10:12] <ogra_> but it went on this time
[10:12] <ogra_> for about a minute
[10:12] <ogra_> even with the click being there
[10:12] <ogra_> but i guess as long as it stops we're fine
[10:13] <dpm> didrocks, done (editing release notes). That's all I could think of
[10:13] <didrocks> dpm: thanks :)
[10:20] <Saviq> didrocks, btw, shall we release unity8 and rerun its suite on #100?
[10:20] <didrocks> Saviq: no need to release it. I just did my test results locally
[10:20] <psivaa> t1mp: ok, on maguro the tests succeeded
[10:21] <didrocks> Saviq: let's not touch anything right now :)
[10:21] <Saviq> didrocks, I mean for smoke ;)
[10:21] <Saviq> didrocks, but ok :)
[10:21] <asac> ogra_: sounds right
[10:21] <Saviq> didrocks, btw, seems we found the crasher: bug #1240866
[10:21] <ogra_> whee
[10:21] <asac> i am sure we are not 100% robust on maguro wrt wifi
[10:21] <Saviq> didrocks, getenv is not thread safe
[10:21] <ogra_> with pittis fix maguro feels snappier actually
[10:21] <t1mp> psivaa: ah cool, that's an improvement :) now let's see whats up with mako
[10:21]  * ogra_ just replaced udevd with the fixed one
[10:22] <didrocks> Saviq: oh, the story repeat! (we had exactly the same in unity7 2 years ago ;))
[10:22] <didrocks> Saviq: nice catch!
[10:22] <Saviq> didrocks, :D
[10:22] <psivaa> t1mp: mako failed to unlock screen.. looking at why this has happened
[10:22] <didrocks> Saviq: no way to run the smoke test without an image being built (hence no release ;))
[10:22] <t1mp> psivaa: mako still seems to have the same problem. https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2578/testReport/junit/ubuntuuitoolkit.tests.gallery.test_gallery/ButtonsTestCase/test_buttons_standard_button_/
[10:22] <sil2100> ;D
[10:22] <t1mp> psivaa: a problem when setting up the app
[10:22] <t1mp> psivaa: ah that could explain it
[10:22] <asac> Saviq: thats a multi-threading issue?
[10:23] <Saviq> asac, yes
[10:23] <Saviq> asac, both unity8 and Mir try to getenv() concurrently
[10:23] <Saviq> asac, and that fails
[10:23] <Saviq> asac, it's a rare occurence - but is most probably the cause for our last unity8 test failures
[10:24] <ogra_> bah
[10:25] <ogra_> nowe it got super slow again :/
[10:25] <asac> Saviq: so if we retry it might succeed?
[10:25] <asac> "if its rare" :)
[10:26] <Saviq> asac, well, if you run just the one failing test it will pass - if you run the whole suite, you'll probably get the same again in some other tests
[10:26] <Saviq> asac, rare seems to mean ~5%
[10:26] <Saviq> in that case
[10:27] <Saviq> asac, trick is, I had better success on maguro, where slower CPU seems to help (or less threads?)
[10:27] <Saviq> asac, but at least we know the cause now - we couldn't get a trace of this for a while now
[10:31]  * ogra_ files bug 1240911
[10:36] <asac> Saviq: yeah MT is tricky to debug and do right
[10:36] <asac> well done
[10:43] <davmor2> ogra_: I thought there was already one on the camera app cause lag in the system
[10:44] <ogra_> davmor2, well, then someone can duplicate it :)
[10:45] <davmor2> ogra_: I would but I can't remember the bug jibel  ^ is it one that you filed  I know someone gave me a link to a bug when I mentioned it
[10:45] <ogra_> bah #ubuntu-release-party is really empty
[10:46]  * ogra_ cant remember a release wheer we were below 100 people in there at that time of day
[10:47] <Saviq> let's fix!
[10:47] <ogra_> it is usually around 200 spiking to 3-400 at tiome of the actual release
[10:47] <ogra_> even here are more people
[11:14] <Laney> ogra_: you should get dholbach to social media about it
[11:14] <Laney> if you want it busy :P
[11:16] <kalikiana> who could tell me about locale details in Jenkins images? I have an i18n unit test using gettext and cannot get it to pass https://code.launchpad.net/~kalikiana/ubuntu-ui-toolkit/xdglocale/+merge/188359
[11:17] <didrocks> dpm: not meeeeeee! ;)
[11:17] <dpm> :)
[11:17] <kalikiana> it never picks up translations even though eg. en_US is installed, files are where they should be
[11:19] <ogra_> Laney, i guess an entry in the topic on #ubuntu (like we ususally have) would help too
[11:20] <Laney> maybe
[11:20] <Laney> creepy, my ubuntu phone just randomly illuminated
[11:20] <ogra_> does anyone remember the bug # for the black wallpaper on maguro ?
[11:25] <t1mp> psivaa: did you discover something related to the mako screen not unlocking?
[11:25] <t1mp> ogra_: is it this one? https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1227783
[11:25] <sil2100> Sad, but I only see people talking about Ubuntu Touch on the release party
[11:25] <sil2100> What about desktop?!
[11:25] <ogra_> t1mp, thanks ...
[11:26] <t1mp> ogra_: the fix is ready for UITK for a while now, but couldn't merge because of CI issues in UITK. And it seems that Unity8 fixed it outside of UITK so it did not seem urgent enough for a manual merge
[11:32] <psivaa> t1mp: not yet, it could be due to bug 1238298. retunning the job seeing some other missing dep issues on other devices
[11:37] <t1mp> psivaa: the error messages there are not exactly the same as what we get in UITK, but the cause may be related
[11:39] <kalikiana> the second part with .ProcessSearchError definitely looks like the failure in uitk we get
[11:39] <kalikiana> the main problem is, it looks identical to the mir-based error used to
[11:41]  * kalikiana idly wonders why lock isn't disabled during test runs
[11:41] <t1mp> kalikiana: well the system should be as close to the "real" system when running the tests
[11:42] <t1mp> +"as possible"
[11:42] <t1mp> kalikiana: indeed, the last failure is exactly the same
[11:43] <t1mp> 6   File "/usr/lib/python2.7/dist-packages/autopilot/introspection/__init__.py", line 271, in get_proxy_object_for_existing_process
[11:43] <t1mp>     raise ProcessSearchError("Search criteria returned no results")
[11:43] <t1mp> autopilot.introspection.ProcessSearchError: Search criteria returned no results
[11:47] <didrocks> ogra_: can you promote the image to devel?
[11:47] <ogra_> didrocks, already ?
[11:47] <didrocks> ogra_: yeah ;)
[11:48] <ogra_> ok, releasing then
[11:50] <ogra_> didrocks, asac, lool, popey 100/20131017 promoted
[11:50] <popey> ttp://popey.com/~alan/phablet/device-2013-10-17-125029.png  \o/
[11:50] <didrocks> thanks :)
[11:50] <asac> nice one!
[11:53] <popey> mail sent
[11:54]  * ogra_ is shocked by #ubuntu-release-party ... so quiet ... still didnt hit 100 people 
[11:55] <popey> Everyone switched to Mint/Arch apparently
[11:55] <ogra_> yeah :/
[12:00] <sil2100> Sad...
[12:01] <sil2100> I guess most of the people on that channel are interested in Ubuntu Touch from what I see
[12:01] <popey> seems so
[12:01] <ogra_> yeah
[12:02] <sil2100> No one cares about the desktop anymore!
[12:02]  * sil2100 runs away in tears
[12:03]  * popey steals sil2100's laptop
[12:03] <sil2100> :O
[12:07] <lool> ogra_: \o/
[12:23] <didrocks> ogra_: oh, stupid question, but in 100:20131017:20131015, the last 20131015 is the last rebuild of the android side?
[12:23] <ogra_> yep
[12:24] <didrocks> ok, I'm not that stupid ;)
[12:24] <didrocks> thanks
[12:24] <ogra_> not sure why stgraber doesnt actually use the package version stamp though
[12:24] <didrocks> yeah, as it's just one package…
[12:36] <lool> vila: nocheck dans DEB_BUILD_OPTIONS
[13:06] <alesage> fginther and others, tedg asking about T support already :)
[13:06] <fginther> alesage, do we have a name yet :-)
[13:06] <cjwatson> we do not
[13:06] <cjwatson> Jane is on it
[13:07] <cjwatson> I expect we'll have things minimally opened later today though PPAs may not quite work yet
[13:07] <alesage> tedg ^^ , sounds like we're waiting for an announcement of a name too ;)
[13:07] <tedg> Wait, isn't "Ted" enough?
[13:08] <alesage> the t-shirt would just look like tedg :)
[13:08] <fginther> alesage, tedg, we can start creating the lp 13.10 branches now and getting the cupstream2distro-config files updated
[13:08] <ogra_> Tedg-ish Tapir ?
[13:08] <ogra_> or would ted be the animal part ?
[13:09] <alesage> fginther, I leave it in your capable hands :)
[13:09] <tedg> fginther, So if I make the branches, does that screw you?  Should I wait?
[13:09] <tedg> fginther, FYI, I have a script for it, so it's fast.
[13:10] <fginther> tedg, I think that's perfectly fine. sil2100, can you comment, can tedg start branching projects as he prefers?
[13:11] <fginther> tedg, sil2100, I think all we care about are the branch names so we can plug them into the config files
[13:12] <tedg> fginther, They'll all be "trunk.14.04" :-)
[13:12] <cjwatson> you should probably be branching for 13.10 and keeping 14.04 stuff on trunk
[13:12] <cjwatson> rather than branching for each release
[13:12] <cjwatson> as a general approach
[13:12] <fginther> tedg, what cjohnston said
[13:12] <tedg> We've been using teh LP symbolic names there.
[13:12] <tedg> So we realign those for what "trunk" is.
[13:12] <tedg> And Bazaar tracks those names as well.
[13:12] <fginther> oh
[13:13] <tedg> But this also means that things like MRs that were already queued, stay with that branch.
[13:16] <fginther> tedg, yeah that works (I'm looking at lp:upstart-app-launch which is just a link to lp:~indicator-applet-developers/upstart-app-launch/trunk.13.10)
[13:18] <didrocks> fginther: we only branch components having desktop support
[13:18] <didrocks> fginther: so for indicators touch only for instance, we don't branch, trunk will be T
[13:18] <didrocks> (and no support release)
[13:19] <didrocks> fginther: so no upstart-app-launch 13.10
[13:19] <tedg> didrocks, Really?  We're probably going to have to support demos, no?
[13:19] <didrocks> tedg: it will be the last stable image
[13:19] <didrocks> which can be T
[13:20] <didrocks> (like next week)
[13:20] <didrocks> we just won't promote image to stable that are not demoable ;)
[13:20] <fginther> didrocks, thanks for the correctino
[13:20] <fginther> correction
[13:20] <didrocks> tedg: don't complain, less support for you! :-)
[13:20] <didrocks> fginther: so, if you want to start diverging for components that are shipped in ubuntu desktop, please do :)
[13:21] <tedg> didrocks, It's not work for me, I just make kenvandine do it.
[13:21] <plars> didrocks: what was the outcome of the unity problems?
[13:21] <tedg> :-)
[13:22] <cjwatson> saucy announce is in mod queue, website being updated
[13:22] <didrocks> tedg: ahah ;)
[13:22] <didrocks> ogra_: do you need to do anything to push to stable? I guess stable points to saucy as devel points to saucy
[13:22] <didrocks> thanks cjwatson :)
[13:22] <ogra_> didrocks, i dont know
[13:23] <ogra_> didrocks, waiting for stgraber to clearify
[13:23] <didrocks> plars: so, it was autopilot unity8 tests
[13:23] <didrocks> yeah, let's wait for him :)
[13:23] <didrocks> plars: the environment which was running unity8 wasn't the right one (only during the tests)
[13:23] <ogra_> didrocks, i suspect we cant do anything atm until we have a name for the new release
[13:23] <didrocks> right
[13:23] <ogra_> so that devel can point there
[13:23] <didrocks> phablet-flash without any option works anyway
[13:24] <didrocks> plars: fixed in trunk, but didn't need a respin as it's only in the unity8-autopilot package
[13:24] <didrocks> fginther: you may need to adapt from https://wiki.ubuntu.com/DailyRelease/MovingNewRelease
[13:33]  * fginther reads to refresh memory
[13:47] <mardy> fginther: hi! Can you have a look at the configuration of this job? http://10.97.0.26:8080/job/signon-ui-daily/label=pbuilder/53/
[13:47] <mardy> fginther: it always fails, because it uses a very old version of Qt5
[13:49] <fginther> mardy, is this job still needed? why are we doing a daily build?
[13:49] <fginther> mardy, just want to make sure this is still useful
[13:50] <mardy> fginther: I actually think it isn't useful at all
[13:51] <mardy> fginther: it has been failing since months, and no one complained (except because of the noise)
[13:52] <fginther> mardy, I'll check with victor, if he has no use for it, I'll disable
[13:56] <lool> so we're branching trunk to saucy?
[13:57] <ogra_> lool, for what ?
[13:57] <lool> I dont know
[13:57] <ogra_> lool, for phone stuff we shouldnt ... for desktop stuff we can
[13:57] <lool> I thought we were doing some saucy based updates first?
[13:58] <ogra_> from whatever deskop SRUs are there that touch us
[13:58] <ogra_> for touch related stuff T is the target
[13:58] <fginther> mardy, victor no longer has a use for that job, i've disabled it
[13:59] <mardy> fginther: thanks!!
[13:59] <lool> ogra_: I thought we were doing a couple of important landings in saucy-upates
[13:59] <lool> e.g. download-manager
[13:59] <ogra_> lool, no
[13:59] <lool> so we're doing saucy based updates, but without any touch stuff?
[13:59] <lool> too bad
[14:00] <lool> delays the critical fixes some more
[14:00] <ogra_> lool, we fix T so we can have an awesome first T image
[14:00] <lool> well we want that too
[14:00] <ogra_> right
[14:00] <ogra_> hire more people if you want both ;)
[14:00] <lool> but if we're going to roll the first updates from saucy, I'd want us to include the download-manager fix, especially if stable is a bit longer lived
[14:00] <ogra_> lets focus resources on going forward
[14:00] <lool> it's not for many things
[14:00] <lool> really one from me  :-)
[14:01] <ogra_> if we make one exception we have to make it for all
[14:01] <lool> sure; we can ask people to file two landings
[14:01] <ogra_> which defeats the purpose
[14:01] <lool> to discourage the saucy ones as being extra cost  :-)
[14:02] <lool> or maybe another way to ask about it: what do we put in devel that we dont put in stable or vice-versa
[14:02] <ogra_> lool, SRUs will have to sit in proposed for two weeks anyway ... we'll likely have the first T image faster (and since the plan is to not regress this vs saucy i would expect that to even be better)
[14:03] <lool> do touch SRUs have to sit 2 weeks?
[14:03] <lool> I was thinking put download-manager in proposed, test, put in -updates; it's seeded only in touch
[14:03] <ogra_> they are SRUs
[14:03] <ogra_> and fall under the rules the ubuntu TB made
[14:03] <lool> maybe we can challenge that rule for touch seeded stuff
[14:03] <ogra_> we have no special rules approved by the TB for this
[14:04] <lool> it's not like we were landing and breaking desktops just hours ago  ;-)
[14:04] <lool> we have special rules for unapproved
[14:04] <ogra_> you can surely add it to the TB agenda for next meeting
[14:04] <lool> and for proposed
[14:04] <sergiusens> lool, ogra_ if we don't move to T now, we'll have the same pain from when we switched to saucy and to raring (although no PPAs this time :-D)
[14:04]  * ogra_  heard several upset voices about special treating touch already
[14:04] <lool> sergiusens: we should move to T as soon as possible, and not allow anything to land in saucy that isnt in T
[14:04] <ogra_> not sure we want to stirr that up further without involving the TB
[14:04] <lool> sergiusens: but if the first updates for a week are from saucy, I want a couple to land there
[14:05] <lool> like download-manager
[14:05] <ogra_> sergiusens, i dont expect any pain
[14:05] <ogra_> sergiusens, all our stuff is in the archive ... so the first T image will in fact just be the same as saucy
[14:05] <ogra_> the archive just gets copied over as the first step
[14:06] <sergiusens> ogra_, yeah, if we switch asap :-)
[14:06] <lool> well we want the toolchain to settle first
[14:06] <ogra_> and image build scripts just get "s/saucy/terrific/"
[14:06] <lool> I guess it's all ready, and just needs a series of upload
[14:06] <ogra_> (or whatever that name will be)
[14:06] <lool> tasty
[14:06] <ogra_> sergiusens, it will be as painless as switching desktop over is
[14:14] <didrocks> lool: we decided to not do that
[14:14] <didrocks> with rick, asac and so on
[14:14] <didrocks> so let's not please rediscuss it again :(
[14:14] <didrocks> see #ubuntu-release
[14:16] <ogra_> right
[14:21] <didrocks> cjwatson: vila: lool: ogra_: sil2100: jibel: plars: psivaa: robru: cyphermox: I've deleted our landing meetup for today and tomorrow, let's enjoy the release, there is no need until T is setup. We can have specific discussions if needed :)
[14:21] <sil2100> didrocks: ok!
[14:22] <ogra_> ++
[14:22] <sil2100> didrocks: what about the releases we usually targetted 'on Friday'?
[14:24] <didrocks> sil2100: it's Friday/Monday, you can prepare, already, working on diverging desktop branches  with fginther should take some time, (are you synced with him on it?)
[14:26] <lool> didrocks: I actually read that discussion and understood it the other way around
[14:26] <lool> didrocks: but thanks for clarifying
[14:29] <rsalveti> morrrrning
[14:29] <rsalveti> seems we released already
[14:29] <rsalveti> I may just get back to bed then
[14:29] <rsalveti> :P
[14:30] <sil2100> didrocks: not yet, but we're syncing up slowly ;)
[14:31] <didrocks> rsalveti: please go! ;)
[14:31] <didrocks> rsalveti: full explanation on the puzzling issue on the ue-leads ML
[14:32] <lool> didrocks: so e.g. what's with the netlink filter 0day SRU?
[14:32] <ogra_> rsalveti, habe a beer first *then* go to bed again
[14:32] <ogra_> lool, wont be needed
[14:33] <fginther> didrocks, do you have a good idea of which projects are touch only? to double check the list before we branch them?
[14:33] <ogra_> lool, tvoss found a possible proper fix we'll have in the first T image
[14:33] <didrocks> lool: so, from what I understood, if it's a fix for touch -> T, if it's a fix that is for desktop, we do the SRU round and will picked in next image respin
[14:34] <lool> I guess we should tell pitti then
[14:34] <rsalveti> ogra_: yeah :-)
[14:35] <lool> looking at the timeline in asac's email, I'm fine if the next *stable* image is like end of next week
[14:35] <rsalveti> didrocks: cool, thanks
[14:35] <lool> that is, landings resume tuesday from T, some crack might come in, gets fixed, image is promoted to stable relatively quickly
[14:35] <rsalveti> lool: T stable?
[14:35] <lool> rsalveti: Yeah
[14:35] <rsalveti> cool
[14:35] <lool> well
[14:36] <rsalveti> we'll we stop this landing process using this spreadsheet?
[14:36] <lool> I still have doubts everybody is on the same page
[14:36] <rsalveti> or is this something post-oakland?
[14:36] <lool> the latest back and forth seem to exclude saucy-updates now
[14:36] <didrocks> lool: I guess if he already tested and pushed -> ok
[14:36] <lool> except for some system-image tests we'll do in the next couple of days
[14:36] <didrocks> lool: but we shouldn't add any extra work now in this
[14:36] <lool> didrocks: well the only one I'm worried about is this download-manager thing
[14:36] <lool> didrocks: because it will affect upgrades *from* stable / 1.0
[14:36] <lool> to possibly a long time in the future
[14:37] <lool> I dont want us to fix 20 issues in 1.0 via saucy-updates
[14:37] <didrocks> lool: what's the effect apart from log spam?
[14:37] <lool> but if the next image in *stable* channel is in 6 months, or even in a month, we dont really know whether it will work
[14:37] <lool> didrocks: slow downloads, huge logs
[14:37] <rsalveti> ogra_: this syslog issue is annoying
[14:37] <rsalveti> ogra_: can't we just put some limits in it?
[14:37] <lool> didrocks: possibly not being able to upgrade
[14:37] <ogra_> rsalveti, yeah but i couldnt trigger it again
[14:38] <rsalveti> like, if we get a crazy process or something it'll quickly get most of the disk space
[14:38] <didrocks> lool: ok, I guess that case can be an exception if it's risking that
[14:38] <ogra_> yea, we'll do that for T
[14:38] <rsalveti> right
[14:38] <lool> (also we have no syslog rotation)
[14:38] <lool> ok
[14:38] <rsalveti> yeah, that's bad
[14:39] <lool> didrocks: so we can discuss this tomorrow; mandel is working on a small update over what's in trunk
[14:39] <lool> didrocks: should come in later today
[14:39] <didrocks> lool: ok, let's see how it's consuming, but yeah, that case, as it's risking not being able to upgrade later, seems one we can accept
[14:39] <lool> didrocks: then we can test, upload to proposed, get it reviewed as a 0day SRU or similar, then roll a saucy update image to test system-image saucy updates, then move to T?
[14:39] <didrocks> lool: but no branch, we'll just distro-patch and dput
[14:40] <lool> didrocks: we can even take it from trunk and push to saucy-proposed and T
[14:40] <lool> whatever
[14:40] <didrocks> yeah, let's see that tomorrow
[14:40] <lool> didrocks: I'll be on leave tomorrow; do you think you could handle it?
[14:40] <lool> didrocks: I've tested my current change, sil2100 did too
[14:40] <lool> with click and systme-image
[14:40] <lool> log is now /too/ quiet  :-)
[14:40] <lool> but things just worked as expected (almost nothign in log(
[14:40] <didrocks> lool: hum, what's the mandel's fix?
[14:41] <lool> didrocks: not super clear to me
[14:41] <didrocks> lool: do you think your change will be enough?
[14:41] <lool> didrocks: he had ambitious plans to fix this properly, but I made it clear this was a long term thing for T, that we wanted something short-term
[14:41] <sil2100> It silences all the DEBUG info for sure
[14:41] <lool> didrocks: he said my fix was ok short-term, but that he wanted to put in a tweak I think
[14:41] <lool> didrocks: see #ubuntu-touch for the exact wording
[14:43] <didrocks> lool: ok, I think you'll have soon more infos from what I read
[14:43] <didrocks> just ensure we have the minimal/quite change
[14:43] <didrocks> don't want that we spend time to test 100 fixes
[14:45] <lool> exactly
[14:45] <lool> also the diff should be minimal to review
[14:46] <didrocks> right
[14:46] <sergiusens> lool, didrocks are the image builds stopped untile T?
[14:46] <sergiusens> until
[14:46] <kalikiana> psivaa: any progress yet on the unlocking?
[14:47] <ogra_> sergiusens, there will be a fes saucy rebuilds with whatever desktop SRUs happened
[14:47] <ogra_> sergiusens, to test the stable upgrade mechanism
[14:47] <didrocks> sergiusens: so, we build image from saucy-updates (but not containing touch fix, it's only to test the infro)
[14:47] <ogra_> sergiusens, our focus is fully on T for everyone though
[14:47] <didrocks> sergiusens: but yeah, image builds with next things for us will start only with T
[14:47] <psivaa> kalikiana: not yet
[14:47] <didrocks> Monday/Tuesday
[14:47] <didrocks> we hpoe :
[14:47] <didrocks> we hope :)
[14:48] <ogra_> sergiusens, and image build are tecnically stopped since two months ... (automatic ones) ... we only build by hand
[14:48] <sergiusens> ogra_, didrocks well I was more into using the idle time into seeing if I could get app ap tests improved, and those aren't tied to any letter
[14:48] <lool> sergiusens: well
[14:48] <lool> sergiusens: you can cheat
[14:48] <kalikiana> psivaa: okay, just checking. the bug was set to "released" for some reason but there's no mr or comment
[14:48] <lool> sergiusens: you can upload some apps to appstore
[14:48] <didrocks> sergiusens: that would be excellent! :)
[14:48] <sergiusens> lool, click already cheats :-)
[14:48] <lool> right
[14:48] <psivaa> fginther: would you be able to take up this https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/ci-test/+merge/190906
[14:48] <lool> so in reality, only the archive thing is stopped for some days
[14:48] <ogra_> sergiusens, sounds fine ...
[14:48] <lool> but clicks keep moving on!
[14:48] <lool> how awesome/crazy is this?!
[14:49] <sergiusens> lool, also wanted to mention that we have to be extra careful with our SDK now
[14:49] <didrocks> yeah, but clicks will be the same packages in T
[14:49] <fginther> psivaa, yes
[14:49] <didrocks> there is no sery :)
[14:49] <psivaa> fginther: thanks v much
[14:49] <didrocks> sergiusens: don't tell me. backward compatibility forever now ;)
[14:49] <psivaa> kalikiana: sorry i was not very explicit when talking to fginther about that
[14:49] <sergiusens> didrocks, well that's the whole idea of the framework in click
[14:49] <sergiusens> :-)
[14:50] <sergiusens> didrocks, no deps, so there; base image has to be solid :-)
[14:50] <fginther> kalikiana, I'll catch up shortly, in a meeting at the moment
[14:50] <kalikiana> cool, thanks
[14:50] <didrocks> sergiusens: yeah ;)
[14:58] <lool> sergiusens: very rigt
[14:58] <lool> sergiusens: we should invest in some tests to make sure we dont drop / break ABI/APIs
[14:58] <lool> sergiusens: It would be great if we could scan the appstore for this BTW
[15:01] <t1mp> I have a question about automatic merging of approved MRs
[15:01] <t1mp> this MR just got merged - https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/tabs_chevron_asset_update/+merge/190639
[15:01] <t1mp> that's no problem - the MR is good - but I never saw a CI test report where all tests are passed. Just recently a jenkins Approved, without test report
[15:02] <t1mp> can someone explain me what's happening? are MRs being approved for merging manually?
[15:04] <rsalveti> didrocks: ogra_: lool: can we put the official release notes under https://wiki.ubuntu.com/Touch/ReleaseNotes ?
[15:06] <didrocks> rsalveti: if you want to copy/paste some part, please do. I think we should revisit the whole "known issues"?
[15:07] <rsalveti> didrocks: yup
[15:07] <didrocks> (like, we can remove power consumption/timezone)
[15:08] <didrocks> networking needs updating
[15:08] <didrocks> as well as telephony
[15:09] <rsalveti> yeah, needs to be updated completely
[15:10] <rsalveti> didrocks: where is the official release notes? I don't know if we moved stuff away from the gdoc document
[15:10] <didrocks> rsalveti: oh sure, one sec
[15:10] <didrocks> rsalveti: https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes#Ubuntu_for_phones
[15:10] <rsalveti> thanks
[15:11] <didrocks> yw ;) thank you!
[15:42] <lool> didrocks, rsalveti: Thanks for sorting it out, was in a HO
[15:43]  * lool moves into watching the news etc.
[15:57] <doanac> plars: was wondering - how much longer should we continue to run touch_ro testing?
[15:58] <doanac> ie - should we remove touch_ro and make touch_mir just be called "touch"
[15:58] <doanac> asac, ev ^^^
[15:58] <plars> doanac: probably a wider discussion
[15:59] <doanac> yeah. probably mailing list is better.
[15:59] <ev> do the Mir guys see value on having that comparison continue?
[15:59] <plars> doanac: I'd like to learn from our renames and understand if there are more image variations coming like the flipped, system-image, mir, etc that would cause us to run more parallel types so that we can name things sensibly
[16:02] <plars> doanac: want to go ahead and land your touch branch changes? :)
[16:03] <doanac> plars: sure. you ready for it?
[16:03] <plars> doanac: well, the release is done, so nothing that should hold us back now
[16:03] <doanac> k. i'll do it now
[16:04] <plars> doanac: I know you already have a lot of the next pieces worked up, but if there's something you want me to take a look at, let me know
[16:04] <plars> doanac: now that I'm out from under the release testing, I have some cycles freed up
[16:04] <doanac> plars: i'll be sending out some doc/examples later today. feedback on those will be great
[16:05] <plars> doanac: cool
[16:05] <doanac> plars: or better yet - just relax the rest of the day. you've earned it!
[16:07] <plars> doanac: nah, the day is still young :)
[16:10] <doanac> plars: our first "saucy" bug: http://paste.ubuntu.com/6251765/ :)
[16:10] <lool> ev: it was for mir switch and for landing team; I dont think we need these, but perhaps asac can confirm
[16:10] <lool> asac: Ok to kill touch_ro runs?
[16:10] <plars> doanac: hah
[16:10] <plars> doanac: just need to update the package
[16:14] <doanac> wow setup_jenkins.py is much slower than normal
[16:16] <doanac> plars: I think I'll tag revno 68 as "13.10" so we have a historical checkpoint
[16:16] <doanac> of lp:ubunut-test-cases/touch
[16:16] <plars> doanac: good idea
[16:16] <doanac> plars: branch merged and jobs re-configured
[16:39] <lool> didrocks: BTW I've retested the unity-mir thing, and it's indeed fast
[16:39] <lool> didrocks: I think I hadn't restarted my unity8 when I just upgraded the .deb (my bad)
[16:45] <didrocks> lool: excellent news :)
[17:14] <fginther> t1mp, sorry, just saw your message. https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/tabs_chevron_asset_update/+merge/190639 did pass CI, there is an approved message as the last comment from ps-jenkins
[17:24] <robru> didrocks, anything you want me to do today?
[17:25] <didrocks> robru: so no landing apart from SRU
[17:25] <robru> didrocks, what SRU?
[17:25] <didrocks> robru: can you look at things like desktopish?
[17:25] <didrocks> like compiz/nux/unity/indicators/hud
[17:25] <didrocks> you need to check that all bugs follow the SRU process
[17:25] <didrocks> or comply them to the SRU process if not ready
[17:25] <robru> didrocks, I don't know what you mean. what bugs? like you want me to check for recent trunk commits and then file SRUs for them?
[17:25] <didrocks> and test the proposed packages of course :)
[17:26] <didrocks> robru: you've never done a SRU?
[17:26] <robru> didrocks, yes I've done many SRUs. i just don't understand what SRUs there could possibly be on the day of release
[17:26] <didrocks> robru: look at http://people.canonical.com/~platform/cu2d/results
[17:26] <robru> didrocks, ok, otp brb
[17:26] <didrocks> you can see we have proposed unity and nux for instance
[17:27] <didrocks> (so upstream already have some nice fixes in trunk)
[17:27] <didrocks> you need to assess if they are good for SRUing in saucy
[17:27] <didrocks> and if so, the bugs needs to follow the SRU process
[17:27] <didrocks> robru: again, we are looking at desktop-only fixes
[17:27] <didrocks> we don't release anything (for now) for touch
[17:28] <didrocks> robru: oh, as well, I see that libfriends rebuilt with no change
[17:28] <didrocks> will be a good exercise and interesting to know why (it means there is a diff between trunk and if you build the source package from it)
[17:28] <fginther> asac, I would like to re-enable automerger for all projects. The only remaining disabled projects are unity8 and ubuntu-filemanager-app both of which have the same test failures for mir and ro with image 100
[17:29] <didrocks> robru: sent me an email for any question, dinner time here, see you tomorrow! :)
[17:29]  * didrocks waves good evening! enjoy the release everyone :)
[20:10] <cyphermox> fginther: hey
[20:10] <fginther> cyphermox, hi
[20:11] <cyphermox> fginther: delay that, I'm wondering if the issue I'm having isn't just slow things
[20:35] <cyphermox> alesage: hey
[20:35] <cyphermox> alesage: would you be able to check why https://code.launchpad.net/~larsu/libindicator/always-create-widgets/+merge/191701 doesn't seem to have been picked up by jenkins yet?
[21:06] <alesage> cyphermox, let's refer it to the CI team?
[21:21] <cyphermox> alesage_: yeah
[21:21] <alesage_> cyphermox, I don't want to name names :)