[00:04] <elopio> veebers: wow, such a process.
[00:05] <elopio> am I understanding right? it is released now?
[00:05] <knome> abeyr, ubuntu-bug packagename, or go to launchpad.net and file a bug there
[01:04] <veebers> elopio: um, ayes? If it's not available in the archive yet it will be shortly. I get confused when and where that happens and where to check it
[01:05] <veebers> but it's done now
[09:59] <Mirv> ubuntuqa (was that the thing to ping?): we would need help debugging why autopilot tests fail randomly when using silo 18, see bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1421009
[10:00] <Mirv> it's related to DBus speeding up (working in threads) in Qt, and the current assumption is that the Qt itself works now better, just faster. the original bug is tested to be fixed, but AP:s start failing pretty randomly in all suites.
[10:00] <Mirv> ubuntu-qa ^
[10:02] <rhuddie> Mirv, have you got some results we can look at?
[10:03] <Mirv> rhuddie: http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ the ones ending with -018.tests
[10:03] <Mirv> if one eg grep - cut - sort -uniq:s UITK failures, they are different on each run so seems random
[10:05] <Mirv> so -1- and -2- are two runs of the same suite
[10:10] <rhuddie> Mirv, so for example in http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_24-21_48_11-address_book_app-1-018.tests
[10:11] <rhuddie> Mirv, the first error is in address_book_app.tests.test_add_contact.TestAddContact.test_go_to_add_contact, which fails to launch the address book
[10:12] <rhuddie> and then the remaining tests fail with: subprocess.CalledProcessError: Command '['/sbin/initctl', 'stop', 'maliit-server']' returned non-zero exit status 1
[10:18] <Mirv> rhuddie: right, the http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/ap-2015_03_24-21_48_11-ubuntuuitoolkit-1-018.tests would also seem to be about launching, right? but in that case it just doesn't fail all the remaining tests, it's just that some tests fail to launch
[10:18] <Mirv> rhuddie: the launching is done via DBus I guess, would that be autopilot itself or ubuntu-app-launch doing it?
[10:25] <rhuddie> Mirv, yes, this seems similar problem. The actual error is that it can't find the process to introspect it. Which could mean that the original process has crashed (check for .crash files in /var/crash)
[10:26] <rhuddie> or it could mean that introspection is not enabled, but this should be set automatically in the base class.
[10:28] <rhuddie> Mirv, in this case upstart is being used to launch the app
[10:34] <Mirv> ok, I didn't see any particular amount of crashes, so I was thinking it'd be dbus signaling problem about launching the app. but I don't have the crash files anymore with me so I'll run a bit more and see if anything turns up.
[10:39] <Mirv> rhuddie: do you know if it's autopilot using qdbus to call upstart or what's the route of launching app?
[10:51] <rhuddie> Mirv, I'm not sure, ubuntu-qa, anyone know answer to -^
[10:53] <brendand> Mirv, totally depends on the AP test itself, the way the app is launched doesn't matter as long as it's launched with QT_LOAD_TESTABILITY=1 in it's environment
[10:53] <brendand> Mirv, which for upstart launched applications would have to be in upstarts environment (initctl set-env)
[10:54] <brendand> Mirv, give us an example test where this is happening
[10:56] <Mirv> brendand: see the backlog, but about any test can fail like that (randomly) when used with silo 018 that contains Qt DBus related fixes. and I'm trying to find out whether the problem could be fixed in AP (by adjusting something) or whether someone can debug it enough to state that no the Qt patches are still broken somehow regarding the DBus usage
[10:56] <Mirv> with the patches the Qt DBus starts supporting threaded usage of DBus which fixes the Unity 8 deadlock on boot randomly, triggered by libusermetrics starting to use DBus earlier...
[10:57] <Mirv> the actual boot problem gets fixed by the patched Qt, but of course we can't regress on the AP side. and it's hard to say whether it's Qt's fault now or if it's just changed behavior AP needs to take into account.
[10:58] <brendand> Mirv, so the launch of the app happens asynchronously?
[11:05] <Mirv> thanks tsdgeos. brendand is starting to ask difficult questions :) http://irclogs.ubuntu.com/2015/03/25/%23ubuntu-quality.html just updated to include all backlog.
[11:06] <Mirv> I'm not sure who can answer what exactly is being called when app is being launched from autopilot, and whether the Qt DBus patches would now make it asynchronous or not
[11:07] <Mirv> but we need at least someone who understands the Qt DBus changes, someone who understands Autopilot and someone who understands app startup..
[11:07] <tsdgeos> you have a 0 sized group in there
[11:07] <tsdgeos> :D
[11:07] <tsdgeos> so are we sure the problem is that the app launch is not being detected by autopilot?
[11:08] <tsdgeos> or is it that the app isn't actually launching?
[11:08] <Mirv> tsdgeos: and sorry for hijacking you, just be available when you have time :) currently it'd look like something in the Qt changes causes app startups during tests to randomly fail, and we'd need to find out if it's Qt's fault or something that can be fixed in AP
[11:08] <Mirv> no I don't think we're sure, this is all just based on the logs so far
[11:08] <tsdgeos> someone should run the test looking at the phone and see if the app is actually there and undetected
[11:08] <tsdgeos> or just has crashed
[11:09] <tsdgeos> it may very well be that those patches are making stuff crash
[11:09] <Mirv> I'm running UITK tests again right now. a crash would result in a .crash, right? none so far except one for telepathy_mission-control which is maybe not related
[11:10] <brendand> tsdgeos, +1
[11:10] <tsdgeos> Mirv: it should probably create a .crassh yeah
[11:11] <brendand> Mirv, which vivid image? latest?
[11:23] <Mirv> brendand: latest + silo 18 that fixes the original bug
[11:35] <jibel> davmor2, on desktop i386 20150325, boot, on the welcome screen select French then 'Essayer Ubuntu'
[11:36] <jibel> davmor2, the live session doesn't start and I get a login screen
[11:36] <jibel> davmor2, it is in a VM
[11:36] <davmor2> jibel: I'll check in a minute for you
[11:36] <jibel> davmor2, amd64 with UEFI starts fine
[11:41] <jibel> davmor2, amd64 works fine
[11:41] <jibel> even in BIOS mode and non-english
[11:50] <davmor2> jibel: when you get to the live session after selecting French should it be in French?
[11:57] <davmor2> jibel: man this is weird I select French I tap on Essayer Ubuntu, Language is set to English_US and yet I see Exemples and Installer Ubuntu 15.04, most of the rest is in English
[11:59] <Mirv> tsdgeos: brendand: ok ran UITK tests, 9 errors, no .crash files. could indicate the launch happens but due to Qt changes something is too fast and AP doesn't notice it?
[12:00] <brendand> Mirv, let's see the logs again
[12:00] <tsdgeos> Mirv: can you try running that ap test only and seeing if something actualyl shows on screen?
[12:01] <Mirv> brendand: added, the last one at http://people.canonical.com/~tjyrinki/qt5/fail/qtbase_ubuntu5/
[12:02] <Mirv> tsdgeos: it's not "that test", it's any test but only rarely, plus randomly. the failures are always different, and about 8 out of 250 fail.
[12:02] <Mirv> sorry, out of 365
[13:12] <Mirv> brendand_: tsdgeos: ok I can reproduce it with while [ 1 ] ; do phablet-test-run ubuntuuitoolkit.tests.custom_proxy_objects.test_header.SectionsTestCase.test_select_sections_with_sections_disabled ; done - when the failure does happen, the app launches fine, autopilot (or something) apparently just doesn't notice it. what's next?
[13:12] <Mirv> I stared at the phone screen for enough long time for the failure to happen :)
[13:12] <brendand_> Mirv, i'll need to get some time to take a look, maybe later today
[13:13] <Mirv> okay. I'll update the bug soon when I've played with it a bit more.
[13:32] <Mirv> bug #1421009 updated
[13:48] <jibel> davmor2, yeah the live session is half translated, but it has been like this for a long time. live session not starting on i386 seems to be a qemu specific bug. It works fine on HW and Vbox
[13:49] <davmor2> jibel: yeah it's starting for me that how I know the translations things is crap :)
[14:01] <sil2100> brendand_: thanks for the help with the Mirv's issue :) It's one of our blockers currently as the silo causing the AP problems is actually a fix for a hanger-regression
[14:08] <brendand_> sil2100, well i haven't been able to do too much yet
[14:08] <brendand_> sil2100, i'll check if we can divert some resources to looking at it
[14:11] <sil2100> Excellent
[14:23] <brendand_> sil2100, btw are we talking vivid or rtm?
[14:27] <jibel> davmor2, I cannot get anything to work in a VM
[14:27] <jibel> davmor2, system doesn't boot after installation tried vbox and qemu
[14:28] <davmor2> jibel: ouch let me try in vm and see if I can confirm
[14:30] <sil2100> brendand_: vivid
[15:25] <davmor2> jibel: I can confirm that I'm not able to get to live desktop on i386 in kvm
[15:25] <davmor2> jibel: it takes me to the login screen and I can't login
[15:31] <davmor2> jibel: did you file a bug for it?
[15:33] <jibel> davmor2, not yet, I'm trying to have at least a successful install in a VM
[15:34] <jibel> davmor2, in vbox, amd64 installation, it tells me there is no bootable device after installation
[15:34] <jibel> davmor2, did you do an amd64 install on HW?
[15:35] <davmor2> jibel: it's running now, I've done i386
[15:39] <davmor2> jibel: 64bit on kvm is working as expected
[15:39] <jibel> davmor2, are you on vivid or utopic?N
[15:39] <jibel> -N
[15:40] <davmor2> jibel: vivid 64bit as host
[15:40] <jibel> davmor2, hm, can you check the checksums of your images?
[15:43] <davmor2> davmor2@boromir:~$ md5sum *.iso
[15:43] <davmor2> 17384a4d4a5c8471d1e766ffe10dd6ec  vivid-desktop-amd64.iso
[15:43] <davmor2> c74c7dbdc60d2c8bbd08ce4b7c4f95b6  vivid-desktop-i386.iso
[15:45] <davmor2> jibel: that matches http://cdimages.ubuntu.com/daily-live/current/MD5SUMS
[15:45] <jibel> davmor2, doesn't look like the latest image
[15:46] <davmor2> jibel: it's the latest in current
[15:46] <jibel> davmor2, yeah there is something wrong here, desktop images are stuck in pending
[15:47] <jibel> davmor2, try with http://cdimage.ubuntu.com/daily-live/pending/MD5SUMS
[15:47] <jibel> which are the images on the tracker
[15:48] <jibel> davmor2, can you check the version of these image? is it 20150325?
[15:49] <davmor2> jibel: hmmm okay they are indeed different
[15:53] <rhuddie> Mirv, I had a go at reproducing the problem with silo 18. I ran an address book app test and it failed on 10th attempt with same error as in the logs.
[15:53] <rhuddie> Mirv, for the failure, the address book started to launch, but then the app froze completely
[15:54] <rhuddie> autopilot then timed out waiting for the app to launch which is when the test failed
[15:54] <rhuddie> There was a crash file for _usr_lib_telepathy_mission-control-5.32011.crash
[15:55] <rhuddie> but nothing for the address book app
[16:01] <davmor2> jibel: right updated the image retrying now
[16:10] <balloons> ubuntu-qa, thoughts on seeing this error on tests in trunk that used to pass for clock app? http://paste.ubuntu.com/10678560/. Error is "org.freedesktop.DBus.Error.ServiceUnknown:"
[16:16] <flexiondotorg> Is there anything I can do to help progress http://launchpad.net/bugs/1432285
[16:17] <flexiondotorg> I think it is a more significant issue than "Medium".
[16:17] <davmor2> jibel: amd 64 is working in kvm with -vga vmware I'll try without that too
[16:17] <jibel> davmor2, here too, finally
[16:17] <jibel> davmor2, in BIOS mode in vbox
[16:17] <jibel> davmor2, I'll retry UEFI
[16:26] <elopio> brendand_: please take a look at the fakeroot card. Looks like a deadend.
[16:39] <brendand_> elopio, maybe. pitti will be back tomorrow to save the day
[16:43] <elopio> as always :)
[16:43] <elopio> if it will take time to fix, I'd go with exporting the pythonpath.
[16:55] <brendand_> elopio, thing is i tried that and it didn't work
[16:55] <brendand_> elopio, doesn't transfer between users
[16:55] <elopio> brendand_: you might need to export the path also on the new user.
[16:55] <brendand_> elopio, again i'll talk to pitti about it. i'm sure there's a way
[16:56] <elopio> yes, lets wait.
[16:58] <rhuddie> brendand_, I reproduced the silo 18 issue. For me the app froze as it was launching, which made autopilot timeout and then fail the test as it couldn't introspect it.
[16:59] <rhuddie> brendand_, So to me it seems like its not an autopilot issue. I updated the bug with some notes: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1421009
[17:00] <brendand_> rhuddie, aha
[17:00] <elfy> afternoon quality chaps and chapesses
[17:17] <balloons> howdy howdy elfy
[17:41] <elfy> hi balloons :)
[18:13] <elfy> balloons: quick question - cos I'm confused
[18:14] <elfy> if things and images are being autotested - how come things like the keyboard setting part can go missing and no-one notices?
[18:14] <elfy> or is it that images still not being checked?
[18:18] <balloons> elfy, if it shows up as a bug in the image, I think it's safe to conclude we don't have a test for it :-) In general, the tests for the images are basic. The tests for the images that block on being published are really basic  and don't test ubiquity
[18:23] <elfy> ok - thanks
[18:24] <elfy> just wanted to make sure - I assume that was probably the case
[18:24] <elfy> s/assumed
[21:33] <alesage> ok maybe I'll ask balloons about this click-install failure of weibo http://pastebin.ubuntu.com/10680643/ , if you were me and secondly you had the patience to explain to yourself, how would you fix?