[07:08] <didrocks> Saviq: hey, I don't remember if you looked/told me about that issue (it's the only non-crash related AP test failure that remains): http://ci.ubuntu.com/smokeng/trusty/touch/mako/232:20140311.2:20140304/7098/unity8/879786/
[09:20] <tsdgeos> Cimi: any luck with those crashes?
[09:31] <Cimi> tsdgeos, nope
[09:34] <Saviq> didrocks, it passes here :/
[09:34] <didrocks> Saviq: sil2100 is going to look at it, he reproduced it
[09:34] <didrocks> (and we have it 100% of the time on the dashboard)
[09:37] <Saviq> didrocks, it looks like the app doesn't start when it fails
[09:38] <Saviq> didrocks, 'cause the failing test checks that the currently focused app is as expected
[09:38] <Saviq> sil2100, ↑
[09:38] <Saviq> but it completes reliably here :
[09:38] <Saviq> :/
[09:44] <sil2100> Saviq: hi, so, as I already mentioned it on the meeting now, I remember seeing it when running the whole unity8 test-suite yesterday - running just the single test doesn't reproduce it, as it passes
[09:44] <sil2100> Saviq: but let me finish this one test run
[09:45] <Saviq> sil2100, k, I'm upgrading my device
[09:45] <Cimi> tsdgeos, try
[09:45] <Cimi> branch lp:~unity-team/unity8/new-scopes-cleanup-5.2
[09:45] <Saviq> sil2100, I suspect the test app just fails to start, as it sometimes happens in real life, but there doesn't seem to be a .crash file
[09:45] <Cimi>  with landing-006 ppa
[09:45] <Cimi> make testDashContent
[09:45] <Cimi> it segfaults every nce a while
[09:45] <Cimi> http://paste.ubuntu.com/7075029/
[09:46] <tsdgeos> Cimi: i'm busy somewhere else, it'd be cool if you could work on fixing ti
[09:46] <Cimi> tsdgeos, I don't know how to fix malloc
[09:47] <tsdgeos> ok, do something else then :)
[09:49] <sil2100> Saviq: what worries me that on smoketesting it's so reproducible
[09:50] <Saviq> sil2100, yeah, it's weird
[10:03] <sil2100> Saviq: ok, so actually strangely the first whole-suite run didn't reproduce the issue ;/ Weird...
[10:04] <Saviq> sil2100, I'm running unity8.application_lifecycle in a loop to see if we can limit it to that
[10:15] <tsdgeos> MacSlow: do you guys have somethign like https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8 for unity-notiifcations?
[10:15] <tsdgeos> MacSlow: or should i use that one?
[10:24] <Saviq> sil2100, still running... all passed...
[10:26] <sil2100> Saviq: same here, craaaap ;/
[10:29] <MacSlow> tsdgeos, no
[10:30] <MacSlow> tsdgeos, but to be sure I'd need to ask thostr
[10:31] <tsdgeos> greyback: "unity8 is not Mir only." -> "unity8 is now Mir only." ?
[10:32] <greyback> tsdgeos: darn
[10:33] <tsdgeos> MacSlow: i'm a bit confused by https://code.launchpad.net/~macslow/unity-notifications/dont-ignore-placeholder/+merge/206950
[10:33] <tsdgeos> MacSlow: the changes in examples are unrelated, no?
[10:35] <MacSlow> tsdgeos, yes... just cosmetics
[10:36] <tsdgeos> MacSlow: ok, commented in the MR too, answer there when you have time
[10:42] <MacSlow> tsdgeos, replied
[10:45] <tsdgeos> MacSlow: ok
[10:45] <MacSlow> tsdgeos, would you want an additional test?
[10:46] <tsdgeos> MacSlow: i'd like an additional test that shows the need for the change
[10:46] <tsdgeos> i mean, you're changing code and then adapt the tests so that they pass again
[10:46] <tsdgeos> but why we need the code to change?
[10:48] <sil2100> Saviq: this is really strange, I could swear that yesterday I got the failure
[10:48] <Saviq> mzanetti, hey, I pushed a new commit to https://code.launchpad.net/~unity-team/unity8/themeing-font-and-mascot/+merge/207282 if you could have a look (it's just dropping a bit of the code for future refactoring)
[10:48] <sil2100> Saviq: today it's like unreproducible
[10:48] <mzanetti> Saviq: ack
[10:49] <Saviq> sil2100, indeed, I just looped the whole suite to see what I get
[10:52] <mzanetti> Saviq: as I switched to 5.2, make trySomething doesn't work any more. same for you?
[10:52] <Saviq> mzanetti, yes
[10:53] <Saviq> mzanetti, we need to make a qmltryrunner
[10:53] <mzanetti> hehe
[10:53] <Saviq> mzanetti, 'cause qmltestrunner registers Qt.test.testroot now internally
[10:53] <mzanetti> yeah... that's what it seems
[10:56] <mzanetti> Saviq: https://code.launchpad.net/~unity-team/unity8/themeing-font-and-mascot/+merge/207282/comments/496082
[10:56] <Saviq> mzanetti, that's under 5.2
[10:56] <Saviq> mzanetti, fixed in 5.2 fixes branch
[10:56] <mzanetti> oh crap :D
[10:57] <Saviq> mzanetti, it would fail without my change, too
[10:57] <mzanetti> yeah, that's what I said too in the comment
[10:57] <Saviq> yup
[11:10] <Saviq> mzanetti, one more... http://bazaar.launchpad.net/~unity-team/unity8/themeing-font-and-mascot/revision/746
[11:13] <tsdgeos> woot
[11:13] <Cimi> really need to buy a new pc
[11:13] <tsdgeos> landing 6 is broken?
[11:13] <Saviq> tsdgeos, why so?
[11:13] <Saviq> Cimi, don't you have hardware refresh coming up?
[11:13] <tsdgeos> i dist-upgraded, it removed unity and unity8 and can't install them back
[11:14] <Cimi> Saviq, I had few months ago
[11:14] <Saviq> Cimi, and you need it again already? ;)
[11:14] <Saviq> tsdgeos, apt-cache policy unity8?
[11:14] <Cimi> Saviq, I meant the bonus!
[11:14] <Cimi> Saviq, didn't buy anything yet
[11:14] <Cimi> Saviq, thinking of a desktop pc
[11:14] <Cimi> Saviq, cheaper and faster
[11:15]  * mzanetti couldn't imagine being bound to a desk any more
[11:15] <Cimi> but cannot decide
[11:15] <Saviq> Cimi, tricky to carry, though ;)
[11:15] <Cimi> Saviq, macbook air for trips
[11:15]  * Saviq neither, is looking at 13" max in Sep
[11:16] <Saviq> Cimi, just put something in a cupboard and use distcc and such
[11:16] <Cimi> macbooks are incredible machines, but I wasn't lucky with hardware support in ubuntu, that's why I run it in VM inside osx
[11:17] <mzanetti> Cimi: huh? those are the only machines where everything works I've ever had
[11:17] <Cimi> don't know about the alternatives
[11:17] <Cimi> mzanetti, I had wifi issues, like 1MB/s
[11:17] <mzanetti> Cimi: true... I had wifi issue too, but then I found the correct driver
[11:17] <Cimi> 1Mb/s
[11:18] <mzanetti> and I think that's really not related to the MacBook but rather the wifi Chip and those are mostly the same in all machines nowadays
[11:18] <Cimi> so all sucks
[11:18] <Cimi> like mhr3 wifi
[11:18] <mzanetti> wifi & linux. yeah... still a pity in overall
[11:18] <Cimi> he was not able to connect to my home wireless yesterday
[11:19] <mzanetti> but my current status is awesome. rock-stable, connects in less than a second and copies ~15MB/s
[11:19] <mhr3> Cimi, the sad part is that it worked under windows in the end
[11:19] <Cimi> mzanetti, that's the speed I have when I browse the web :P
[11:19] <mzanetti> Cimi: megabytes that is
[11:19] <Cimi> mzanetti, same here
[11:19] <Cimi> B)
[11:19] <mzanetti> what you mean with "when you browse the web"?
[11:20] <Cimi> mzanetti, downloaded with phablet-flash yesterday at average of 14.6MB/s
[11:20] <tsdgeos> Saviq: http://paste.ubuntu.com/7078775/ http://paste.ubuntu.com/7078773/ http://paste.ubuntu.com/7078772/
[11:20] <mhr3> Cimi, don't exaggerate, it's just 12.2 :P
[11:20] <tsdgeos> Saviq: is it because i have new-scopes?
[11:20] <Saviq> tsdgeos, what ppas do you have enabled?
[11:21] <tsdgeos> Saviq: demo-stuff and landing6 i think
[11:21] <mhr3> Cimi, oh, wait, no you're right, it was 14 something
[11:21] <Saviq> tsdgeos, drop demo-stuff
[11:21] <tsdgeos> ok
[11:21] <mzanetti> Cimi: what internet connection do you have?
[11:22] <Cimi> mzanetti, 125/12
[11:22] <mhr3> Saviq, tsdgeos, btw we're building latest scopes-related stuff in 003
[11:22] <mhr3> minus 5.2
[11:22] <Saviq> mhr3, k thanks
[11:34] <tsdgeos> Saviq: ok, that helped
[11:42] <Saviq> MacSlow, hmm, how did the notifications test work with wrong notification id¿?
[11:42] <MacSlow> tsdgeos, I've found the issue of the failing sd-incoming-call AP-test
[11:43] <MacSlow> Saviq, yeah... that's what I don't get either :/
[11:43] <MacSlow> Saviq, I also don't get why all but that one objectName was correct
[11:44] <Saviq> MacSlow, bzr qblame will tell you ;)
[11:44] <MacSlow> Saviq, I already did that
[11:44] <MacSlow> Saviq, some r655 from me
[11:45] <Cimi> mhr3, dednick when next one with better performances in l4d2?
[11:45] <Saviq> MacSlow, r660 "Fixed the failure of notification autopilot-test test_sd_incoming_call."  actually
[11:45] <MacSlow> Saviq, hm..
[11:46] <Saviq> MacSlow, you did a s/notification1/notification0/ in there
[11:46] <Saviq> in January...
[11:46] <mhr3> Cimi, whenever we let bots play instead of us :D
[11:46] <Cimi> ahaha
[11:46] <Saviq> didrocks, so, what's the deal with landing, could we get a silo for unity8 or would you rather us wait?
[11:47] <dednick> Cimi: hehe. i'll try practice a bit before our next session :)
[11:48] <sil2100> Saviq: not much luck here, I wonder what CI smoketesting does differently
[11:48] <tsdgeos> Cimi: so lp:~unity-team/unity8/new-scopes-cleanup-5.2 is new-scopes + fix-5.2
[11:48] <Saviq> mzanetti, could you review https://code.launchpad.net/~unity-team/unity8/new-scopes-cleanup/+merge/209642? it's 7k diff, but fortunately +1010/-5304
[11:48] <tsdgeos> right?
[11:48] <Cimi> tsdgeos, yes
[11:48] <Saviq> tsdgeos, Cimi, let's not use new-scopes, only new-scopes-clean-to-trunk, btw
[11:49]  * Saviq marks new-scopes as abandoned or something
[11:49] <Cimi> tsdgeos, new-scopes-cleanup + 5.2 Saviq
[11:49] <Saviq> k
[11:49] <Saviq> better
[11:49] <tsdgeos> yes yes, that's what i wanted to say
[11:49] <mzanetti> Saviq: how many branches are there? :D
[11:49] <Saviq> I expected as much, just wanted to clear it up
[11:49] <Cimi> i could have called new-scopes-cleanup-segfaults as well
[11:49] <Saviq> mzanetti, there will only be one once you review that one ;)
[11:50] <Saviq> mzanetti, this last one was only about cleanup and fixing tests
[11:50] <Saviq> mzanetti, I want to merge it into new-scopes-clean-to-trunk, but thought it would be easier to review separately
[11:51] <mzanetti> Saviq: ok. will take a little while tho... currently debugging something in the right-edge stuff
[11:51] <MacSlow> Saviq, I don't have qblame ... regular bzr blame shows it was rev 655.1.2 from me touching that line the last time.
[11:51] <mzanetti> it crashes when started by upstart, but works fine when launched manually.
[11:51] <tsdgeos> new-scopes-cleanup is so big that reaches the limit of launchpad diffs
[11:51] <tsdgeos> too many code killed
[11:51] <Saviq> MacSlow, yeah, but that's a subcommit that landed as r660 in trunk
[11:52] <Saviq> tsdgeos, yeah, 1.5 overflow (5k limit in LP, diff is > 7k
[11:52] <MacSlow> Saviq, qblame is part of which package... qbzr?!
[11:52] <Saviq> MacSlow, yes
[11:52] <tsdgeos> Cimi: which of the testDashContent tests segfaults for you?
[11:53] <Cimi> tsdgeos, it segfaults after a while, end
[11:53] <Cimi> tsdgeos, sometimes, not always
[11:53] <tsdgeos> Cimi: that's not the answer to the question i made :D
[11:53] <Cimi> tsdgeos, near the end
[11:53] <Cimi> don't remember now
[11:53] <tsdgeos> Cimi: can you give me a name?
[11:53] <Cimi> tsdgeos, I would if I could now :)
[11:55] <Saviq> pete-woods, hey... just reading your email... couldn't this be a QAbstractListModel directly, without the call to -> infographics? also... IIUC the file names don't change? could we have timestamps in filenames?
[11:56] <Cimi> tsdgeos, it segfaults at the end I believe
[11:56] <Cimi> tsdgeos, after all tests
[11:56] <Cimi> when it reports back
[11:56] <Cimi> it segfaults
[11:56] <tsdgeos> ok
[11:56] <tsdgeos> working fine here
[11:56] <tsdgeos> i've looped it a lot
[11:56] <Cimi> tsdgeos, I tried on two different machines
[11:56] <tsdgeos> Cimi: is that an i386 machine?
[11:56] <Cimi> tsdgeos, both segfaults
[11:56] <Cimi> tsdgeos, both amd64
[11:57] <Cimi> a VM inside osx
[11:57] <Cimi> a native ubuntu
[11:57] <tsdgeos> been running for a while here
[11:57] <tsdgeos> no crash at all
[11:57] <tsdgeos> will let it run a few more mins
[11:58] <pete-woods> Saviq: I really just wanted to keep the filenames watching as simple as possible - i.e. not having to worry about removing the "old version" of the file, that sorta thing
[11:58] <Cimi> tsdgeos, it crashes always here
[11:58] <pete-woods> Saviq: we just watch them using QFilsSystemWatcher
[11:59] <tsdgeos> Cimi: that is weird
[11:59] <Saviq> pete-woods, I hope you're not replacing them in-place, though, but writing in a temporary location and atomic mv on success? ;)
[11:59] <pete-woods> Saviq: yes :)
[11:59] <pete-woods> have been burned by that in the past
[12:00] <Cimi> tsdgeos, you on landing 006?
[12:00] <tsdgeos> yes
[12:00] <didrocks> Saviq: can get a silo, just please don't publish until click is fixed
[12:00] <didrocks> Saviq: however, unity8 is blocked by the 5.2 landing, right?
[12:00] <Saviq> didrocks, yes, that's what I was asking about
[12:00] <Cimi> @unity who can try one branch and one test with qt 5.2?
[12:00] <didrocks> Saviq: yeah, so I guess you need 5.2 to land first
[12:01] <Saviq> didrocks, ok, is fine
[12:01] <didrocks> sil2100: Saviq: any luck with the AP test failure btw? Weird that CI can reproduce it everytime :/
[12:01] <Cimi> Saviq, can you try if you get the malloc?
[12:01] <didrocks> and as we have it in the modified 5.2 testsuite as well…
[12:01] <Saviq> pete-woods, so... this just complicates the api and the shell's job a bit, as there isn't a reload() for images, and generally, matching which file we'll have to reload is a bit problematic
[12:01] <Cimi> I have it with two machines out of two
[12:03] <Saviq> pete-woods, if you really want to keep the file names, I'd rather you emit a dataChanged for them with empty string for url and then replace it with the correct path again, but that's slightly hackish, too
[12:03] <tsdgeos> xvfb-run -s "screen 0 1024x768x24" make testDashContent
[12:03] <tsdgeos> should this ↑↑ work ?
[12:03] <Saviq> tsdgeos, should, yes, what doesn't?
[12:03] <pete-woods> Saviq: okay, so what you're really looking for then is for all the change notification to be via the item model then
[12:04] <Saviq> tsdgeos, ah, missing "-" before "screen" I think
[12:04] <Saviq> tsdgeos, yeah, looks like it
[12:04] <Saviq> tsdgeos, also, if you're on nvidia, LD_PRELOAD=/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
[12:04] <pete-woods> and you want the filename to change to workaround the QML image objects not supporting refreshing
[12:04] <tsdgeos> ok, missing -
[12:06] <Saviq> pete-woods, I wouldn't call it a workaround, but yes, all changes should come via the model itself, otherwise we need to be jumping hoops
[12:06] <Saviq> pete-woods, but also, caching images in Qt only looks at the URI
[12:07] <Saviq> pete-woods, so we might have issues with that if file names don't change (although if we disable caching, this should be fine)
[12:08] <pete-woods> Saviq: are you also asking me to make the InfographicList class just extend QAbstractItemModel?
[12:08] <pete-woods> in addition to it having the method to set the user's UID?
[12:08] <Saviq> pete-woods, basically, IMO it would be cleaner if the filename changed (and dataChanged was emitted) while both files are still available, and only then the old one would get removed
[12:08] <Saviq> pete-woods, I don't see a reason why not
[12:08] <pete-woods> okay, I can do that
[12:08] <Saviq> pete-woods, and from my PoV, a property, not a method ;)
[12:08] <pete-woods> yeah, sure
[12:09] <Saviq> pete-woods, don't get me wrong, I'm not requiring here, just discussing :)
[12:09] <pete-woods> it is a Qt property now
[12:09] <mzanetti> Cimi: still need that 5.2 testing?
[12:09] <pete-woods> well I want to make the API how you want it
[12:09] <Cimi> mzanetti, yes
[12:09] <mzanetti> Cimi: which branch?
[12:09] <sil2100> didrocks: sadly, still no luck :|
[12:09] <Saviq> pete-woods, with files replaced I'd be worried about races in case stuff gets refreshed while I'm loading the file
[12:10] <Saviq> pete-woods, I'd probably get the old file then
[12:10] <Cimi> lp:~unity-team/unity8/new-scopes-cleanup-5.2,  with landing-006 ppa, make testDashContent
[12:10] <Saviq> pete-woods, and not refresh it until the next filesUpdated signal
[12:10] <pete-woods> Saviq: yes you would, alhough you'd just get another  signal, yes
[12:10] <Cimi> mzanetti, ^
[12:10] <Cimi> mzanetti, it segfaults here with two different pc
[12:10] <tsdgeos> Cimi: it crashed now under xvfb-run
[12:11] <tsdgeos> which is also a bit more convinient
[12:11] <tsdgeos> since don't need to get the flashing window on screen all the time
[12:11] <Saviq> yikes we get plenty of warnings...
[12:12] <Saviq> pete-woods, anyway, I'll write those down as a comment in the PM
[12:12] <Saviq> MP
[12:12] <pete-woods> Saviq: thanks
[12:12] <Cimi> tsdgeos, you got the segfault?
[12:13] <tsdgeos> yes
[12:13] <tsdgeos> just need to integrate the gdb with the while loop and xvfb-run
[12:13] <Cimi> tsdgeos, it segfaults with malloc
[12:14] <Cimi> tsdgeos, if you then can tell me how you understand what is crashing
[12:14] <Cimi> I'd be happy to learn
[12:14] <tsdgeos> i'll tell you once i learn :D
[12:14] <Cimi> hahaha
[12:14] <mzanetti> not crashing here
[12:14] <mzanetti> neither normal nor in xvfb-run
[12:14] <Cimi> mzanetti, try again
[12:14] <mzanetti> tried 3 times so far
[12:15] <Cimi> mzanetti, it crashes when it gives results
[12:15] <mzanetti> got one test fail tho
[12:15] <Cimi> mzanetti, carouselpreview?
[12:15] <Cimi> something like that?
[12:15] <mzanetti> yes
[12:15] <Cimi> I got that unreliable
[12:15] <Cimi> yes
[12:15] <mzanetti> yeah. happened 2 out of 4 times now
[12:15] <mzanetti> and now I got the crash
[12:15] <Cimi> yay
[12:17] <tsdgeos> the great while loop
[12:17] <tsdgeos> http://paste.ubuntu.com/7078989/
[12:17] <mzanetti> tsdgeos: we need make testSomething to integrate with xvfb ;)
[12:17] <tsdgeos> mzanetti: and with gdb
[12:19] <tsdgeos> Cimi: it actually crashes in free not in malloc (at least here http://paste.ubuntu.com/7078998/)
[12:19] <mzanetti> yeah.... dtor. deleteChildren()
[12:20] <mzanetti> most likely something that is deleted but has a parent to some other Qtobject which tries to delete it again
[12:27] <tsdgeos> ok, gdb doesn't really say much
[12:27] <tsdgeos> let's see valgrind
[12:27] <tsdgeos> see you next year :D
[12:35] <tsdgeos> running that test in valgrind is not really a good idea
[12:36] <tsdgeos> Cimi: you say it also segfaults sometimes in another test?
[12:36] <Cimi> tsdgeos, I'll tell you later, running make -i
[12:38] <Cimi> http://paste.ubuntu.com/7079068/
[12:38] <Cimi> those fail here
[12:38] <tsdgeos> aren't we talking about crashing
[12:38] <tsdgeos> ?
[12:38] <Cimi> tsdgeos, one monent
[12:38] <Cimi> tsdgeos, grepping log file
[12:39] <tsdgeos> valgrind crashed ^_^
[12:39] <tsdgeos> valgrind: the 'impossible' happened:
[12:40] <tsdgeos> having another test that crashes maybe makes valgrind less unhappy
[12:54] <Cimi> tsdgeos, seems fineapart others
[12:54] <tsdgeos> testDash crashed for me one
[12:54] <Cimi> tsdgeos, running make -i qmluitests 2> log
[12:54] <tsdgeos> running valgrind on that now
[12:54] <Cimi> ah ok
[12:55] <tsdgeos> lunch
[13:18] <Saviq> MacSlow, doesn't seem good https://code.launchpad.net/~macslow/unity8/fix-object-name-of-notification-ap-test/+merge/210588/comments/496181
[13:18] <Saviq> MacSlow, failed on both otto and mako with the same fail
[13:18] <MacSlow> Saviq, :/
[13:19] <Saviq> didrocks, was autopilot updated again?
[13:20] <didrocks> Saviq: to fix the regression from yesterday, yeah
[13:20] <didrocks> (the 2 bugs that failed on unity8 + 3 on system settings)
[13:20] <didrocks> unicode error
[13:21] <Saviq> didrocks, right, but we still had the thing from last week where sd_incoming_call started failing reliably, do you know what's the status of that?
[13:22] <didrocks> Saviq: let me check, IIRC, the only other failures are the one I pointed + the crashes
[13:22] <didrocks> Saviq: it's passing: http://ci.ubuntu.com/smokeng/trusty/touch/mako/233:20140312:20140304/7104/unity8/882314/ ?
[13:23] <Saviq> didrocks, right, autopilot-qt wasn't updated, just autopilot
[13:23] <didrocks> Saviq: yeah, autopilot-qt is still reverted
[13:24] <didrocks> and normally, Mirv should have reverted it in trunk for 5.2 as it didn't reland with a fix
[13:24] <didrocks> (he has some branches with that)
[13:25] <Mirv> didrocks: aha.. I think that might explain something too, it's just a rebuild that's currently in the silo of autopilot-qt
[13:25] <didrocks> Saviq: seems he just proposed a no change rebuild
[13:25] <didrocks> https://code.launchpad.net/~timo-jyrinki/autopilot-qt/rebuild_against_qt521/+merge/209393
[13:25] <didrocks> yeah
[13:25] <didrocks> Mirv: you missed that revert I guess ^
[13:26] <Mirv> yes, I'm not sure at which point it was reverted and at which point it became clear those all need "revert branches" for 5.2
[13:26] <didrocks> Mirv: well, like for the other webapps ones ;)
[13:26] <MacSlow> Saviq, wait... of course it fails... it needs lp:~macslow/unity-notifications/dont-ignore-placeholder merged into lp:unity-notifications...  first... since I can't make that a prerequisite ... it's trying to break a chicken-egg-problem
[13:26] <Saviq> MacSlow, ok, didn't know that
[13:27] <Saviq> MacSlow, btw, fill https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8 in the description please
[13:27] <MacSlow> Saviq, I just put that in the MR-description... since I didn't know how to add it for real so the system could pick it up
[13:27] <Mirv> didrocks: yes, the 4 webapps are reverted (webbrowser-app, friends-app, online-accounts, signon-ui)
[13:27] <Mirv> but those were the only ones. rebuilding autopilot-qt now.
[13:27] <Saviq> MacSlow, "the system" doesn't know how to pick it up yet ;)
[13:27] <didrocks> Mirv: ok, from the current revert we didn't backport, it's the remaining one IIRC
[13:27] <Saviq> MacSlow, "the lander" needs to - i.e. me or Kevin
[13:28] <Saviq> or mzanetti, when he decides to take on the job ;)
[13:28] <MacSlow> Saviq, I was about to "warn" mzanetti about it :)
[13:28] <mzanetti> ?
[13:28] <MacSlow> now he should know :)
[13:28] <mzanetti> not sure...
[13:28] <MacSlow> mzanetti, one sec
[13:32] <MacSlow> tsdgeos, to get back to your earlier question about the MP-process for lp:unity-notifications ... it's meant to use the same as unity8.
[13:35] <MacSlow> mzanetti, I've updated the MP-description for https://code.launchpad.net/~macslow/unity8/snap-decisions-states/+merge/195394 to state the two required branches for snap-decisions-states to work
[13:35] <MacSlow> mzanetti, this should answer all branch-requirements
[13:56] <mhall119> Saviq: #ubuntu-uds-client-1 and https://plus.google.com/hangouts/_/hoaevent/AP36tYeI9UoFfAvvZ_cHjFMURV-YVmB6JQ4raHxIAng26bXr7k5AOA?authuser=1&hl=en
[13:56] <mhall119> for the Unity API docs hosting session
[13:56] <Saviq> mhall119, yup, joining
[13:56] <mhall119> mhr3: ^ if you're interested too, it's about using the new API website for Unity's internal API docs
[13:58] <tsdgeos> MacSlow: ok
[13:59] <tsdgeos> Cimi: run valgrind during lunch on a loop and didn't crash :/
[13:59] <Cimi> ahah
[13:59] <Cimi> tsdgeos, classic
[14:08] <mhr3> mhall119, sorry, in a different session
[14:46] <mzanetti> dandrader: thanks for the feedback
[14:46] <tsdgeos> anyone has experience with asan and gcc ?
[14:46] <tsdgeos> any clue how to make it be more verbose than this http://paste.ubuntu.com/7079615/
[14:47] <tsdgeos> specially line numbers
[14:47] <tsdgeos> and yes i'm using -g3 already
[14:47] <mzanetti> tsdgeos: is this about the testDashContent crash?
[14:47] <tsdgeos> yes
[14:48] <mzanetti> tsdgeos: I've never asan so I can't answer your question. But did you check if the Scopes stuff perhaps deletes some pointer on shutdown that it passed over to the QML site?
[14:48] <tsdgeos> why is qttest freeing stuff
[14:49] <mzanetti> looking at the stack trace and the test code it seems the most likely thing that we return a pointer with JsOwndership (or how its called) but still delete it ourselves
[14:49] <tsdgeos> may very well be
[14:53] <tsdgeos> a bit better http://paste.ubuntu.com/7079639/
[14:53] <tsdgeos> now i compile more stuff with asan
[14:54] <tsdgeos> and maybe...
[14:57] <dpm> mhr3, pstolowski, thostr_1, URL for the scopes hangout: https://plus.google.com/hangouts/_/hoaevent/AP36tYd2EugWeju3olaoKG0wp3Rs5QRg6D0zEOW8xoFwkhvVMd85nQ
[14:57] <pstolowski> dpm, thanks
[16:18] <mhr3> Saviq, was running ap tests on the scopes0.4 + new-scopes-cleanup silo, and got 3 failures -     raise NoSuchProcess(pid, None, 'no process found with pid %s' % pid)
[16:18] <mhr3>  and AssertionError: After 10.0 seconds test on QQuickListView.currentIndex failed: 0 != dbus.Int32(1, variant_level=1)
[16:19] <mhr3> Saviq, think i saw here mention of these, so i'll just ignore? :)
[16:19] <Saviq> the no process found are known, but the latter I haven't seen
[16:19] <Saviq> mhr3, more log?
[16:20] <mhr3> Saviq, http://pastebin.ubuntu.com/7080031/
[16:20] <mhr3> eh, ^^ FAIL: unity8.shell.tests.test_emulators.GenericScopeViewEmulatorTestCase.test_open_preview(Native Device)
[16:21] <Saviq> tsdgeos, looks familiar ↑?
[16:21] <Saviq> mhr3, we got PASSED on new-scopes-cleanup recently, so that's a failed test, is it failing reliably?
[16:21] <tsdgeos> kind of yes
[16:21] <mhr3> dunno, tried just once to run them all
[16:21] <mhr3> ah, good :)
[16:21] <tsdgeos> that happened before my last tweak
[16:21] <tsdgeos> but it should be fixed
[16:22] <tsdgeos> are you totally merged with new-scopes-cleanup?
[16:22] <mhr3> tsdgeos, when did you push it?
[16:22] <mhr3> this is from the morning
[16:22] <tsdgeos> today morning/yesternight
[16:22] <tsdgeos> don't remember :D
[16:23] <mhr3> tsdgeos, last rev 7 hours ago, so that one will be there
[16:23] <tsdgeos> then no clue
[16:25] <tsdgeos> mhr3: wait 5.2 or 5.0 ?
[16:25] <mhr3> tsdgeos, 5.0
[16:25] <tsdgeos> ok
[16:25] <tsdgeos> should work
[16:26] <mhr3> got it to pass now that i ran just the one test
[16:26] <mhr3> and one more and unity8 crashed
[16:33] <mhr3> tsdgeos, and failed again, with the same error
[16:34] <mhr3> so i'd say it's flaky :)
[16:34] <mhr3> fail, pass, crash
[16:34] <mhr3> can hardly do anything else than that :)
[16:35] <tsdgeos> mhr3: where are you running it?
[16:36] <mhr3> device
[16:36] <tsdgeos> ok
[16:37] <tsdgeos> Saviq: didn't the test randomly crash in the device for some reason with 5.0? ↑
[16:39] <Saviq> tsdgeos, first time I've seen a failure like that
[16:39] <tsdgeos> ok
[18:53] <mterry> kgunn, Saviq, mzanetti: so...  I think we're close enough to greeter split landing that we should get some eyeballs on the actual unity8 changes.  Would love it if anyone had time for https://code.launchpad.net/~mterry/unity8/split/+merge/210664
[18:54] <kgunn> mterry: awesome news!...let's def bring it up in stand up
[18:54] <kgunn> we'll find you a vict..i mean volunteer
[19:01] <greyback> mterry: 4303 line diff, whoa
[19:01] <mterry> Yeah...
[19:02] <mterry> tedg, hello!
[19:02] <mterry> tedg, I wondered if you wouldn't mind testing the split greeter experience with an eye towards indicators?
[19:02] <mterry> tedg, it's in a place where it could be tested well enough
[19:02]  * greyback eod
[19:02] <tedg> mterry, Oh! Exciting!
[19:03] <mterry> tedg, https://code.launchpad.net/~mterry/unity8/split/+merge/210664 gives gory details for all the branches you need
[19:03] <tedg> mterry, I'm still a bit underwater with stuff, but I can put that on my list.
[19:03] <mterry> tedg, for your purposes, you can skip the mir ones
[19:03] <mterry> tedg, OK
[19:04] <mterry> tedg, in particular, I predict you may want to do something similar to what telephony-service does to grab contact info for messages in indicator-messages
[19:06] <tedg> mterry, indicator-messages got deprioritized for greeter work :-/