[03:39] <robru> Trevinho, around? do these errors mean anything to you? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1252937
[03:40] <robru> Saviq, ^^
[08:08] <tsdgeos> Mirv: sorry i should have attended that one, lost track of stuff
[08:08] <tsdgeos> ah, i see saviq joined later
[08:34] <tsdgeos> Mirv: can you trigger a rebuild of https://code.launchpad.net/~canonical-qt5-edgers/+recipe/unity-mir-daily-qt52 ? i don't seem to be able to choose the "[testuse] Qt5 Beta2" archive from the list
[08:34] <tsdgeos> Saviq: maybe you can? ↑↑
[08:35] <Mirv> tsdgeos: clicked the button
[08:35] <tsdgeos> tx
[08:35] <Mirv> and yeah savi_q could have done that too
[08:37] <tsdgeos> Saviq: we've been 40 revisions without a release, shouldn't we get one?
[08:44] <tsdgeos> Mirv: can you actually trigger the unity8 one? i got a patch in this morning that should get rid of the armhf failure too
[08:45] <tsdgeos> Mirv: https://launchpadlibrarian.net/156994226/buildlog.txt.gz ?¿
[08:45] <Mirv> tsdgeos: ok.
[08:46] <Mirv> tsdgeos: Saviq: it was too tempting btw, I was running with Qt 5.2 already, I can post a video soon :) I merged some branches, disabled tests (in case they'd fail) and recompiled unity8 + qtubuntu + unity-mir on the device
[08:47] <tsdgeos> Mirv: so you're seeing the ugly regression in the ubuntushapes?
[08:57] <tsdgeos> damnit my nexus4 decided to commit suicide again
[08:57]  * tsdgeos searches or the original charger
[09:07] <mzanetti> tsdgeos: that's what you get for filling your home with Z10 chargers :P
[09:07] <tsdgeos> it's not my fault if BB loves giving me free stuff
[09:07] <mzanetti> lol
[09:07] <tsdgeos> at this point i've gotten 3 Z10 and a Playbook :D
[09:08] <mzanetti> insane
[09:08] <mzanetti> I wonder why they take names when giving away their free stuff. certainly not to check for duplicates
[09:12] <tsdgeos> mzanetti: i think they only duplicate by e-mail address
[09:13] <tsdgeos> because you know there's so many "Albert Astals Cid" in the world you can't know if tsdgeos@yahoo.es aacid@kde.org and albert.astals@canonical.com are the same guy or not :D
[09:13] <mzanetti> ah. so you are being sneaky
[09:13] <mzanetti> :)
[09:13] <tsdgeos> i am not being sneaky
[09:13] <tsdgeos> i am just contributing to Qt a lot :-P
[09:14] <mzanetti> ok. sure...
[09:14] <tsdgeos> i got red light in the nexus4 btw
[09:14] <tsdgeos> needed to do the magic three finger salture though
[09:14] <Mirv> tsdgeos: https://plus.google.com/107379654278574464995/posts/NeUt19z1V3p
[09:15] <tsdgeos> lol
[09:15] <tsdgeos> empty scopes?¿
[09:15] <tsdgeos> that's bad :D
[09:18] <Mirv> tsdgeos: yep, not really sure why.. I get a black screen relatively soon too. but that's for this afternoon's session about where we're at with testing :)
[09:18] <Mirv> "it starts"
[09:32] <nic-doffay> tsdgeos, what do you make of this test? https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
[09:32] <tsdgeos> nic-doffay: i retriggered ci
[09:33] <nic-doffay> tsdgeos, I didn't see anything related.
[09:33] <tsdgeos> the ci machines are sometimes stupidly username blocked
[09:33] <tsdgeos> and thus everything fails to run
[09:33] <tsdgeos> it's something the ci people are working on
[09:33] <tsdgeos> basically if you see all 28 autopilot tests fail at once
[09:33] <tsdgeos> it's probably that
[09:35] <om26er> mzanetti, which package do you suggest I should report bug for ? re: running qmltestrunner on Mir
[09:36] <tsdgeos> erm
[09:37] <tsdgeos> /var/local/autopilot/setup.log: The following packages have unmet dependencies:
[09:37] <tsdgeos> /var/local/autopilot/setup.log:  unity8 : Depends: libunity-mir1 but it is not going to be installed
[09:37] <tsdgeos> what ?¿
[09:39] <tsdgeos> nic-doffay: seems the CI for your MR will fail again because of ↑ :_/
[09:40] <mzanetti> om26er: unity-mir
[09:41] <tsdgeos> mzanetti: any idea what's causing the above problem with deps?¿
[09:41] <mzanetti> isnt the upside down question mark supposed to go at the beginning of the sentece?
[09:41] <om26er> I think some build failed
[09:41] <mzanetti> no. I don't know what that is
[09:42] <om26er> build of the dependency I mean
[09:43] <tsdgeos> mzanetti: it is, but it's easier to add it at the end :P
[09:43] <mzanetti> tsdgeos: well, libunity-mir probably depends on something that doesn't exist (yet/any more)
[09:43] <tsdgeos> since it's confortably located on the keyboard besides the other
[09:43] <mzanetti> tsdgeos: but that defeats it's purpose. I always liked the fact that you know it is a question before you start reading
[09:43] <tsdgeos> trueth
[09:53] <nic-doffay> tsdgeos, err
[09:53] <tsdgeos> yes?
[10:02] <nic-doffay> tsdgeos, just re the setup.log
[10:03] <tsdgeos> nic-doffay: ?¿
[10:03]  * tsdgeos is lost
[10:04] <mzanetti> MacSlow: why the "skipBackground" in the fullscreen lockscreen?
[10:07] <MacSlow> mzanetti, that's to avoiding the black/opaque rect drawn by the PinPad...
[10:08] <mzanetti> MacSlow: well, there should be the background image from the shell
[10:08] <mzanetti> MacSlow: if it's just black that's an issue in the Lockscreen I'd say
[10:09] <MacSlow> mzanetti, there's still the surrounding element which has the notifications bg-color and setting the shell-background would make it look very ugly with the notification-border
[10:10] <mzanetti> MacSlow: hmm...why is that? I thought the lockscreen content is fullscreen
[10:11] <MacSlow> mzanetti, there's still the padding/margins from the parent-element, which fill space up to the edges
[10:12] <mzanetti> MacSlow: hmm... any chance to get around that?
[10:12] <MacSlow> mzanetti, also it would look a bit weird, if the pinpad would flush up right to the screen-edges
[10:12] <MacSlow> mzanetti, I tried and didn't get any working results
[10:16] <MacSlow> mzanetti, besides... I was a bit surprised, that the background (other than what the parent is) could be forced onto the pinpad
[10:17] <mzanetti> MacSlow: not sure I understand
[10:18] <MacSlow> mzanetti, I didn't expect an opaque background color (with the option to set a custom image) was the default for it.
[10:19] <MacSlow> mzanetti, I thought it would just be a transparent background... like e.g. the OptionSelector has
[10:20] <mzanetti> MacSlow: well, in the end it should be, but blur the background. as we are not able to properly do that yet, we went for putting the background image into it
[10:21] <mzanetti> MacSlow: in any case, the notifications border needs to go away
[10:21] <dednick> Cimi: can you re-review https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965 when you get a minute?
[10:21] <Cimi> dednick, yup
[10:21] <dednick> Cimi: thanks
[10:22] <MacSlow> mzanetti, I can try again... but don't know if I get to a acceptable solution this time
[10:22] <mzanetti> MacSlow: I can help you
[10:23] <MacSlow> mzanetti, I'll stick to the snap-decision states until lunch... after that I'll address the border
[10:24] <mhr3> sil2100, when can we except the new unity-scopes-shell to land in distro?
[10:25] <mhr3> sil2100, right now it's pretty safe to land it, cause it doesn't include deps on the new stuff yet
[10:25] <mhr3> cc dednick ^
[10:26] <dednick> mhr3, sil2100: I'm more interested in getting ubuntu-settings-components landed! :)
[10:26] <sil2100> dednick: mhr3: one moment, let me check something
[10:28] <sil2100> dednick: ok, after I land one of the fixes that seb128 pointed out yesterday, we can enable and release the ubuntu-settings-components for sure
[10:28] <sil2100> mhr3: unity-scopes-shell I think is ok as well, as seb128 reviewed my packaging changes and didn't note any problems, so I guess we can do the same here
[10:28] <dednick> sil2100: fixes for?
[10:28] <sil2100> dednick: packaging, minor things
[10:29] <dednick> sil2100: ah, ok
[10:29] <seb128> sil2100, unity-scopes-shell ... I reviewed your packaging changes, not the package for NEW
[10:29] <seb128> sil2100, not sure if that's what you are talking about there?
[10:30] <sil2100> seb128: ah, right, I thought you also did the preNEW review during that time as well ;) I don't want to bother you too much though, so maybe I can ask didrocks to perform the preNEW review or something
[10:30] <sil2100> Since you're like doing all the review work since yesterday for me ;p
[10:30] <seb128> sil2100, let me do the preNEW, didrocks is fighting with his trusty to get it back to "working"
[10:30] <Saviq> jeez what's with jenkins these days :/
[10:31] <sil2100> seb128: thanks again!
[10:33] <tsdgeos> Saviq: it's broooooooooken
[10:33] <seb128> sil2100, mhr3: you guys are joking right?
[10:33] <tsdgeos> Saviq: seems to have some kind of broken dependency packages
[10:33] <Saviq> tsdgeos, where?
[10:33] <Saviq> om26er, yeah, unlock_screen was looking fine, just needed to test it still
[10:33] <seb128> sil2100, mhr3:
[10:33] <seb128> $ licensecheck * -r | grep " GPL (v3" | wc -l
[10:33] <seb128> 74
[10:33] <seb128> $ grep License debian/copyright
[10:33] <seb128> License: LGPL-3
[10:34] <om26er> Saviq, ok. thanks
[10:34] <sil2100> seb128: ouch
[10:34] <sil2100> Wait...
[10:34] <tsdgeos> Saviq: this is not jenkins but it's a similar error https://launchpadlibrarian.net/156994226/buildlog.txt.gz
[10:34] <tsdgeos> Saviq: let me look up one in jenkisn
[10:35] <seb128> sil2100, if the source should be GPL you need to fix the copyright and ./data/unity-plugin-scopes.pc.in: LGPL (v3)
[10:35] <sil2100> seb128: ok, right, I think this is something that I obviously missed during the review
[10:35] <sil2100> :q
[10:35] <mhr3> sil2100, fwiw it should be gpl, no need for lgpl there
[10:36] <tsdgeos> Saviq: see http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/810/console
[10:36] <om26er> mzanetti, is qmltestrunner responsible for running both unit tests and integration tests ?
[10:36] <tsdgeos> /var/local/autopilot/setup.log: The following packages have unmet dependencies:
[10:36] <tsdgeos> /var/local/autopilot/setup.log:  unity8 : Depends: libunity-mir1 but it is not going to be installed
[10:36] <sil2100> seb128, mhr3: fixing those 2 issues
[10:36] <mhr3> ty
[10:37] <Saviq> tsdgeos, that seems to have started happening very recently
[10:37] <mzanetti> om26er: not really... we use autopilot for integration tests
[10:37] <Saviq> tsdgeos, like 4hrs ago we had a successful desktop run (touch failed due to device failing)
[10:37] <om26er> mzanetti, sorry, I was referring to the integration tests of QtMultimedia, they test if the sound is really working for example
[10:38] <mzanetti> om26er: still talking about those .qtt files?
[10:38] <om26er> mzanetti, no
[10:38] <tsdgeos> Saviq: yeah :-/
[10:38] <om26er> mzanetti, they are of the format tst_name
[10:38] <mzanetti> om26er: no .qml?
[10:39] <mzanetti> om26er: in that case they're binaries. just run them with ./
[10:39] <om26er> mzanetti, no, rather the compiled cpp binaries
[10:39] <om26er> mzanetti, right. I just wanted to know which is the tool that runs them ?
[10:39] <mzanetti> none. the have their own main()
[10:40] <mzanetti> (usually generated through the QT_TEST_MAIN macro)
[10:40] <mzanetti> om26er: ^
[10:40] <tsdgeos> mzanetti: MacSlow: what's missing for top approval in https://code.launchpad.net/~mzanetti/unity8/generic-lockscreen/+merge/191951 ?
[10:40] <mzanetti> tsdgeos: jenkins probably :P
[10:40] <om26er> mzanetti, right. so those also don't work under Mir
[10:40] <mzanetti> tsdgeos: I think it's ready to go
[10:41] <mzanetti> om26er: why not?
[10:41] <MacSlow> tsdgeos, mzanetti: nothing... my bad... top-approved
[10:41] <mzanetti> just pass --desktop_file_hint...
[10:41] <sil2100> mhr3, seb128: https://code.launchpad.net/~sil2100/unity-scopes-shell/packaging_review/+merge/195936
[10:41] <mzanetti> om26er: also, most likely those tests don't even paint a UI. so you wouldn't even need that
[10:41] <om26er> mzanetti, not really sure. I get:
[10:41] <om26er> QUbuntu: Could not create application instance
[10:41] <om26er> Aborted (core dumped)
[10:42] <mzanetti> om26er: yeah. just add --desktop_file_hint=/usr/share/applications/some-random-file.desktop
[10:42] <mhr3> seb128, +1 from me, pls top-approve if you're ok with that
[10:42] <om26er> mzanetti, we want to run those tests to make sure that all the QtMultimedia apis are working fine with our backend implementation on the phone
[10:42] <tsdgeos> om26er: that's on the phone or on the desktop?
[10:42] <Saviq> tsdgeos, the launchpad failure is different
[10:42] <om26er> tsdgeos, phone
[10:42] <mzanetti> tsdgeos: on the phone, with mir
[10:42] <tsdgeos> ok
[10:43] <Saviq> tsdgeos, the launchpad failure builds in the ppa, from trunks
[10:43] <seb128> sil2100, mhr3: ok, approved, thanks
[10:43] <tsdgeos> Saviq: ok, still both failed :-/
[10:43] <mzanetti> om26er: did you try running them with the parameter?
[10:43] <Saviq> tsdgeos, and because mir isn't built in that ppa, unity-mir fails due to http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/145
[10:44] <seb128> sil2100, mhr3: the naming is a bit weird otherwise, especially that the description states "Library to integrate"...
[10:44] <om26er> mzanetti, yeah. I get this http://paste.ubuntu.com/6447502/
[10:45] <mzanetti> oh crap
[10:45] <mhr3> seb128, well... yea, should be "plugin"
[10:45] <mzanetti> Saviq: ^^
[10:46] <Saviq> mzanetti, om26er yeah, that happens sometimes, at which point you need to use upstart-app-launch directly
[10:46] <tsdgeos> Saviq: i see, so how do we fix that?
[10:46] <mzanetti> Saviq: but that requires a valid .desktop file, or?
[10:46] <mhr3> sil2100, mind fixing that in your branch while it's not merged yet?
[10:47] <Saviq> mzanetti, yes
[10:47] <Saviq> mzanetti, it might be that Exec=%s would work
[10:47] <sil2100> mhr3: sure, I bumped it back to unapproved and fixing
[10:47] <mzanetti> Saviq: but we can't have valid .desktop files for every test
[10:47] <mzanetti> ah ok. worth a try
[10:47] <mhr3> sil2100, thx
[10:47] <sil2100> Plugin to integrate scopes with the Unity shell <- is ok?
[10:47] <mhr3> yep
[10:47] <Saviq> mzanetti, then you'd go upstart-app-launch foo $PWD/tst_foo
[10:47]  * mzanetti tries
[10:48] <tsdgeos> Cimi: how's the basedashrenderer thing going?
[10:48] <mzanetti> Saviq: the .desktop file needs to be located in /usr/share/applications?
[10:48] <Saviq> mzanetti, or ~/.local/share/applications
[10:48] <Cimi> tsdgeos, I have a bug
[10:49] <om26er> mzanetti, btw seems some unit tests are running fine without any arguments(but just executing the binary) others, don't
[10:49] <mzanetti> Cimi: get a bird :P
[10:49] <mhr3> sil2100, ok to re-approve?
[10:49] <tsdgeos> Cimi: can i help?
[10:49] <Cimi> tsdgeos, you can try if you want
[10:49] <Cimi> let me push
[10:49] <mzanetti> om26er: yeah... depends on whether it tries to paint something on the screen or if its just a command line based test
[10:50] <sil2100> mhr3: actually I just noticed that lp-propose proposed the wrong branch... so let me propose a different merge and auto-approve
[10:50] <Saviq> tsdgeos, the PPA we don't fix - we just wait for mir 0.1.1 to be released (they must've forced the unity-mir dependency through)
[10:50] <mhr3> sil2100, fwiw the diff looks fine
[10:50] <om26er> mzanetti, none of those tests tries to paint anything, they are all verbose only.
[10:50] <om26er> hence unit-tests ;)
[10:50] <mhr3> sil2100, doesn't really matter that you're reusing old branch
[10:50] <sil2100> mhr3: yeah, I know, just I'm a bit worried if the merger/LP wouldn't go crazy, but hell, let's try and approve
[10:51] <mzanetti> om26er: a) why wouldn't a unit test paint anything? b) you don't necessarily see something even if its accessing the display server
[10:51] <mhr3> sil2100, it'll be fine, i'm doing that from time to time too :)
[10:51] <Cimi> tsdgeos, lp:~unity-team/unity8/dash-renderers
[10:51] <om26er> mzanetti, right, that.
[10:51] <tsdgeos> Cimi: ok, i'll have a look
[10:52] <Saviq> Mirv, hey, is mir 0.1.1 getting into the archive soon-ish?
[10:52] <sil2100> mhr3: phew, I'm always worried, since then there are like 2 merge commits pointing to the same branch, always makes me worry
[10:52] <Cimi> tsdgeos, 1) the indicator triangle at the bottom of the preview does not move
[10:52] <Cimi> 2) the preview of the carousel leads to empty scope after
[10:52] <Cimi> you close it
[10:53] <Mirv> Saviq: very soonish after https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/clean_conffile/+merge/195934 this lands, otherwise all tested
[10:53] <sil2100> dednick: https://code.launchpad.net/~sil2100/ubuntu-settings-components/tests_copyright/+merge/195937 <- with this we can push u-s-c out
[10:53] <Mirv> sil2100: hey, don't hijack the u-s-c abbreviation, it means unity-system-compositor!
[10:53] <Mirv> :)
[10:54] <Mirv> soon we can push both u-s-c's out
[10:54] <sil2100> Daamn
[10:54] <sil2100> ;)
[10:54] <sil2100> It's just so tedious to write the long name, so as long as the person knows the context, I guess it's ok to mix ;p
[10:55] <Mirv> yes of course :)
[10:57] <dednick> sil2100: cool. approved.
[10:58] <om26er> bug 1253044
[10:58] <om26er> Saviq, mzanetti ^ for reference.
[10:59] <Cimi> tsdgeos, maybe we need to create bindings with some properties in DashFilterGrid.qml
[10:59] <Cimi> like alias
[10:59] <Cimi> but can you override a property declaration?
[11:01] <Saviq> Mirv, thanks
[11:01] <Saviq> mzanetti, om26er, maybe those tests just need to run with QT_QPA_PLATFORM=minimal?
[11:02] <mzanetti> Saviq: think about the listviewwithpageheader test for example
[11:02] <tsdgeos> Cimi: let me see
[11:03] <om26er> Saviq, apparently they seem to be running
[11:04] <Saviq> mzanetti, sure, but that's a UI test
[11:04] <Saviq> mzanetti, let's see if om26er can cut it with minimal
[11:04] <mzanetti> yeah ok... the qtmultimedia tests actually might work with that
[11:04] <Saviq> om26er, there's a conflict in https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529
[11:04] <mzanetti> but still I guess the target is to be able to run ui tests too
[11:05] <Saviq> mzanetti, sure
[11:05] <mzanetti> Saviq: Desktop Exec line code '%s' unknown, skipping
[11:05] <Saviq> mzanetti, hmm
[11:05] <Saviq> mzanetti, might be it "protects" against that
[11:06] <Saviq> mzanetti, but anyway, yeah, we just need something that will make upstart exec an arbitrary binary, while saying the .desktop file is foo
[11:06] <mzanetti> but how about this? I have a script "dummyrunner" and a .desktop file for it. I guess passing normal arguments would work to exec stuff in the script
[11:06] <Saviq> mzanetti, sure it would
[11:07] <Saviq> mzanetti, just "exec $@"
[11:07] <Saviq> mzanetti, fwiw
[11:07] <Saviq> Exec=exec %s
[11:07] <Saviq> maybe that'd work
[11:07] <Saviq> although that's not a normal binary
[11:08] <mzanetti> Saviq: yeah. but it still should work if i call "exec someBinary" in there
[11:08] <mzanetti> I do that with some apps to export LD_LIBRARY_PATH first
[11:08] <Saviq> mzanetti, in the script, yes
[11:08] <Saviq> mzanetti, just not directly in the .desktop file
[11:08] <mzanetti> nope
[11:11] <mzanetti> Saviq: no. can't seem to pass arguments to the script
[11:12] <mzanetti> oh.  seems to work
[11:12] <mzanetti>  % U
[11:13] <mzanetti> foo bar
[11:13] <mzanetti> interesting :)
[11:13] <Saviq> mzanetti, so what's the verdict?
[11:13] <mzanetti> % U in IRC causes underscores
[11:13] <mzanetti> ;D
[11:14] <mzanetti> still trying. gimme one more minute
[11:14] <Saviq> %U
[11:14] <Saviq> foo bar
[11:14] <mzanetti> might be my client
[11:14] <Saviq>  % U
[11:14] <Saviq> foo bar
[11:14] <Saviq> yeah, nothing here ;)
[11:19] <om26er> Saviq, thanks, merged with trunk now.
[11:21] <mzanetti> hah. got it
[11:23] <mzanetti> om26er, Saviq: http://paste.ubuntu.com/6447666/
[11:25] <Saviq> mzanetti, yup, sounds right
[11:25] <mzanetti> actually changing Exec to dummyrunner % u  % U  would allow us even to pass arguments to the binary I guess
[11:25] <mzanetti> (without the spaces ofc)
[11:27] <tsdgeos> Cimi: some of your bindings are wrong on the DashFilter
[11:27] <Cimi> tsdgeos, can you spot?
[11:27] <Cimi> tsdgeos, those are not bindings
[11:27] <tsdgeos> Cimi: http://paste.ubuntu.com/6447673/
[11:27] <mzanetti> btw. the lvwph test fails on the phone :P
[11:27] <Cimi> I see
[11:27] <Cimi> makes sense
[11:28] <tsdgeos> and the others probably need the same
[11:28] <tsdgeos> an alias but be indeed better
[11:29] <tsdgeos> and it works too
[11:29] <mzanetti> tsdgeos: hmm... it's always off by 5: http://paste.ubuntu.com/6447677/
[11:29] <tsdgeos> but then you end up in a weird situation in which your base item has a property
[11:29] <tsdgeos> and you have another one
[11:29] <tsdgeos> with the same name :-/
[11:29] <Cimi> tsdgeos, yeah...
[11:30] <Cimi> tsdgeos, it was my concern indeed
[11:30] <tsdgeos> mzanetti: and then segfaults?
[11:30] <mzanetti> yeah. but I'm not sure if that's because the screen blanked
[11:31] <mzanetti> tsdgeos: nope. segfaults indeed
[11:31] <dednick> sil2100: your changes have been merged into ubuntu-settings-components. landing time?
[11:31] <tsdgeos> mzanetti: the input is failing
[11:32] <tsdgeos> those 5 px are the difference between receiving and not receiving the mouse events
[11:32] <mzanetti> strange. given that the other tests seem to work
[11:32] <tsdgeos> mzanetti: it's the only test that uses the mouse to change y
[11:32] <mzanetti> ah ok
[11:32] <tsdgeos> because needs to overshoot
[11:32] <tsdgeos> the others just change the y programatically
[11:33] <mzanetti> hmm... interesting...
[11:33] <mzanetti> tsdgeos: so something in the QPA?
[11:34] <mzanetti> om26er: btw. let me know if that works for you with the QtMultimedia tests
[11:34] <om26er> mzanetti, yeah, will be testing that in a few.
[11:35] <tsdgeos> mzanetti: don't know tbh
[11:35] <tsdgeos> mzanetti: is this new?
[11:35] <tsdgeos> didn't we have test running on the phone for a while?
[11:37] <mzanetti> tsdgeos: I don't think we ever did
[11:37] <tsdgeos> really?
[11:37] <tsdgeos> then it was autopilot running on the phone?
[11:37] <mzanetti> tsdgeos: yeah. AP is
[11:37] <tsdgeos> ah
[11:37] <tsdgeos> hmmm
[11:37] <tsdgeos> don't know what may be causing this
[11:37] <mzanetti> tsdgeos: iiuc om26er is working on getting unit tests running otp too
[11:39] <tsdgeos> qpa may be it
[11:39] <tsdgeos> not sure how mousePress is wired
[11:39] <tsdgeos> maybe it's not wired at all?
[11:39] <mzanetti> heh... that might well be
[11:39] <mzanetti> but wait... I did run qml tests already and iirc they were passing
[11:40] <mzanetti> I guess it uses the same wires
[11:40] <tsdgeos> do we have mousPress calls in there?
[11:40] <mzanetti> qmltests? sure
[11:40] <tsdgeos> ok
[11:41] <tsdgeos> tbh i'm more worried about the crash than this one :D
[11:41] <tsdgeos> but someone would have to debug it properly
[11:41] <mzanetti> yeah... the crash might reveal a real one
[11:41] <tsdgeos> and see why it's not getting the y changed on those moves
[11:41] <tsdgeos> maybe it's all a thing of i need a .gu multiplier
[11:42] <mzanetti> hmm... apart from this, that would be a good idea in any case
[11:42] <mzanetti> the LVWPH tests are freakin tiny here
[11:42] <mzanetti> but I don't think we have GUs in C++ yet
[11:42] <tsdgeos> i can't think why the .gu should matter
[11:42] <tsdgeos> otoh
[11:43] <tsdgeos> since it's all in the same "scale"
[11:43] <tsdgeos> but who knows
[11:43] <mzanetti> tsdgeos: actually... they pass on my desktop which is pretty much the same as on the phone
[11:43] <tsdgeos> right
[11:43] <tsdgeos> it's what i was saying, if everything is small it should still work
[11:43] <tsdgeos> because everything is small
[11:43] <mzanetti> yep
[11:49] <Saviq> om26er, this conflicted, too... https://code.launchpad.net/~om26er/unity8/unlocker_fix_non_working_code/+merge/194850
[11:51] <om26er> Saviq, things are running against me today :/ will fix that.
[11:51] <mzanetti> hey. if I have a flickable, and inside that another flickable. is it possible to scroll the outer flickable when the inner one reaches its end?
[11:52] <Saviq> mzanetti, I don't think it is
[11:52] <mzanetti> Saviq: design wants it
[11:52] <mzanetti> Saviq: any ideas?
[11:52] <Saviq> mzanetti, definitely not if you allow overshoot/dragging on bounds
[11:52] <Saviq> mzanetti, feels like digging in Qt
[11:52] <mzanetti> Saviq: yeah. I tried setting it to StopAtBounds
[11:52] <mzanetti> doesn't work
[11:53] <Saviq> mzanetti, to make it give up the touch if isAtEnd / isAtBeginning
[11:53] <mzanetti> yeah... was hoping I'm not the first one that needs this :D
[11:53] <tsdgeos> mzanetti: you can't do that seamlessly
[11:54] <tsdgeos> i tried to make it work once
[11:54] <tsdgeos> don't remember what for
[11:54] <tsdgeos> but it's just "impossible" as it stands now, nobody is going to pass the extra momentum from the inner flickable to the outer one
[11:55] <tsdgeos> and make it look acceptable
[11:55] <mzanetti> yeah... I was afraid of that
[11:56] <tsdgeos> mzanetti: can't you just use one flickable?
[11:56] <mzanetti> tsdgeos: not really
[11:56] <mzanetti> no
[11:56] <tsdgeos> why not?
[11:56] <tsdgeos> the dash is doing it
[11:56] <mzanetti> tsdgeos: yeah, but the dash doesn't scroll the categories
[11:56] <tsdgeos> or they really want viewport inside viewport
[11:56] <mzanetti> tsdgeos: yep.
[11:56] <tsdgeos> someone kill design :D
[11:57] <tsdgeos> viewport inside viewport looks like a terribly complicated use pattern to me
[11:57] <mzanetti> tsdgeos: https://docs.google.com/a/canonical.com/document/d/1_c4029C6Jwll_ng8gqp3SRnF4DgXRA3tR_LL3J-zOD8/edit
[11:57] <mzanetti> tsdgeos: page 3
[11:58] <mzanetti> tsdgeos: its like the previews in the dash. when you reached the end of the preview, the dash would continue scrolling
[11:58] <mzanetti> tsdgeos: I don't think its really bad for usage. but yeah. its really bad for the developer :D
[11:59] <tsdgeos> mzanetti: but isn't it "expanding"?
[11:59] <tsdgeos> where's the inner flickable here?
[11:59] <mzanetti> tsdgeos: yes. up to a may of ListView.height - delegate.collapsedHeight
[11:59] <mzanetti> tsdgeos: if the expanded content is still larger, it should scroll
[11:59] <mzanetti> s/may/max/
[12:00] <Saviq> mzanetti, but is it really expected that when you reach beginning / end of the content, you continue scrolling?
[12:00] <mzanetti> Saviq: yes. I explicitly asked for that
[12:00] <tsdgeos> mzanetti: i think it may be a wording confusion
[12:00] <tsdgeos> mzanetti: and they just want what the dash does when the expanding category is bigger than the dash
[12:00] <tsdgeos> but i may be wrong
[12:01] <Saviq> tsdgeos, no
[12:01] <Saviq> tsdgeos, I'm afraid in that case it really is it's supposed to scroll inside
[12:01] <tsdgeos> ok
[12:01] <mzanetti> [Monday 18 November 2013] [17:43:48] <katie> when scrolling in the expanded item, and you reach the end of the content (no more scrolling possible), and you try to scroll more, then the list will scroll
[12:01] <Saviq> but I can't see how it'd be acceptable to the user to overshoot and that becoming a "global" scroll
[12:02] <tsdgeos> true
[12:02] <tsdgeos> so what i described is not necessary
[12:02] <tsdgeos> or is it?
[12:02] <Saviq> tsdgeos, you mean killing design?
[12:02] <mzanetti> :D
[12:02] <Saviq> tsdgeos, what mzanetti described is
[12:02] <Saviq> Flickable { Flickable { } }
[12:02] <tsdgeos> Saviq: killing may be a bit too much yeah
[12:02] <Saviq> mzanetti, I believe we must push back
[12:02] <mzanetti> Saviq: he meant to carry over momentum
[12:03] <tsdgeos> so there's two things here:
[12:03] <Saviq> mzanetti, ok well, sure, but that would still be really confusing
[12:03] <tsdgeos> a) do we need to carry momentum? i understand no
[12:03] <mzanetti> yeah, I agree
[12:03] <tsdgeos> b) does a finger drag without releasing should carry to the outer flickable?
[12:03] <tsdgeos> i don't think we can do b) either
[12:04] <tsdgeos> but that may be reasonable usability wise
[12:04] <mzanetti> not without patching the ListView itself I guess, no
[12:04] <tsdgeos> if we don't need any, just setting the inner flicjable to disabled should work
[12:04] <tsdgeos> disable -> non interactive
[12:04] <mzanetti> tsdgeos: yeah. but how do you know to re-enable it?
[12:04] <tsdgeos> good questio
[12:04] <mzanetti> i.e. the user wants to scroll upwards again?
[12:06] <tsdgeos> thinking
[12:06] <mzanetti> event.accepted = true/false might help... but we'd still need to be able to reinject the onPress event
[12:06] <mzanetti> as we can decide at earliest after the finger moved 1 pixel
[12:06] <om26er> mzanetti, upstart-app-launch dummyrunner tst_qaudioinput just returns new line
[12:07] <mzanetti> om26er: yeah. but the test runs :)
[12:07] <om26er> mzanetti, in the background ?
[12:07] <mzanetti> om26er: cat .cache/upstart/application-legacy-dummyrunner-*
[12:08] <mzanetti> Saviq: can upstart-app-launch wait for the binary to exit?
[12:08] <mzanetti> (there's no --help)
[12:09] <Saviq> om26er, how do I test phablet-test-run for clicks? or basically what should I test in your phablet-tools MP (other than unity8 tests, which work fine)?
[12:09] <Saviq> mzanetti, no
[12:09] <Saviq> mzanetti, you then need to stop it
[12:09] <Saviq> mzanetti, i.e. stop dummyrunner
[12:09] <Saviq> or so
[12:10] <Saviq> mzanetti, or well, when it exits, it's exited
[12:10] <om26er> Saviq, try to run camera-app tests so that it unlocks the screen for you. camera-app-autopilot
[12:10] <Saviq> mzanetti, while it's running, you won't be able to launch more dummyrunners
[12:10] <Saviq> om26er, so packaged, not click?
[12:10] <mzanetti> Saviq: yeah. but I'm thinking about batch-running lots of tests
[12:10] <om26er> Saviq, yeah, package
[12:10] <Saviq> mzanetti, right, we need a smarter wrapper then
[12:11] <Saviq> mzanetti, one that would poll until dummyrunner is stopped again
[12:11] <mzanetti> you mean a wrapper around upstart-app-launch
[12:11] <Saviq> mzanetti, yes
[12:11] <mzanetti> mhm... om26er, can you figure this yourself or need my help? ^
[12:12] <om26er> mzanetti, sorry, the logs files only printed: running
[12:12] <Saviq> om26er, and the case when it's already unlocked, that's fixed by your merge to lp:unity8
[12:12] <mzanetti> om26er: then there's something wrong
[12:12] <om26er> Saviq, yes, exactly
[12:12] <mzanetti> om26er: can you paste me the commands you use and the .desktop file you created?
[12:13] <Saviq> om26er, and powering the screen on is another issue completely (i.e. phablet-test-run won't do it for me?)
[12:13] <om26er> mzanetti, if i run like dummyrunner tst_testname --dekstop_file_hint="that.desktop" it crashes the same way
[12:13] <om26er> mzanetti, sure
[12:13] <om26er> mzanetti, http://paste.ubuntu.com/6447835/
[12:13] <mzanetti> omer theres the % u missing in the exec line
[12:13] <om26er> Saviq, yes, it won't do that. there are a number of problems with that.
[12:14] <tsdgeos> mzanetti: yeah i don't think you can really do it as of now
[12:14] <tsdgeos> mzanetti: well actually
[12:14] <om26er> Saviq, if the screen is turned off by hand(with power button) it does not turn on unless the power button is pressed
[12:14] <tsdgeos> mzanetti: the inner flickable won't change size get new elements, no?
[12:14] <Saviq> om26er, mhm, when unlocking fails, it continues to run the test, though, should it not bail out?
[12:15] <mzanetti> tsdgeos: hmm... not sure... it's a component for the SDK where users might put growing stuff into
[12:15] <om26er> Saviq, I should exit on python script failure then ?
[12:15] <tsdgeos> ah :/
[12:15] <mzanetti> tsdgeos: but what would be your idea?
[12:16] <Saviq> om26er, feels like it, yeah
[12:16] <tsdgeos> mzanetti: otherwise i was thinking you could use the hack similar to the one we had for the old QML listview, where we basically had the internal listview disabled all the time and the external one had a fake size and on it's contentY we would move the internal one or not
[12:17] <Saviq> om26er, also, will it work in read-only environment? looks like it installs unity8-autopilot on every run...
[12:17] <tsdgeos> mzanetti: but that had billions of shortcomings when the innerlistview started to grow or whatnot, so if it needs to be an SDK component doesn't look like a good idea
[12:17] <mzanetti> tsdgeos: oh... yeah... I'm afraid that would just cause uncountless bug reports in the SDK
[12:17] <mzanetti> -un :D
[12:17] <tsdgeos> mzanetti: the other option is a simple Qt patch in which be add a way to disable interactiveness just in one direction
[12:18] <mzanetti> right... that might do I guess
[12:18] <tsdgeos> but we all know tihs means we'll have to carry the patch ourselves
[12:18] <mzanetti> yeah. I think we agree in a vUDS session yesterday to avoid that
[12:19] <Saviq> mzanetti, tsdgeos I think we need to push back to design, it's really confusing if the same gesture will do two different things depending on where you are in the list
[12:19] <Saviq> mzanetti, well, if push comes to shove, we just might
[12:19] <dednick> mhr3: is there anyway to get glib to stop logging critical messages ?
[12:19] <Saviq> lol
[12:19]  * Saviq loves the fact that critical messages are not critical and so you might want to stop logging them ;D
[12:19] <mhr3> dednick, of course there is, but i'm not sure you should be doing that :P
[12:20] <dednick> mhr3: lol, no. I'm getting thosands of them though, and it's cramping my other debug logging!
[12:20] <om26er> Saviq, I can do a 'exec_with_adb mount -o remount, rw' if that's not too aggressive ?
[12:20] <Saviq> tsdgeos, re: jenkins, we just need to wait for new mir release, should happen pretty soon
[12:20] <Saviq> om26er, no, that probably won't work, even
[12:20] <tsdgeos> Saviq: cool
[12:20] <Saviq> om26er, and yes, it's definitely too aggressive
[12:20] <dednick> mhr3: i just mean like a G_MESSAGES_DEBUG thing
[12:21] <Saviq> om26er, I was thinking something along the lines of /home/phablet/autopilot
[12:21] <mhr3> dednick, no, you need to call g_log_set_handler()
[12:21] <dednick> mhr3: ah. ok, well that's ok i guess
[12:22] <mhr3> dednick, btw the first param (log_domain) matters
[12:23] <mhr3> you might want to call it multiple times if you're getting criticals from multiple domains
[12:23] <dednick> mhr3: yup, i'm looking at docs
[12:23] <dednick> mhr3: thanks
[12:24] <om26er> Saviq, did the message cut ?
[12:24] <Saviq> om26er, I don't think so
[12:24] <Saviq> om26er, for supporting read-only rootfs, autopilot suites get installed into /home/phablet/autopilot
[12:24] <Saviq> om26er, by phablet-click-test-setup or whatever it's called
[12:25] <Saviq> om26er, I think we should think of the same, otherwise we'll have problems all over
[12:26] <nic-doffay> tsdgeos, the results came back from that retrigger.
[12:27] <nic-doffay> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/810/consoleFull
[12:27] <Saviq> nic-doffay, we need to wait for new mir
[12:28] <Saviq> nic-doffay, later today hopefully
[12:28] <nic-doffay> Saviq, ok cool.
[12:28] <nic-doffay> Saviq, are there any bugs I can look at? All my branches are waiting on merges right now.
[12:28] <nic-doffay> I've had a look through the list. Not sure which are doable in a short time.
[12:29] <om26er> mzanetti, sorry for being slow got into a lot of conversations. I changed that and the logs printed: http://paste.ubuntu.com/6447901/
[12:29] <mzanetti> om26er: no worries
[12:29] <tsdgeos> nic-doffay: i commented on your expansion thing
[12:29] <tsdgeos> nic-doffay: seen it?
[12:29] <om26er> Saviq, let me think of a solution for the local install and come back with a solution.
[12:29] <Saviq> om26er, sure
[12:29] <mzanetti> om26er: hmm... now that is weird
[12:30] <mzanetti> om26er: ah.. I guess you need to give the absolute path
[12:30] <mzanetti> (or relative to /home/phablet/
[12:30] <Saviq> nic-doffay, I believe greyback wanted to take you over for some unity-mir/autopilot work, sounds like now's the time?
[12:30] <mzanetti> )
[12:30] <Saviq> mzanetti, om26er needs to be absolute, yes
[12:31] <Saviq> well, relative to ~ could work, but not reliable
[12:31] <Saviq> /food
[12:31] <om26er> mzanetti, that's absolute. qtmultimedia-opensource-src-touch/ is on /home/phablet
[12:31] <Saviq> om26er, that's relative to /home/phablet, then ;)
[12:31] <mzanetti> om26er: this is still relative
[12:31] <mzanetti> :)
[12:31] <om26er> Saviq, http://paste.ubuntu.com/6447913/ same :)
[12:31] <dandrader> Mirv, ping
[12:31] <mzanetti> ok. now its absolute. still weird tho
[12:31] <mzanetti> :)
[12:31] <Saviq> brb
[12:32] <Saviq> or biab, rather
[12:32] <mzanetti> om26er: just to make sure. you're positive that the path is correct?
[12:33] <nic-doffay> Saviq, ah yes totally slipped my mind.
[12:33] <nic-doffay> tsdgeos, no not yet, having a look...
[12:34] <mzanetti> om26er: ah got it... you have a Dummy running from a previous attempt
[12:34] <mzanetti> om26er: stop that one (either close it in the ui or do a "stop dummyrunner")
[12:35] <tsdgeos> Saviq: Cimi found an interesting problem when doing the Dash base renderer stuff
[12:35] <nic-doffay> tsdgeos, I can't really test your comment.
[12:35] <tsdgeos> nic-doffay: why?
[12:35] <nic-doffay> I don't have files on folders visible on my home scope.
[12:36] <tsdgeos> mhr3: can you help nic-doffay get them ? ↑↑↑
[12:36] <tsdgeos> pstolowski: or you ↑↑↑
[12:37] <Saviq> nic-doffay, add music to your device and test on device
[12:37] <Saviq> same thing
[12:37] <om26er> mzanetti, I stopped dummyrunner as well :/
[12:37] <om26er> mzanetti, let me reboot the phone just to be sure
[12:39] <om26er> mzanetti, now confirmed. it still gives QUbuntu: Could not create application instance
[12:39] <mzanetti> dammit... but it works fine here...
[12:39] <mzanetti> om26er: you sure that you aren't reading the wrong logfile?
[12:39] <mzanetti> om26er: a new one gets created on every run
[12:40] <om26er> mzanetti, I did: rm .cache/upstart/application-legacy-dummyrunner-*
[12:40] <tsdgeos> Saviq: the problem is, if we define properties in the BaseRender, later in DashRenderer we have either to redefine the properties as alias (which defeats a bit the purpose of defining them on the base class) or create bidings, the problem with bindings is that they can easily get broken if you do an =
[12:41] <tsdgeos> Saviq: or we can add a pair of onFooChanged and then update the counterpart
[12:41] <tsdgeos> but that's also a bit weird imho
[12:41] <pstolowski> nic-doffay, this is in unity7 I presume; with or without a search query?
[12:43] <nic-doffay> pstolowski, unity8
[12:43] <nic-doffay> without a search query.
[12:44] <pstolowski> nic-doffay, what does 'gsettings get com.canonical.Unity.Lenses home-lens-default-view' say?
[12:44] <nic-doffay> tsdgeos, I've added a search and tried other tabs.
[12:44] <nic-doffay> I don't see any issues there. Note this isn't the Apps tab though.
[12:44] <Mirv> dandrader: pong
[12:44] <nic-doffay> pstolowski, ['applications.scope', 'applications-applications.scope']
[12:45] <pstolowski> nic-doffay, ok, then please add 'files.scope' to this list, and restart home scope
[12:45] <dandrader> Mirv, I was confused about what Qt version (5.0.2 or 5.2) this bug refers to: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1252709
[12:45] <dandrader> Mirv, but looking better at it, it's about Qt 5.2, right?
[12:46] <pstolowski> nic-doffay, or just select Files from home scope filters if you're running unity7, while having search query empty
[12:46] <tsdgeos> nic-doffay: lunch time
[12:46] <tsdgeos> nic-doffay: but it's really very visible flickering
[12:48] <Mirv> dandrader: well it's both depending on what is wanted. if it's ok to wait until we have 5.2 in archives, then it's fix committed and available in qt5-beta2 PPA. if it's needed to be available in archives while 5.0.2 is still in use there, then it needs still to be sponsored over there as well
[12:49] <nic-doffay> pstolowski|lunch, cool cheers
[12:49] <Cimi> tsdgeos, we're also missing other properties
[12:49] <Cimi> tsdgeos, just realised the onCurrentIndexChanged inside preview listview
[12:50] <om26er> Saviq, so I think we need unity8-autopilot in the image seed
[12:50] <dandrader> Mirv, any idea on how long until trusty has 5.2?
[12:52] <Mirv> dandrader: weeks, probably. unity8 now barely runs with that, and then it needs properly tested to have no regressions
[12:53] <nic-doffay> tsdgeos, I see it
[12:53] <nic-doffay> good catch, thanks
[12:54] <dandrader> Mirv, in that case it would be nice to have on 5.0.2 as well, unless it's troublesome to get it there. In the end it's not really a *must have* at the moment.
[12:57] <Mirv> dandrader: the trouble is mostly that someone would need to run the AP tests of http://reports.qa.ubuntu.com/smokeng/trusty/touch/ against that updated version
[12:58] <Mirv> dandrader: was it built somewhere already?
[12:59] <dandrader> Mirv, you mean debian packages with it? I think not. I built it locally on top of upstream qt and played around with if (with both stable and dev branches)
[12:59] <dandrader> s/if/it
[13:00] <dandrader> Mirv, ah, built the amd64 packages for ubuntu qt 5.2 as well. if that's what you meant
[13:00] <Mirv> dandrader: ok, the general rule is for updating Qt packages to run the -autopilot tests mentioned at http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/ on device to see that there are no regressions (hopefully automated at some point)
[13:00] <Mirv> dandrader: I meant the 5.0.2 packages, for getting anything updated into archives
[13:00] <dandrader> Mirv, ok, I'll take note of that
[13:22] <Cimi> tsdgeos, ok fixed the carousel preview
[13:22] <Cimi> tsdgeos, but it's weird...
[13:22] <Cimi> tsdgeos, I have to put dummy values for columns and other properties
[13:37] <Saviq> tsdgeos, yeah, that's what I meant last time I mentioned multi inheritance ;)
[13:37] <Saviq> tsdgeos, I know you'll find the least ugly solution :)
[13:38] <Saviq> om26er, yeah, that'd be one possible way indeed
[13:43] <Saviq> om26er, but I'm not the one to make that decision
[13:46] <om26er> Saviq, sure. I'll ask ogra for that :) and maybe propose a branch for ubuntu-touch-seed
[13:55] <Saviq> mzanetti, you might want to join http://summit.ubuntu.com/uds-1311/meeting/21991/core-1311-cross-compilation/
[13:56] <mzanetti> Saviq: yip yip
[13:56]  * Saviq got a conflict again :[
[13:56] <Saviq> Qt5 or Xcompilation...
[13:57] <Saviq> who wants to play rock, paper, scissors with me/
[13:57] <Saviq> ?
[13:57] <tsdgeos> i can do qt5 if you want
[13:57] <Saviq> tsdgeos, right, you know more than me anyway
[13:57] <Saviq> solved!
[13:58] <tsdgeos> need someone to invite me to the thing though if they want to see my ugly face
[13:59] <Saviq> tsdgeos, there's a link "join the hangout" at the top
[14:00] <Saviq> tsdgeos, or will be, at least
[14:00] <tsdgeos> ok
[14:00] <tsdgeos> there is not for me
[14:00] <Saviq> tsdgeos, once they start it should show up
[14:00] <Mirv> tsdgeos: https://plus.google.com/hangouts/_/7ecpjhcv91f5e2g6cvefjmia44?authuser=0
[14:00] <Mirv> Saviq: ^
[14:00] <Saviq> done :)
[14:00] <Mirv> if interested in Qt5
[14:00] <Saviq> Mirv, tsdgeos's going
[14:00] <Saviq> mzanetti, oh, there's a competing xbmc remote in the app store ;)
[14:01] <mzanetti> not exactly competing though :P
[14:01] <Saviq> mzanetti, and it seems searching is case-sensitive ;(
[14:01] <Saviq> ;D
[14:01] <Saviq> mzanetti, you need better screenshots :P
[14:01] <Saviq> mzanetti, ones without window borders
[14:01] <mzanetti> heh, true
[14:02] <mzanetti> Saviq: elopio packaged up that web xbmc remote and we published it roughly the same day
[14:02] <mzanetti> Saviq: but now elopio is one of my beta testers :D
[14:03] <Saviq> mzanetti, oh it's android-y
[14:42] <mterry> doh, missed meeting
[15:00] <tsdgeos> Saviq: good news the exception crash we were seeing in arm-only is fixed with the Qt RC code
[15:00]  * tsdgeos flashes his phone to clean it a bit
[15:02] <tsdgeos> what's the current phablet-flash command to use? my history doesn't have it in there anymore ^_^
[15:02] <popey> tsdgeos: phablet-flash ubuntu-system --channel trusty
[15:03] <tsdgeos> tx
[15:09] <Saviq> tsdgeos, cool
[15:09] <Saviq> tsdgeos, or trusty-proposed if you want to ride the wave
[15:12] <tsdgeos> Saviq: greyback: any chance we can merge this https://code.launchpad.net/~aacid/qtubuntu/event_dispatcher_52 even if it doesn't build on desktop yet? will get us closed on the phone side
[15:13] <tsdgeos> Mirv: speaking about patches, can we carry this one? https://codereview.qt-project.org/#change,71717 it's not fully accepted yet but enables building again desktop opengl with EGL that will help fixing the qtubuntu desktop compilation problem we're seeing right now
[15:14] <Mirv> tsdgeos: awesomeness, bookmarking. can you open a qtdeclarative bug about it?
[15:15] <tsdgeos> Mirv: qtbase?
[15:15] <Mirv> tsdgeos: yeah, https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src
[15:15] <tsdgeos> ok
[15:15] <tsdgeos> damnit, i have two +1 but noone giving the +2
[15:15] <tsdgeos> hate those situations :D
[15:16] <Mirv> tsdgeos: yesterday there was also talk about having kind of libxcb_opengl and libxcb_gles for desktop, and Saviq estimated it wouldn't be a huge problem, but today I've started to doubt a bit how far the implications of ./configure -opengl desktop go beside the QPA plugin
[15:16] <tsdgeos> i can't tell which implications it has tbh
[15:16] <tsdgeos> but it should be doable
[15:17] <tsdgeos> given enough man hours
[15:17] <tsdgeos> i.e. if it's not totally isolated into the QPAs
[15:17] <tsdgeos> it should
[15:17] <Mirv> like if I do ./configure opengl -desktop and ./configure -opengl es2, can I just build two QPA plugins... and my guess would be that it's not that simple
[15:18] <Mirv> ok, "doable" sounds good at least, I was fearing "impossible" :)
[15:18] <Mirv> but well yeah no-one knows yet
[15:18] <greyback> tsdgeos: it looks good, just testing it is annoying :) I've a 5.2 and a 5.0 machine ready, so I can take it
[15:19] <tsdgeos> greyback: i'd appreciated if you did, i know it's a bit of a work, but will get us a bit closer to the goal
[15:19] <greyback> tsdgeos: will jenkins accept it? It'll probably fail to build on non-arm arches
[15:20] <tsdgeos> greyback: it will
[15:20] <tsdgeos> because jenkins is building 5.0
[15:20] <tsdgeos> so it works the same it did
[15:20] <greyback> true
[15:20] <tsdgeos> greyback: i mean, the thing is approved by CI already
[15:26] <tsdgeos> yay libmirserver is here
[15:26] <tsdgeos> let's reapprove stuff
[15:28] <tsdgeos> Mirv: will this https://code.launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+recipebuild/587630 autostart itself when the dependency is available? or needs some manual prodding?
[15:31] <greyback> tsdgeos: approved
[15:31] <tsdgeos> cool, tx
[15:33] <Mirv> tsdgeos: it should, but as it hasn't yet maybe it doesn't work for recipes so kicking again. new Mir is now in release pocket since 1.5h
[15:34] <Mirv> (kicking as soon as the recipe page loads without Timeout error)
[15:35] <tsdgeos> he he
[15:35] <tsdgeos> tahnks
[15:53] <tsdgeos> Mirv: can you also kick a new qtubuntu rebuild?
[15:53] <tsdgeos> the patch that'll make it build in 5.2 (at least ffffor arm) its also there
[15:54] <Saviq> tsdgeos, sorry, was in a session
[15:55] <Saviq> tsdgeos, did we merge the desktop-incompatible change in qtubuntu?
[15:55] <Saviq> oh cool ;0
[15:55] <tsdgeos> Saviq: it's not desktop-incompatible
[15:55] <tsdgeos> it's as desktop compatible as it is now
[15:56] <MacSlow> mzanetti, Saviq: I fixed https://code.launchpad.net/~macslow/unity8/fix-1200569/+merge/190365 and https://code.launchpad.net/~macslow/unity-notifications/fix-1200569/+merge/190364 ... if you could re-review... thanks in advance!
[15:56] <tsdgeos> it won't build in Qt 5.2 but because of how qt changed
[15:57] <Saviq> tsdgeos, +1 then
[15:57] <Saviq> tsdgeos, post-factum ;)
[15:57] <Mirv> tsdgeos: yeah, I noticed the patch is in and have been trying to reload that page too :) the recipe pages are really, really hard to get opened in LP since a long time..
[15:57] <Mirv> I already was able to click the button but got timeout after that, so I'd like to see if it went through
[15:57] <Saviq> MacSlow, probably not gonna happen until Friday / Monday, UDS taking a lot of my time
[15:58] <tsdgeos> this is looking better :-) https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages
[15:58] <Mirv> cool, it did
[15:58] <Mirv> tsdgeos: so qtubuntu will arrive shortly there as well
[15:58] <MacSlow> Saviq, no doubt... just wanted to get it in the back of your heads at least :)
[16:21] <mzanetti> MacSlow: sure
[16:21] <tsdgeos> sooo
[16:21] <tsdgeos> https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages is all set for the phone :-)
[16:21] <tsdgeos> not amd64/i386 yet though
[16:23] <Saviq> tsdgeos, yay, /me will run some test suites
[16:34] <nic-doffay> tsdgeos, fixed that bug. I've given it a pretty rigorous testing. Would you mind giving it a spin yourself now? Just want to make sure it's thumbs up before moving on to something else.
[16:35] <tsdgeos> nic-doffay: sure
[16:35] <tsdgeos> nic-doffay: would we need some test for it though?
[16:37] <nic-doffay> tsdgeos, we could test the one purpose it has.
[16:38]  * greyback offline for ~45 mins
[16:38] <nic-doffay> tsdgeos, is there some sort of mock for the filter grid?
[16:38] <tsdgeos> nic-doffay: why you want a mock of the filter grid?
[16:39] <nic-doffay> tsdgeos, or a mock of the scopes rather to populate a filter grid for testing.
[16:40] <tsdgeos> nic-doffay: we have mock scopes yes, there's lots of tests for dash, dashcontent, genericscopeview, etc
[16:40] <mzanetti> MacSlow: done
[16:41] <tsdgeos> nic-doffay: yes the blinking is gone
[16:44] <tsdgeos> away for a while too
[16:46] <nic-doffay> tsdgeos, just found a filtergrid test.
[16:46] <nic-doffay> Might as well throw it in there.
[16:46] <nic-doffay> tsdgeos, I'll hit you up when I'm finished with it. Thanks dude
[17:27] <nic-doffay> Saviq, any idea who wrote the bulk of the FilterGrid tests?
[17:28] <dandrader> nic-doffay, me
[17:29] <nic-doffay> dandrader, I'm adding a test to the FilterGrid, it's for startFilterAnimation
[17:30] <nic-doffay> dandrader, thing is it's not interfering with the existing test_turningFilterOffShowsAllElements
[17:30] <nic-doffay> Was wondering if you were aware what had to be reset after it's use?
[17:31] <nic-doffay> dandrader, in my new test the filter variable gets set as per startFilterAnimation.
[17:33] <nic-doffay> *I meant it's now interfering
[17:34] <dandrader> nic-doffay, this startFilterAnimation code is way more recent than tst_FilterGrid. i.e. when test_turningFilterOffShowsAllElements was written there was no startFilterAnimation
[17:34] <dandrader> nic-doffay, so the guy that wrote startFilterAnimation should be updatings the tst_FilterGrid tests to make them comply with the new stuff
[17:34] <dandrader> nic-doffay, which would be tsdgeos
[17:35] <nic-doffay> dandrader, right then I'll be updating it because the function has changed a fair amount.
[17:35] <nic-doffay> dandrader, ta
[19:10] <dandrader> Cimi, ping
[22:30] <pero> can anyone help me get back the unity webapps extension in chromium?
[22:44] <Saviq> pero, better post to ubuntu-devel, most people here are EOD
[22:44] <pero> ok - but what does EOD mean?
[22:57] <Saviq> pero, End Of Day
[22:57] <Saviq> pero, sorry :)
[22:58] <Saviq> pero, acronymfinder.com to the rescue :)
[22:58] <pero> ok, i know that one, but i'm not understanding your sentence then
[23:47] <kgunn> pero: you simply need to formulate your query into an email...and send it to the list at ubuntu-devel....you can signup thru https://lists.canonical.com/