[04:21] <pitti> Good morning
[05:29] <didrocks> hello
[08:04] <Laney> hey hey
[08:04] <Laney> it's a fri-day
[08:04] <Laney> (/me checks calendar to make sure this is true)
[08:05] <seb128> Laney, hey, happy friday!
[09:28] <seb128> Laney, I think you have the chroot for that, can you try to crossbuild https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018/+files/ubuntu-system-settings_0.3%2B14.10.20140711-0ubuntu1.dsc
[09:28] <seb128> I lost my utopic install
[09:28] <seb128> damn inspiron
[09:28] <Laney> seb128: can do - what's this?
[09:28] <Laney> how do you lose an install?
[09:28] <seb128> Laney, it's the currently in silo settings landing
[09:28] <seb128> which includes the port to python3
[09:28] <Laney> look down the back of the settee
[09:29] <seb128> Laney, you try ubuntu-desktop-next, get Mir to lock, force power down the box, and the ext4 system messed up enough that the thing refuse to boot/get the kernel to throw a stacktrace at you on fsck runs
[09:30] <Laney> O_O
[09:30] <seb128> yeah...
[09:30] <seb128> so I'm downloading the current daily and doing a reinstall
[09:30] <seb128> that's fine, it's a test machine
[09:30] <seb128> but still, annoying
[09:30] <Laney> thought you were using an xps for that
[09:31] <seb128> that's the inspiron 11
[09:31] <Laney> oh wtf
[09:31] <seb128> the touch one I had in malta
[09:31] <seb128> they look like the xps
[09:31] <Laney> a man of many laptops
[09:31] <seb128> lol
[09:31] <Laney> anyway this doesn't work
[09:31] <Laney> let me see
[09:31] <seb128> :-(
[09:31] <seb128> could be the archive
[09:32] <seb128> leo tested the crossbuild when he submitted
[09:32] <seb128> or he screwed up his testing
[09:47] <didrocks> hum, nose config file doesn't seem to like having the same argument specified multiple times
[09:47] <didrocks> like --with-foo=bar --with-foo=baz
[09:47] <didrocks> while the command line takes it directly
[09:48] <Laney> the archive version fails to x-build too
[09:49]  * didrocks needs to use cov instead of coverage to be able to track subprocess coverage in integrations tests and only the first one supports that
[09:49] <didrocks> (and to have command line and html reports, the same options is used twice)
[09:54] <seb128> Laney, I'm going to assume it's not an issue in settings, since leo had it run and work
[09:55] <Laney> could be a problem with my mirror
[09:55] <Laney> lemme try with archive.u.c
[10:03] <Laney> c
[10:09] <seb128> Laney, ?
[10:13] <Laney> I think it is working
[10:13] <Laney> my mirror was out of date
[10:13] <Laney> more accurately, it was skewed between archive and ports
[10:15] <Laney> yeah that worked
[10:15] <seb128> great
[10:15] <seb128> thanks for testing!
[10:15] <Laney> but it seems that it was uploaded already anyway
[10:15] <seb128> well, I just pressed the button
[10:16] <seb128> I can do m&c now that it's confirmed to work ;-)
[10:16] <seb128> I want to do another landing this afternoon for the ofono work
[10:17] <seb128> the background maybe as well
[10:17] <Laney> what happened to running pep8 during the build?
[10:22] <seb128> Laney, that's not happening anymore?
[10:28] <Laney> well I grepped the log for pep8 and don't see it
[10:29] <seb128> yeah, it's not run
[10:30] <Laney> are any of the tests run?
[10:31] <seb128> wait, I'm looking at it
[10:31] <seb128> you dropped that in r682
[10:31] <Laney> llllllannnnnnnnnnnnnneeeeeeeeeyyyyyyyyyyyyyyyyy?
[10:31] <seb128> well, you dropped the overwrite
[10:32] <seb128> but I though the idea was to have that part of normal "make check"
[10:32] <seb128> right?
[10:32] <seb128> I'm trying to remember how that's supposed to work :p
[10:32] <Laney> yeah dh_auto_test should run the testsuite
[10:33] <seb128> it rusn "make test"
[10:33] <seb128> runs
[10:33] <seb128> you did a +add_test(NAME python COMMAND "${CMAKE_CURRENT_SOURCE_DIR}/test_code.py") in r682
[10:34]  * seb128 is looking at why that's not happening
[10:34] <Laney> check the build log from that version
[10:34] <Laney> 0411 in trusty, it does run tests
[10:35] <seb128> oh
[10:35] <seb128> it runs?
[10:35] <seb128> 4/6 Test #4: python3 ..........................   Passed    0.35 sec
[10:36] <Laney> so it does
[10:36] <Laney> it's because tests don't run when cross building
[10:36]  * Laney runs
[10:37] <seb128> lol
[10:37] <seb128> well, at least good, one thing we didn't regress
[10:46] <Laney> seb128: can you toss this one in next time maybe? https://code.launchpad.net/~laney/ubuntu-system-settings/as-activation/+merge/225953
[10:46] <Laney> didn't actually see that in practice but I did force it to happen
[10:46] <Laney> so not as important
[10:52] <seb128> Laney, sure, didn't you want to add tests for that? or same rational than the other one?
[10:52] <seb128> oh, just saw your comment, ok
[10:53] <Laney> https://bugs.launchpad.net/python-dbusmock/+bug/1340627
[11:59] <pmcgowan> bregma, couple of folks having issues with performance fwiw https://bugs.launchpad.net/compiz/+bug/1293384
[12:42] <didrocks> ok, I have my own config parser to replace the nose one for multiple repeated keys
[12:43] <seb128> because of the multiple options thing?
[12:43] <didrocks> yeah
[12:44] <seb128> is that a bug on their part? or a "design decision"?
[12:44] <didrocks> well, the issue isn't in nosetests but in the cov pluging
[12:44] <didrocks> plugin
[12:44] <didrocks> they shouldn't use the same arg multiple times
[12:44] <didrocks> or you can't use config file
[12:45] <didrocks> (configparser doesn't support that)
[12:45] <seb128> that somewhat makes sense
[12:45] <didrocks> right
[12:45] <seb128> having the same argument multiple time is confusing
[12:45] <didrocks> indeed
[12:45] <didrocks> basically, what I'm passing is:
[12:45] <didrocks> --cov-report=term-missing --cov-report=html
[12:45] <didrocks> because I want the terminal output for coverage AND the html one
[12:46] <didrocks> it's different options in the coverage modules
[12:46] <didrocks> that I happily used until today
[12:46] <didrocks> but for integration tests, I need to support subprocess()
[12:46] <didrocks> and the coverage module doesn't
[12:46] <didrocks> the nose-cov does
[12:48] <seb128> k, I see
[12:48] <seb128> having new fun every day ;-)
[12:54] <didrocks> exactly :p
[12:54] <didrocks> and I'm scratching my head on something related now as well…
[13:05] <didrocks> waow, really weird
[13:08] <didrocks> oh, I know…
[13:09] <seb128> what's the challenge this time? ;-)
[13:10] <didrocks> I was wondering why in my new integration directory, the tests were not executed
[13:10] <didrocks> tried multiple things, was thinking it was due to weird class name
[13:11] <didrocks> but actually, nosetests only run tests from files starting with "test_"
[13:12] <seb128> oh, one convention you need to know then
[13:12] <didrocks> yeah, I had multiple files like that, I just didn't think about it in this new dir
[13:14] <didrocks> seb128: especially because tests in tests/__init__.py are taken into account
[13:14] <didrocks> but not tests/large/__init__.py
[15:23] <Laney> parallel builds really make a difference to webkit build time
[15:23]  * Laney zzzzzzzz
[15:39] <seb128> Laney, your as-activation seems to make some tests unhappy?
[15:39] <Laney> does it?
[15:39] <seb128> "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-vHQLLI3uBn: Connection refused'
[15:39] <seb128> see https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/1303/?
[15:39] <seb128> I retried and it did the same error on same test
[15:40] <seb128> I wonder if that's case where it was skipping the call before and now is trying to issue it
[15:40] <Laney> which test?
[15:40] <seb128> doesn't make much sense
[15:41] <Laney> /var/local/autopilot/autopilot.log: FAIL: ubuntu_system_settings.tests.test_about.AboutTestCase.test_imei_information_is_correct(with mouse)
[15:41] <seb128> ignore what I wrote
[15:41] <Laney> what does that have to do with AS?
[15:41] <seb128> that doesn't seem related
[15:41]  * Laney wibbles
[15:41] <seb128> yeah, I was just wondering if it's doing it there
[15:42] <Laney> hmm don't you get a video for these?
[15:42] <Laney> wait that's coming from the test itself
[15:45] <seb128> yeah, dunno what's going on there
[15:45] <seb128> other mps have the same issue in fact
[15:52] <Laney> bah that test works for me
[15:58] <seb128> same here
[15:59] <Laney> hateful
[16:09] <attente> seb128: hi, can we do a landing for unity-gtk-module? https://code.launchpad.net/~indicator-applet-developers/unity-gtk-module/trunk.14.10/+activereviews
[16:09] <seb128> attente, hey, sure, it's friday 6pm here but I can do that next week
[16:11] <attente> seb128: ah, sorry, have a good w.e!
[16:11] <seb128> attente, no worry, thanks, you as well!
[16:11]  * Laney stares at this trace
[16:12] <Laney> could it be apparmor?
[17:09] <Laney> bye, have a good weekend!
[17:15] <didrocks> have a nice week-end everyone, see you on Tuesday!
[19:06] <kenvandine> humm... anyone else having unity7 failing to start on login?
[19:07] <kenvandine> or maybe that's not the cause...
[19:07] <kenvandine> init: at-spi2-registryd main process ended, respawning
[19:07] <kenvandine> seb128, ^^ ideas?
[19:08] <seb128> kenvandine, stacktrace?
[19:08] <kenvandine> i guess this is what happens now that i'm not on the desktop team... are you punishing me? :-D
[19:08] <kenvandine> looking
[19:08] <kenvandine> no crash files...
[19:08] <seb128> what happens if you run it by hand?
[19:08] <kenvandine> the gnome session isn't working either
[19:08] <seb128> exit? segfault? hang?
[19:08] <seb128> reboot
[19:08] <seb128> seems like your system is hosed
[19:09] <kenvandine> hang...
[19:09] <kenvandine> i rebooted once... let me try again
[19:09] <seb128> bt?
[19:09] <kenvandine> i see a
[19:09] <seb128> can you get a bt of the hang?
[19:09] <seb128> need to do that from a vt
[19:09] <kenvandine> intel_do_flush_locked falied message
[19:09] <seb128> oh
[19:09] <kenvandine> i did just get a new kernel
[19:10] <seb128> try the previous one
[19:10] <seb128> or power down the box
[19:10] <kenvandine> yeah... thx
[19:10] <seb128> sometime the hardware get in weird start and reboot doesn't fix it, powerdown does
[19:10] <seb128> yw!
[19:12] <kenvandine> powerdown worked
[19:12] <kenvandine> same kernel
[19:13] <seb128> k
[19:13] <seb128> not ubuntu's fault then ;-)
[19:13] <seb128> blame the hardware