[08:23] <Mirv> tsdgeos: could you run the make qmluitests as indicated at https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt with the 012 PPA and make sure there is no regression compared to 5.4.0?
[08:23] <tsdgeos> Mirv: sure
[08:24] <Mirv> tsdgeos: could you also run the unity8 AP on the device with the PPA? (remember to clean the QML cache) - I see some sort of hang, clock shown, but black background
[08:24] <Mirv> tsdgeos: hopefull not related to the deadlock patch I already included or anything
[08:25] <tsdgeos> i will try
[08:26] <Mirv> I don't see any problems with any other AP:s which ran overnight, so I need some sort of reconfirmation on unity8. it did also finish to the end of tests a couple of times, but seems a bit flaky.
[08:48] <tsdgeos> Saviq: so it seems the othre dash qml regression is similar to https://code.launchpad.net/~aacid/unity8/test_stubborn_flick i'll put it there too (or are you landing it already and is it a hassle?)
[08:49] <Saviq> tsdgeos, no, is fine, put it there
[08:49] <tsdgeos> k
[09:08] <Saviq> mzanetti, hey, could bug #1423573 be the launcher lag extreme?
[09:12] <tsdgeos> Saviq: ok,updated https://code.launchpad.net/~aacid/unity8/test_stubborn_flick/+merge/252407
[09:12] <Mirv> tsdgeos: I'm having at least this http://people.canonical.com/~tjyrinki/qt5/_usr_bin_unity8.32011.crash
[09:12] <Saviq> tsdgeos, k
[09:14] <tsdgeos> Mirv: looks mir-y
[09:14] <tsdgeos> Saviq: seen ↑↑ before?
[09:15] <Saviq> tsdgeos, nothing obvious without symbols
[09:16] <tsdgeos> Mirv: when do you get that
[09:16] <tsdgeos> ?
[09:17] <Mirv> tsdgeos: I filed bug #1431225 to report everyone's findings. before those latest patches to qtbase and qtdeclarative, I at least had a unity8 AP run with only 2 failed tests, now 15-25 (maybe when it hangs and then AP eventually times out)
[09:17] <Mirv> tsdgeos: running unity8 AP:s
[09:17] <Mirv> ie those Lock-dispatchLock-before-the-regular-lock.patch + Fix-crash-in-overdraw-and-change-visualizers.patch
[09:17] <Mirv> might be something else too
[09:17] <Saviq> Mirv, does it actually fail the test because of that?
[09:18] <tsdgeos> hope it's not the dbus one :D
[09:18] <Saviq> it might be a bad close
[09:18] <Mirv> Saviq: well now for example I've again the black background on the phone, I don't think the test can succeed since nothing happens
[09:19] <Mirv> tsdgeos: Saviq: Qt 5.4.1 silo would be ready to go (to QA testing) aside from this unity8 issue now, the PPA is fully ready and all other AP:s pass.
[09:20]  * Saviq flashes
[09:44] <tsdgeos> Mirv: Saviq: yeah i get the clock+black screen here a lot :(((
[09:44] <tsdgeos> i guess i've created a new deadlock fixing the other deadlock
[09:44] <tsdgeos> booo
[09:45] <tsdgeos> now if we could adb shell to the phone without unlocking the greeter ...
[09:45] <tsdgeos> that'd be a thing
[09:47] <Mirv> tsdgeos: Saviq: wait a minute..
[09:48] <Mirv> tsdgeos: Saviq: I just upgraded to today's vivid image without 5.4.1, and I now have the black screen / clock over there...
[09:48] <tsdgeos> that may very well be :d
[09:48] <tsdgeos> let me try the same
[09:48] <Saviq> Mirv, that is during AP tests?
[09:49] <Mirv> Saviq: this actually happened in normal startup
[09:49] <tsdgeos> yeah same here
[09:49] <tsdgeos> rebooted twice
[09:49] <tsdgeos> ended up with only clock + black background
[09:49] <Saviq> so that sounds like the dbus deadlock not fixed?
[09:49] <Mirv> tsdgeos: without 5.4.1?
[09:49] <tsdgeos> with
[09:49] <tsdgeos> now let me try without
[09:50] <Mirv> what I did run latest 5.4.1 tests with was yesterday's image + late apt-get dist-upgrade, so quite close to what today's image is
[09:51] <Saviq> "quite close" :D
[09:52] <Saviq> Mirv, so maybe what makes it break is the dist-upgrade? /me looks what's involved there
[09:52] <Mirv> Saviq: I mean, quite close if it's something in normal vivid archive changes that's causing the problem and not the 5.4.1 or the cherry-picked patches
[09:53]  * Saviq reboots 130 in a loop
[09:53] <Saviq> Mirv, that's mako btw?
[09:53] <Mirv> Saviq: I just said above that I upgraded to today's image (without 5.4.1 and without dist-upgrade) and got the black screen on the first boot. the image upgrade takes care of QML cache cleanup too so it's not that either.
[09:53] <Mirv> Saviq: yes
[09:54] <Saviq> Mirv, so yeah, lock on boot is something we were hoping tsdgeos's patch would fix... apparently not, then?
[09:54] <tsdgeos> seems not
[09:54] <tsdgeos> how does one even log into the device when it's locked on boot?
[09:55] <Mirv> adb shell works for me. with "black screen on first boot" I meant this clock/indicators visible so it's running pretty normally
[09:55] <Mirv> but black background similar to what I thought was 5.4.1 / cherry-pick patches specific problem
[09:56] <Saviq> tsdgeos, you can adb into mako just fine when it's locked
[09:56] <Saviq> tsdgeos, other than that, ssh
[09:56] <tsdgeos> Saviq: not mine
[09:56] <tsdgeos> it says "connection closed"
[09:56] <Saviq> interesting
[09:57] <tsdgeos> i need to enter the password
[09:57] <tsdgeos> in the greeter i mean
[09:58] <Saviq> yeah, that was planned for rtm/krillin, but not for mako I don't think
[10:01] <Saviq> Mirv, #130 doesn't lock up for me, did it only happen after flashing for you or any reboot?
[10:04] <tsdgeos> Saviq: i got the hunch it may be after cleaning the qml cache
[10:04] <tsdgeos> did you clear yours?
[10:04] <Saviq> that could make sense
[10:05] <Saviq> did not
[10:05] <tsdgeos> need it because otherwise your keyboard will crash like crazy
[10:05] <Saviq> tsdgeos, /me not on 5.4.1 yet
[10:05] <tsdgeos> ah
[10:05] <tsdgeos> ok
[10:05] <Saviq> tsdgeos, trying to reproduce without
[10:10] <Saviq> ok yeah, got it to lock up
[10:11] <Saviq> grabbing symbols
[10:11] <Saviq> but expect this to be the dbus lockup, really
[10:11] <Saviq> but at least we now got a way to reproduce it
[10:17] <tsdgeos> pstolowski: Saviq: https://code.launchpad.net/~aacid/unity-api/scopes-as-apps/+merge/252705
[10:17] <Saviq> tsdgeos, tx, will have a look soon
[10:18] <pstolowski> tsdgeos, Saviq thanks; btw I think thostr_ and michi still want to discuss the overall approach
[10:19] <Saviq> pstolowski, sure, I think it's happening on the doc, but please just drop a HO if you guys feel some face time is needed
[10:20] <Saviq> ugh what's with ddebs... ~70kB/s is meh :/
[10:27] <Mirv> Saviq: only once after image upgrade so far
[10:28] <Saviq> Mirv, delete ~/.cache/QML, you'll get it again
[10:28] <Saviq> and this is bug #1421009
[10:29] <tsdgeos> this is confusing
[10:30] <tsdgeos> the backtrace looks exactly like what my patch was supposed to fix :D
[10:30]  * tsdgeos looks at it more closely
[10:31] <thostr_> Saviq: will ping you later... need to get my thoughts more straight first
[10:32] <Mirv> Saviq: oh, right. well, at least that is then not a regression (in qt 5.4.1, that is)
[10:32] <Saviq> Mirv, yeah, but it was supposed to be fixed by tsdgeos's patch ;)
[10:33] <tsdgeos> http://paste.ubuntu.com/10584768/
[10:33] <tsdgeos> this is what i have
[10:34] <Saviq> tsdgeos, yeah
[10:34] <Saviq> tsdgeos, and that's with 5.4.1?
[10:34] <tsdgeos> yes
[10:34] <Saviq> so not fixeded :?
[10:34] <tsdgeos> seems not
[10:36] <Mirv> Saviq: right.. :)
[10:36] <tsdgeos> may want to try thiago's long dbus patchset then=
[10:36] <tsdgeos> ?
[10:38] <Saviq> would be good to know, yeah
[10:38] <Saviq> but it's in progress still, maybe we need to just say we failed to fix the unity8 boot bug with 5.4.1 landing
[10:40] <tsdgeos> or that yeah
[10:40] <Cimi> Saviq, tsdgeos do you remember a scope for trunk (not krillin) that has pinch to zoom images?
[10:40] <Saviq> Mirv, what would be easier, letting silo 12 through and bugfixing just qtbase later, or adding another 5-6 patches to 12 still?
[10:41] <Saviq> Cimi, apps, no? ;)
[10:42] <Saviq> ah no, no pinch there
[10:43] <Saviq> Cimi, dunno there is one, actually
[10:43] <Cimi> Saviq, bug fixed!
[10:43] <Cimi> :D
[10:45] <Saviq> Cimi, PM
[10:47] <Mirv> Saviq: 1. getting agreement that unity8 doesn't regress with current 012 (AP, qmluitests..), 2. put to QA signoff queue, 3. prepare potential next patches in another silo, and if QA hasn't started testing by the time the new silo is validated fully, copy the new packages to 012
[10:47] <Saviq> Mirv, ok, works, /me validates then
[10:48] <tsdgeos> nice thing is that now we can reproduce the thing by erasing the cache
[10:48] <tsdgeos> which is good
[10:48] <Saviq> yeah
[10:48] <tsdgeos> E_TOO_MANY_THINGS
[10:49] <Saviq> stupid Uber
[10:49] <Saviq> for whatever reason they decided that I'm in CZ and I'm getting newsletters in CZ... because yes, we're bordering with CZ, so we know the language of course, right?
[10:50] <Mirv> that way the new experiments won't restart testing of 012
[10:51] <Mirv> Saviq: thanks, let me know the results later
[10:51] <Mirv> I'll start some app testing
[11:14] <tsdgeos> Mirv: qmluitests passed fine here (well not fine but with the same errors we have in trunk)
[11:21] <Mirv> tsdgeos: ok, good
[11:38] <Saviq> Mirv, tsdgeos, I'm worried silo 12 increases the deadlock likelihood, I never had it during AP tests before
[11:39] <tsdgeos> Saviq: it may very well be that i fixed a case and made some other more likely
[11:39] <tsdgeos> :/
[11:39] <tsdgeos> Saviq: we may as well go without that dbus patch
[11:39] <tsdgeos> and i can ask upstream to revert ir
[11:39] <tsdgeos> it
[11:40] <tsdgeos> at this stage seems like the best route
[11:40] <Saviq> tsdgeos, yeah, it's locking quite badly
[11:40] <tsdgeos> Mirv: can you revert the dbus patch and rebuild
[11:40] <Mirv> Saviq: tsdgeos: is it reproducable on desktop?
[11:41] <tsdgeos> just to make sure it's cause that patch and not something else
[11:41] <Mirv> Saviq: tsdgeos: I was being proactive and started rebuilds of both reverted qtbase and qtdeclarative at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+packages (against 012), but armhf qtbase is still building
[11:41] <Mirv> since it takes around 4.5h for the armhf to build
[11:41] <tsdgeos> the qtdeclarative one should be fine tbh i don't see that one causing any trouble
[11:42] <Mirv> yeah, the idea was that either or both can be copied to 012 when ready
[11:42] <tsdgeos> right
[11:42] <Mirv> armhf will be ready in around 2.5h from now
[11:47] <tsdgeos> good stuff
[11:54] <Cimi> tsdgeos, Saviq do you have a krillin rtm>?
[11:54] <Saviq> Cimi, I do
[11:55] <tsdgeos> Cimi: i can flash it yes
[11:55] <Cimi> mine has now dead battery
[11:55] <Cimi> Saviq, ok, can you try in the my photos scope, zoom in and scroll the photo?
[11:55] <Cimi> in trunk you cannot scroll the photo anymore, you can just zoom in
[11:56] <Cimi> I believe is related to transition to 5.4
[11:56] <Cimi> https://code.launchpad.net/~aacid/unity8/qmluitests54/+merge/250021
[11:56] <Cimi> pincharea on top and probably stealing events to flickable
[11:56] <Cimi> but not sure yet
[11:56] <Cimi> krillin is charging...
[12:03] <Cimi> Saviq, ?
[12:10] <tsdgeos> Cimi: yes it does zoom and pan fine
[12:10] <tsdgeos> on rtm
[12:10] <tsdgeos> let me update to the latest latest rtm to try again
[12:10] <Cimi> tsdgeos, ok enough
[12:10] <Cimi> tsdgeos, so we have a regression
[12:11] <Cimi> tsdgeos, probably caused by your branch, but your branch fixed another bug
[12:11] <Cimi> I am looking
[12:12] <tsdgeos> Cimi: can you report a bug so we don't forget?
[12:12] <Saviq> Cimi, sry, yeah, can pan
[12:12] <Cimi> tsdgeos, I am looking right now
[12:12] <tsdgeos> ok
[12:19] <dandrader> mzanetti, hey, about that "double tap to switch focus" thing, should I report a bug?
[12:21] <mzanetti> dandrader, yeah, please
[12:25] <dandrader> mzanetti, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1431325
[12:25] <mzanetti> dandrader, thanks
[12:25] <dandrader> mzanetti, It's an interesting bug, I would actually like to have a look at it later, in case you're busy with other stuff
[12:26] <mzanetti> dandrader, I kinda am. if you're free, I'd be happy to get a helping hand with this one.
[12:26] <dandrader> mzanetti, ok
[12:27] <mzanetti> dandrader, btw, the mouseemulationcheckbox for tests is awesome. writing mouse-related launcher tests now :)
[12:28] <tsdgeos> Mirv: need to find someone that can top approve https://code.launchpad.net/~timo-jyrinki/ubuntu-push-qml/drop_private_header_bd/+merge/251691 i guess (and land))
[12:29] <Mirv> tsdgeos: oh right. ralsina ^
[12:29] <Mirv> (looking at the previous top-approves there)
[12:30] <ralsina> tsdgeos: sure, I'll top-approve
[12:31] <Mirv> tsdgeos: I went throuh our private header usage prompted by the fact that we had been marking a couple of symbols as private/public wrongly... everything basically cleared out but I found a couple of errors like that
[12:32] <tsdgeos> :)
[12:32] <tsdgeos> food!
[12:32] <Mirv> kwin has qtdeclarative/qtbase-abi-5-4-0 dependency currently even though it doesn't use private symbols, since it uses some symbols that were made public by upstream recently. fixed in the 5.4.1 PPA.
[12:32] <dandrader> mzanetti, glad you liked it. But even more awesome is having a touchscreen laptop, as you can even harass tests with multiple, simultaneous, touches :)
[12:33] <mzanetti> do you have a touchscreen laptop now?
[12:33] <dandrader> mzanetti, yeah
[12:33] <mzanetti> fancy
[12:33] <Saviq> /food
[12:36] <Cimi> tsdgeos, which bugs where you trying to fix with that branch?
[12:36] <Cimi> "* Make PinchArea not be a child of Flickable, otherwise when zooming out the Flickable was stealing the events from the PinchArea"
[12:42] <ralsina> tsdgeos: added it to silo 16, building now, hopefully will land soon. Thanks for the fix!
[12:44] <Saviq> faenil, huh, libsystemsettings-dev is a Build-Dep of unity8... and the build script builds a package depending on all those... can you show `apt-cache show unity8-build-deps` please?
[12:44] <faenil> Saviq: I've already done apt-get build-dep unity8 :/
[12:44] <faenil> which installed 33 new packages
[12:45] <Saviq> faenil, ok, so the build script failed to install the unity8-build-deps one
[12:46]  * Saviq tries it out in chroot
[12:46] <Saviq> faenil, thanks for the report
[12:46] <faenil> Saviq: no problem :)
[12:46] <faenil> I hope you'll find where the issue comes from
[12:46] <faenil> if I can give other info let me know, but I guess it's too late now ;/
[13:25] <Saviq> faenil, oh, one thing, how did you build after ./build-sh -s ?
[13:33] <mzanetti> Saviq, with ./build.sh
[13:33] <mzanetti> Saviq, I instructed him (and told him to report the bug)
[13:35] <mzanetti> dandrader, saw your branch. what's the difference beween TouchGate and InputWatcher? couldn't that be the same?
[13:36] <dandrader> mzanetti, they are totally different
[13:36] <dandrader> mzanetti, InputWatcher just monitors input evets received by its target
[13:37] <dandrader> mzanetti, TouchGate is a item that buffers the touch events it receives until it gets ownership over them, at which point it forward them down to it target
[13:37] <mzanetti> right ok. so not merging them, but seems InputWatcher is just a normal mousearea somehow
[13:38] <tsdgeos> Mirv: /back
[13:38] <dandrader> mzanetti, no, InputWatcher is a QObject
[13:38] <tsdgeos> what, that back was not for Mirv :D
[13:38] <tsdgeos> Cimi: unittest
[13:39] <mzanetti> dandrader, I guess I didn't understand the problem properly yet
[13:39] <dandrader> mzanetti, and TouchGate actually shouldn't have a pressed() signal, added it as a easy way to solve that issue. Should probably remove that signal now
[13:39] <tsdgeos> Cimi: as the comit log says, no?
[13:39] <dandrader> mzanetti, the problem is that MirSurfaceItem doesn't tell us whether it got pressed or not, like a MouseArea
[13:39] <mzanetti> ah. suddenly all makes more sense :D
[13:40] <dandrader> mzanetti, so in order for us to figure it out, we have to watch the events it gets ourselves
[13:40] <dandrader> mzanetti, I didn't want to add a pressed property to MirSurfaceItem as it really doesn't fit in MirSurfaceItem's purpose
[13:40] <dandrader> mzanetti, hence the separate component for that
[13:41] <mzanetti> dandrader, I agree, yes
[13:41] <greyback> +1
[13:52] <Saviq> tsdgeos, when installing silo 12, did bluetooth configure take forever for you too?
[13:52] <tsdgeos> Saviq: yes, but it's not silo 12, no? it's dis-tupgrade
[13:52] <tsdgeos> i mean it's a different package
[13:53] <tsdgeos> Saviq: i rebooted the phone
[13:53] <tsdgeos> and just finished the disr-upgrade after
[13:53] <Saviq> tsdgeos, hmm right yes
[13:53]  * Saviq was hoping the funky apt update would not upgrade from distro
[14:08] <Mirv> tsdgeos: Saviq: ok please resume testing with http://pastebin.ubuntu.com/10585616/ ie updating qtbase (only) from 001 in addition to using 012. if that can be validated, I'll copy it over to 012 and then the next experiments can be done in 001.
[14:08] <Saviq> Mirv, yup, almost there
[14:15] <Encrypt> Hello everybody! o/
[14:15] <Encrypt> Hi tedg o/
[14:16] <Encrypt> I have a question for (all of) you
[14:16] <Encrypt> I have been integrating Unity to µTox (a Tox client), however I have a problem...
[14:17] <Encrypt> The GMainLoop is running in a given thread, but once the user clicks on a button with a gtk-related call, µTox immediately core dumps
[14:19] <Encrypt> Do you have any idea about the problem?
[14:19] <Encrypt> Is there any incompatibility between the GMainLoop & gtk events?
[14:21] <Encrypt> Here is my code: https://github.com/notsecure/uTox/blob/master/xlib/mmenu.c#L25
[14:23] <Encrypt> And here is a function which is called -- for example -- when the users clicks on the avatar
[14:23] <Encrypt> https://github.com/notsecure/uTox/blob/0ffe91321040b4f9253761e91c7455f927962fb6/xlib/gtk.c#L191
[14:26] <greyback> Encrypt: I'd suggest generating a good backtrace of the crash, so you can see exactly where the fail happens
[14:27] <Encrypt> greyback, Ok, thanks
[14:27] <Encrypt> I'll do that right now
[14:29] <Encrypt> greyback, Here it is
[14:29] <Encrypt> http://pastebin.com/RrfVy2sF
[14:30] <Encrypt> I tried using a different context
[14:30] <Encrypt> But the Messaging Menu doesn't like that
[14:30] <Encrypt> It doesn't even registers in a different context
[14:30] <Encrypt> register*
[14:35] <greyback> Encrypt: that's not a useful backtrace, you need to get symbols (see it complains "No symbol table available")
[14:35] <Encrypt> Ok
[14:38] <greyback> Encrypt: dpkg -S /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
[14:38] <greyback> libgtk2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
[14:38] <greyback>  ~/dev/projects/unity8/unity8 ⮀ apt-cache search libgtk2 | grep dbg
[14:38] <greyback> libgtk2.0-0-dbg - GTK+ libraries and debugging symbols
[14:38] <greyback> you should install that package, and use similar technique to find and install other debug symbol packages
[14:38] <Encrypt> Ok! :)
[14:39] <greyback> then you'l get a more informative backtrace. Ideally you're looking for the line of code where the fail occured, and then work backwards to understand why that happened
[14:40] <Saviq> Mirv, tsdgeos, silo 1 it looks better indeed, got a lock on ~first boot after upgrade, but AP tests continue happily
[14:41] <Encrypt> greyback, That's really more informative! :D
[14:41] <tsdgeos> Saviq: :) :/
[14:42] <Saviq> Encrypt, also see https://wiki.ubuntu.com/DebuggingProgramCrash
[14:43] <Encrypt> thanls :)
[14:43] <Encrypt> thanks*
[14:43] <Mirv> Saviq: yeah I also got full pass on AP:s. I'll already copy it to 012 since the differnce is clear.
[14:45] <Mirv> the qtbase + qtbase-gles, that is
[14:46] <Saviq> Cimi, care to comment your findings on bug #1430815 please
[15:01] <Cimi> Saviq, I was waiting for john lea to pop in online, since he said fix committed
[15:03] <Saviq> Cimi, please comment your current findings anyway
[15:03] <Cimi> Saviq, ok
[15:05] <Mirv> Saviq: give me some sort of nod/ack when you finish testing unity8 w/ 5.4.1 so that I know. also, 001 can now be removed as it's published in 012.
[15:05] <Saviq> Mirv, *nod*
[15:05] <Saviq> Mirv, is fine
[15:05] <Mirv> Saviq: !! :)
[15:06] <Mirv> great. I'll leave some more manual testing for myself to tomorrow and wait to hear back from emulator and then it should be ready to be thrown over to QA!
[15:06] <Saviq> tsdgeos, re: tryTouchFlick... shouldn't the function just do everything based on content{Y,Height}?
[15:06] <Saviq> tsdgeos, since it's relying on the fact that it's a Flickable already...
[15:08] <tsdgeos> Saviq: but it's not contentY/Height that make sense here
[15:08] <tsdgeos> Saviq: you mean so that we don't have to pass x, y, toX, toY ?
[15:08] <Saviq> tsdgeos, yes
[15:08] <tsdgeos> Saviq: those x,y are not based on content but on real size of the item
[15:09] <tsdgeos> i.e. they are the phisical positions
[15:09] <tsdgeos> you press and release on
[15:09] <tsdgeos> we could hardcode them to middle of the item and some gus from top/bottom
[15:10] <Saviq> tsdgeos, the purpose of the function is to flick to end, sounds good enough?
[15:10] <tsdgeos> i guess
[15:10] <tsdgeos> didn't want to close doors
[15:11] <tsdgeos> but if you prefer let me change it
[15:11] <Cimi> tsdgeos, but apart the unit test, was there a wrong behaviour on the phone?
[15:11] <Saviq> tsdgeos, then make x,y,toX,toY optional
[15:11] <Cimi> tsdgeos, because putting the area outside breaks the flickable
[15:11] <Saviq> tsdgeos, you won't close doors, and it'll still work
[15:11] <tsdgeos> Cimi: well there was no test for that :)
[15:11] <Cimi> :D
[15:12] <Cimi> tsdgeos, basically wondering if there is a better fix for the unit test itself
[15:12] <tsdgeos> you can remove it, suddenly it will pass
[15:12] <tsdgeos> though what it is testing may break
[15:12] <tsdgeos> :D
[15:12] <Cimi> tsdgeos, but was the interaction broken?
[15:12] <Cimi> tsdgeos, or just the unit test?
[15:12] <tsdgeos> Cimi: well if the test fails
[15:12] <tsdgeos> why would the interaction not broken?
[15:13] <Saviq> the test could be broken ;)
[15:13] <tsdgeos> honestly i don't remember, but if i changed the code and not the test, i would assume that yes it was broken
[15:15] <mzanetti> Mirv, I just installed silo12 and the phone doesn't boot any more. is that known already?
[15:15] <Mirv> mzanetti: something else is probably wrong, which device?
[15:15] <mzanetti> freshly flashed mako
[15:15] <Mirv> mzanetti: did you follow https://wiki.ubuntu.com/Touch/QtTesting ?
[15:15] <Saviq> mzanetti, citrain doesn't do for silo 12
[15:15] <mzanetti> ah
[15:16] <mzanetti> Saviq, ^^ it's your fault :D
[15:16] <mzanetti> j/k
[15:16] <Mirv> mzanetti: thanks for joining the testing crowd, though, anyway!
[15:16] <Saviq> mzanetti, install libdouble-conversion1 before citrain
[15:16] <mzanetti> I guess I can't recover without reflashing
[15:17] <Saviq> mzanetti, bug #1378245
[15:17] <Mirv> oh, citrain fails completely because of it doesn't allow installation of new packages, right..
[15:17] <Saviq> mzanetti, in theory yes, install ubuntu-touch (after an apt update)
[15:17] <Saviq> mzanetti, but safer to flash, install ↑↑ and citrain
[15:17] <mzanetti> it's stuck in a reboot loop it seems
[15:17] <mzanetti> ok. reflashing
[15:19] <Mirv> mzanetti: yeah when apt fails it fails in a big way, you've likely had several core packages removed
[15:20] <tsdgeos> Saviq: so i should propose the revert of the patch upstream, right?
[15:20] <Saviq> tsdgeos, it kinda clearly made it worse for us, yes
[15:23] <tsdgeos> ok
[16:11] <Encrypt> greyback, I think I found my error
[16:11] <Encrypt> In the Messagign Menu integration, I'm using a GMainLoop
[16:12] <Encrypt> And gtk also uses a main loop, with gtk_iter (or something like that)
[16:12] <Encrypt> There should only be one main loop and not two
[16:32] <tsdgeos> Saviq: updated the stubborn flick branch
[16:51] <Saviq> tsdgeos, tx