[08:01] <tsdgeos> lol, it shows the CI is back
[08:01] <tsdgeos> 170 emails :D
[08:15] <tsdgeos> anyone knows what's the new s-jenkins ip?
[08:16] <tsdgeos> ok 10.98.3.13 says Mirv
[08:31] <om26er> Saviq, Hi!
[08:33] <mzanetti> o/
[08:39] <Saviq> om26er, o/
[08:39] <Saviq> tsdgeos, don't use IPs
[08:39] <om26er> Saviq, I created a branch for phablet-tools to unlock screen before running tests, I was asked to get it reviewed by you.
[08:39] <Saviq> tsdgeos, just set up the dns https://wiki.canonical.com/UbuntuEngineering/QA/VPN
[08:40] <om26er> Saviq, its using the unlock helpers from unity8
[08:40] <om26er> https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529
[08:40] <Saviq> om26er, will do
[08:40] <tsdgeos> Saviq: but that dns tech is black magic! a good hand written hosts file is the future!
[08:44] <Saviq> Cimi, re: units.gu and no import - yeah, that's what we get for using context props - as long as you import it once somewhere, it's available for everyone everywhere
[08:45] <Saviq> Cimi, not ideal, and yeah, we should have the import everywhere we are using units
[08:50] <tsdgeos> Saviq: do you know if our autolander is really back? we had some autolanding failures due to some jenkins stuff, shall i re-approve them or wait?
[08:50] <Saviq> tsdgeos, yeah it should be working now
[08:50] <tsdgeos> ok, so i'll top-approve them
[08:51] <Saviq> rotfl
[08:51] <Saviq> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/682/artifact/results/autopilot/artifacts/unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears%20%28Desktop%20Nexus%2010%29.ogv
[08:51] <tsdgeos> :D
[08:51] <tsdgeos> come on you can do it, type ubuntu in there!
[08:52] <tsdgeos> but no, it never happens
[08:52] <Saviq> that seems to be the most prevailing failure reason
[08:53] <tsdgeos> i've seen a few with timed out scp
[08:53] <tsdgeos> like https://jenkins.qa.ubuntu.com/job/unity8-trusty-armhf-autolanding/74/console
[08:54] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 conflicted
[08:54] <tsdgeos> booo
[08:54] <tsdgeos> ok, tx
[08:55] <Saviq> tsdgeos, scp should be fixed hopefully since then
[08:56] <tsdgeos> :)
[09:01] <tsdgeos> Saviq: reapprove https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 ? otherwise it'll complain it was approved in 515 but there's a 516 now, no?
[09:01] <Saviq> tsdgeos, right, shouldn't have approved
[09:01] <Saviq> tsdgeos, done
[09:01] <tsdgeos> tx
[09:08] <Saviq> om26er, here you go https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529/comments/451627
[09:16] <Saviq> mzanetti, Cimi, what's the status of https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/192118 ?
[09:18] <Saviq> Cimi, if you could reply to my comment as to what was fixed, would help progress on this
[09:22] <Saviq> mzanetti, this should be ready, right? the last two things got fixed https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803 ?
[09:23] <Saviq> mzanetti, filed a bug for SDK yet? could we link it in a FIXME there?
[09:23] <mzanetti> Saviq: re Cimi's branch: still no tests. do you think it would make sense to have some?
[09:24] <mzanetti> Saviq: re my branch: yes. last 2 things are fixed
[09:24] <mzanetti> Saviq: yes, bug is filed. can add a FIXME
[09:25] <Saviq> mzanetti, re: Cimi's branch, what would you test there? it's mostly really layout changes, apart from maybe one or two "visible" checks
[09:29] <mzanetti> Saviq: yeah... ok. fine with me. do we have at least some test that loads up the loader once? to see if components actually compile
[09:30] <Saviq> mzanetti, don't think we do, that'd be a simple test, though
[09:31] <Saviq> mzanetti, thinking `source = data.source; tryCompare(loader, "status", Loader.Ready)` or so?
[09:31] <mzanetti> let me read it once more
[09:33] <Saviq> tvoss_, https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp/+merge/194797/comments/451440
[09:33] <Saviq> tvoss_, https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp/+merge/194804/comments/451441
[09:34] <Saviq> tvoss_, re: https://code.launchpad.net/~thomas-voss/unity-mir/replace_get_env_with_thread_safe_variant/+merge/195037 - do we have a corresponding set-env? as the actual thread-non-safeness wasn't from two threads getenv'ing, but from one of them getenv'ing while the other was setenv'ing
[09:35] <Saviq> tvoss_, resolved by just moving the setenvs to execute earlier
[09:35] <mzanetti> Saviq: nah... I think its ok...
[09:36] <Saviq> mzanetti, k
[09:57] <mzanetti> Saviq: do you know which designer I should contact regarding the expanding list items?
[09:59] <Saviq> mzanetti, 'fraid not
[09:59] <mzanetti> Saviq: so maybe you can help me then. have a minute?
[09:59] <Saviq> mzanetti, poke the usual suspects
[09:59] <Saviq> mzanetti, sure
[09:59] <mzanetti> Saviq: I'm thinking how to make the API of it. I guess I start off with a ListItem.Base
[10:00] <mzanetti> Saviq: now, it sucks if I force the user to position stuff attached to the top. as he'd need to hardcode the collapsed size and he cannot vCenter the text in there for example
[10:01] <mzanetti> Saviq: also I'm a bit unsure what should happen on expansion. should the item just grow  and with that reveal any previously clipped content? (/me not likes)
[10:02] <mzanetti> Saviq: or should it have some sort of "collapsedContent" and "expandedContent" properties which get exchanged on collapsed/epxanded (/me likes a bit more)
[10:02] <Saviq> mzanetti, as said before, that last part should, IMO, be component-specific
[10:02] <mzanetti> Saviq: or should the expandedContent just be loaded additionally below the content (I think the nicest API and easy to use, but restricts it a bit on the looks&feel)
[10:03] <Saviq> mzanetti, think OptionSelector - it shouldn't have its content replaced, as the content is just a ListView that's being expanded
[10:03] <mzanetti> Saviq: which is not really the case in a expanding list item
[10:03] <mzanetti> Saviq: as the epanded stuff is most likely not a list
[10:04] <mzanetti> but more like previewData
[10:04] <Saviq> mzanetti, the OptionSelector *is* an example of expanding list item
[10:04] <Saviq> where you have an OptionSelector in a ListItem, and it just grows when you "focus" it
[10:04] <mzanetti> Saviq: no. it's the other way round
[10:04] <Saviq> mzanetti, no, it is not ;)
[10:05] <Saviq> mzanetti, ok, let's put it another way
[10:05] <Saviq> mzanetti, an OptionSelector is an example of the *content* of an expandable
[10:05] <Saviq> where that content just grows to fill the expandable
[10:06] <Saviq> mzanetti, we're not after a behavior like we have with the preview (OpenEffect)
[10:06] <Saviq> mzanetti, but instead just an item growing in height when focused, revealing more content
[10:07] <mzanetti> so option one
[10:07] <mzanetti> ok
[10:09] <Saviq> mzanetti, as for "sucks if I force the user to position stuff..." not sure I get what you mean
[10:09] <mzanetti> Saviq: I think most of the times the stuff in there will not be a list
[10:10] <mzanetti> Saviq: so you have the item that looks like a regular ListItem when collapsed
[10:11] <mzanetti> Saviq: but you can't vCenter text in there, as the actually size will change when expanded for example
[10:11] <mzanetti> so you need to anchor it to top/bottom with hardcoding margins etc
[10:11] <mzanetti> still, the most flexible
[10:12] <mzanetti> and that's what we need. so...
[10:13] <Saviq> mzanetti, yeah, nothing better comes to mind
[10:21] <om26er> can I check in python or through bash if the screen is turned on or not? i.e. is there  a powerd api for python or a commandline option without root access ?
[10:35] <Saviq> om26er, I don't think there is, no, sforshee should know more
[10:46] <nic-doffay> Saviq, getting device not found errors in these jenkins reports, haven't seen those yet https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist
[10:48] <Saviq> nic-doffay, it's in queue to run one more time - there were some configuration issues a few hours ago still
[10:48] <nic-doffay> Saviq, kk
[10:49] <Saviq> nic-doffay, but it's better now, we got two green ones already this morning http://s-jenkins:8080/job/unity8-autolanding/
[10:53] <Saviq> nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145 fails due to "ListItem.ItemSelectorDelegate is not a type"
[10:53] <Saviq> nic-doffay, did that get renamed or something?
[10:53] <nic-doffay> Saviq, that's waiting on an sdk branch.
[10:53] <Saviq> nic-doffay, ok
[10:54] <nic-doffay> Saviq, I still need that icon from design, everything else has been seen to though.
[10:54] <Cimi> Saviq, don't really know how to fix the carousel...
[10:54] <Cimi> asin landscape
[10:55] <Cimi> *in
[10:56] <Cimi> because it scales....
[10:56] <Cimi> it's dynamic
[10:57] <Cimi> it's bigger than when it's in portrait
[10:57] <Cimi> so the assets and spacing/padding/margins are different
[10:57] <Cimi> fonts too
[11:01] <Saviq> Cimi, well it should just scale with them, should it not (i.e. margins and such should be a factor of the size)
[11:01] <Cimi> Saviq, but they won't be pixel grid aligned?
[11:01] <Cimi> Saviq, when it involves operations
[11:01] <Saviq> Cimi, dednick had a "align-to-grid" function somewhere
[11:02] <Saviq> Cimi, in indicators
[11:02] <Saviq> Cimi, that would find the closest grid-aligned value for an arbitrary value
[11:02] <Cimi> Saviq, but the asset is not aligned maybe
[11:02] <Cimi> dunno
[11:02] <Cimi> have to try
[11:02] <Saviq> Cimi, font size should be good as-is, we don't want to scale fonts
[11:02] <Saviq> Cimi, please do
[11:02] <Saviq> Cimi, as this will break badly on the tablet, too
[11:04] <Cimi> Saviq, I think we need better ubuntu shape
[11:04] <Cimi> like when we can finally fill inside
[11:04] <dednick> Panel/Indicators/DefaultIndicatorWidget.qml::guRoundUp
[11:04] <dednick> Cimi: ^
[11:04] <Saviq> Cimi, please ping loicm on the status of it
[11:04] <Cimi> Saviq, will land before january iirc
[11:04] <Cimi> Saviq, in december
[11:05] <Saviq> Cimi, if you can't find a ~simple "will-do" solution, we'll have to wait for that, then
[11:05] <Cimi> Saviq, I'd wait
[11:06] <Cimi> Saviq, can't think of something that will work now, unless asking for more assets
[11:06] <Cimi> with a .sci file
[11:06] <Saviq> Cimi, just ponder it, if you can't - mark the branch as WiP and comment on the bug accordingly
[11:10] <dednick> Cimi: can you do a review when you have some time?
[11:10] <dednick> Cimi: https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/fix-broken-calendar-tests
[11:12] <mhr3> sil2100, seems like ci is working now, could you setup ci and autolanding for lp:unity-scopes-api?
[11:12] <mhr3> sil2100, althought zmqpp seems to be stuck in proposed?
[11:13] <didrocks> mhr3: releasing to distro is not ready yet though
[11:14] <mhr3> didrocks, not needed to enable ci though, is it?
[11:16] <didrocks> mhr3: well, for upstream merger, it still worth it I guess
[11:23] <tsdgeos> mzanetti: you forgot to fix a typo in the same sentence :D re https://code.launchpad.net/~mzanetti/ubuntu-ui-toolkit/fix-listitems-empty-typo/+merge/195405
[11:24] <mzanetti> tsdgeos: :D
[11:25] <mzanetti> typo overflow
[11:28] <tvoss_> Saviq, we have set_env, too
[11:29] <tvoss_> Saviq, working on a queue of mps right now, will get to that specific one shortly
[11:29] <Saviq> tvoss_, cheers
[11:46] <tsdgeos> dednick: aren't we better served by fixing that in Qt or glib or wherever the root cause is?
[11:46] <Saviq> greyback, ping
[11:46] <greyback> Saviq: pong
[11:47] <Saviq> greyback, icanhazchangelogbump on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224 ?
[11:47] <Saviq> greyback, otherwise the ap tests I've just added to https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 will fail if we don't upgrade libunity-mir
[11:47] <greyback> okies
[11:48] <Saviq> good we don't have .symbols files, 'cause that wouldn't help at that point, we'd need an explicit >= on libunity-mir1
[11:48] <dednick> tsdgeos: yeah, well that would be great. But as far as I can tell, it's not actually bug. It's done that way on purpose.
[11:49] <Saviq> didrocks, here's a question, unity8 build-deps on libunity-mir-dev, there's a behavioral change in unity-mir that unity8 wants to depend on, so we're bumping unity-mir's version and build-depending on >= $that_version
[11:50] <Saviq> didrocks, shlibs will then make sure that there's a Depends on >= $that_version
[11:50] <Saviq> didrocks, but if it was C, and there was a .symbols file, and we wouldn't have changed ABI, would that still work?
[11:51] <Saviq> didrocks, or would shlibs find the lowest possible symbol set and use that for the Depends: unity-mir >= $version ?
[11:51] <Saviq> /food
[11:53] <greyback> Saviq: done
[11:53] <Saviq> greyback, cheers
[11:54] <Saviq> greyback, cu2d would've taken care of the commit message (and the +foo in the version number)
[11:54] <Saviq> greyback, just FYI
[11:54] <greyback> Saviq: didn't know that. Ta
[11:55] <tsdgeos> dednick: really?
[11:55] <Saviq> greyback, hmm why do we have an explicit Depends on libunity-mir1 for unity8?
[11:56] <Saviq> greyback, wouldn't shlibs take care of that?
[11:56] <tsdgeos> dednick: why would it be on purpose?
[11:56] <greyback> Saviq: it would. Not sure why.
[11:56] <Saviq> greyback, k, will prep a branch
[12:01] <om26er> Saviq, fixed per suggestions: https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529
[12:02] <Saviq> om26er, yup, saw that, will look/test soon
[12:02] <om26er> cool
[12:03] <dednick> tsdgeos: explanation given to me:
 dednick: the loop level condition for deleteLater processing is to protect you from calling deleteLater and having it destroyed by a nested event loop while still in scope
[12:04] <tsdgeos> dednick: and why should i care about internal stuff?
[12:04] <dednick> tsdgeos: what we're doing in glib callbacks bypasses the event system.
[12:05] <tsdgeos> so bascially i can't use deleteLater and assume it'll delete stuff later?
[12:05] <tsdgeos> that's a big bug, no?
[12:07] <dednick> tsdgeos: it will delete it. when the current event loop finsishes. Unfortunately that's when we shut the shell down.
[12:07] <tsdgeos> dednick: :D not very helpful
[12:08] <dednick> tsdgeos: yes, I'm painfully aware.
[12:09] <dednick> tsdgeos: unfortunately that's what happens when you twist a framework.
[12:12] <tsdgeos> dednick: so the problem is when we do stuff directly in a glib callback?
[12:12] <dednick> tsdgeos: yeah
[12:12] <mhr3> can't we just detect the case where the callback is called outside of the qt system and deal with that inside deleteLater?
[12:12] <mhr3> tsdgeos, dednick ^?
[12:12] <tsdgeos> dednick: is it just deletelater or everything else that fails?
[12:13] <tsdgeos> mhr3: it's what i was thinking, but i've had no look at the code at all
[12:13] <dednick> mhr3: detect? not that I know of. It's using the same mainloop. There is no difference between an event coming from keyboard and one coming from something we have initiated.
[12:14] <mhr3> dednick, well one goes through some more qt :)
[12:14] <dednick> mhr3: because the keyboard event pushes it through the qt. Which is what we're supposed to do :)
[12:15] <mhr3> dednick, in that case we could deal with it - set a flag when it gets into the qt event system, and unset when it leaves it
[12:15] <mhr3> then inside deleteLater we'd look at that flag
[12:16] <mhr3> problem solved
[12:16] <dednick> mhr3: ? when what goes into qt event system?
[12:17] <mhr3> a qevent
[12:18] <dednick> mhr3: the qevent for the delete ?
[12:19] <dednick> or what caused the delete ?
[12:19] <dednick> tsdgeos: it's only deleteLater
[12:20] <tsdgeos> dednick: i see
[12:20] <tsdgeos> dednick: any idea why deelistmodeltest doesn't get built here?
[12:20] <dednick> tsdgeos: need to compile with -DWITHQT5=1
[12:20] <tsdgeos> ah right
[12:21] <dandrader> mzanetti, got a quick one for you: https://code.launchpad.net/~dandrader/unity8/greeter_edge_hint/+merge/195591
[12:21] <tsdgeos> dednick: seen that CI failed?
[12:21] <tsdgeos> actually fails here too
[12:21] <tsdgeos> hmm
[12:22] <dednick> huh. odd
[12:22] <mhr3> dednick, ok, from start 1) app receives key event (or any other) 2) there's a GSource that gets dispatched 3) that GSource usually sends a QEvent 4) stuff happens (q signals etc etc)
[12:23] <mzanetti> dandrader: what does this exactly do?
[12:23] <mhr3> dednick, now somewhere inside the qt event system we'd set a flag (in sendEvent?), if deleteLater is called with that flag set, use the current behaviour, if not - which should mean that this was an direct glib dispatch - don't wait for the next event loop
[12:23] <dandrader> mzanetti, adds a hinting animation when you press on the right edge of the greeter. try it
[12:24] <mhr3> dednick, makes sense?
[12:24] <dandrader> mzanetti, I think it fits nicely with the teasing animation that happens when you hit the body of the Greeter
[12:24] <mzanetti> dandrader: ah got it. when you press inside the drag area
[12:25] <dandrader> mzanetti, exactly
[12:25] <tsdgeos> dednick: somehow moc is not getting the -DWITHQT5 flag
[12:25] <tsdgeos> maybe a regression somewhere
[12:25] <tsdgeos> ?
[12:25] <dednick> tsdgeos: eh. it may be because i had compiled before i made changes
[12:25] <mzanetti> dandrader: shouldn't the DDA in that case reject the gesture and pass it on to any mousearea behind it?
[12:27] <dednick> mhr3: yeah, makes sense. could possibly work.
[12:27] <tsdgeos> dednick: it's not your fault, the lp:dee-qt one doesn't build here either
[12:27] <tsdgeos> dednick: are you on trusty?
[12:27] <dednick> tsdgeos: no
[12:27] <tsdgeos> i am
[12:27] <tsdgeos> so there you go
[12:27] <dandrader> mzanetti, no. it's the same as what happens when you press on the indicator panel
[12:27] <dednick> i thought i had upgraded...
[12:28] <tsdgeos> something changed in cmake probably
[12:28] <tsdgeos> or somewhere else
[12:28] <tsdgeos> dednick: can you do this for me plz
[12:28] <tsdgeos>  rm modules/Dee/moc_plugin.cpp
[12:28] <tsdgeos> and then
[12:28] <mzanetti> dandrader: well, ok with me. I was just wondering. as my understanding was it would pass on the input to the next handler if it isn't a gesture. in which case the greeter teasing would already work
[12:29] <tsdgeos> make VERBOSE=1
[12:29] <tsdgeos> dednick: and paste the moc line somewhere
[12:29] <tsdgeos> /usr/lib/x86_64-linux-gnu/qt5/bin/moc bla bla
[12:29] <dandrader> mzanetti, 1- the framework for having that forwarding scheme working is not in trunk yet
[12:30] <dandrader> mzanetti, 2- hitting the border of the greeter is different than hitting its main body
[12:30] <dandrader> because you cannot drag it from the main body
[12:30] <dandrader> mzanetti,  whereas you can when you hit its right edge
[12:31] <dandrader> mzanetti, so it makes sense for those two animations to be like they are with this patch
[12:32] <mzanetti> dandrader: yes. I agree. was just curious. but if there is an app in foreground the right edge would pass non-recognized gestures on to the app once the required stuff is in trunk?
[12:32] <dandrader> mzanetti, the fist animation says "hey, hit the border to drag me!" whereas the second tells "you can drag me if you start dragging your finger leftwards"
[12:32] <dednick> tsdgeos: http://pastebin.ubuntu.com/6437235/
[12:32] <dandrader> mzanetti, yes of course. in that case a DragHandle is not used. but a EdgeDragArea
[12:33] <tsdgeos> dednick: so the -DWITHQT5 is there
[12:33] <tsdgeos> not for me
[12:33] <tsdgeos> :-/
[12:33] <mzanetti> dandrader: ah, got it. yeah. thanks
[12:34] <dednick> tsdgeos: from builddir "cmake .. -DWITHQT5=1"
[12:34] <tsdgeos> dednick: sure, but not propagating to moc
[12:34] <tsdgeos> for me
[12:34] <dednick> weird
[12:35] <tsdgeos> well cmake may have regressed
[12:44] <tsdgeos>     Merge branch 'fix-automoc-compile-definitions' into release
[12:44] <tsdgeos> that looks like it :D
[12:52] <dednick> could be, could be :)
[13:17] <dednick> mhr3: trying a patch now. unfortunately it requires me to build qtbase. may take awhile :(
[13:18] <mhr3> dednick, yea, i'll ask about it tomorrow ;)
[14:03] <tsdgeos> dednick: ok, got the new cmake packaged and on prosoped, going to try if that fixes the build for me after rebasing for nth time my qt patch
[14:05]  * mzanetti celebrates jenkins-is-back-day :)
[14:13] <tsdgeos> dednick: yep, problem gone with cmake from trusty-proposed
[14:14] <Saviq> mzanetti, if only it was jenkins-is-really-back-day and not jenkins-is-sometimes-back-day ;P
[14:15] <dednick> tsdgeos: cool
[14:15] <mzanetti> lol
[14:15] <Saviq> mzanetti, too many things still not in their best shape
[14:42] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/ubuntu-ui-toolkit/expanding-listitem/+merge/195602
[14:43] <Saviq> dednick, standup?
[14:45] <mzanetti> MacSlow: we should get this reviewed in order to land your fullscreen branch: https://code.launchpad.net/~mzanetti/unity8/generic-lockscreen/+merge/191951
[14:48] <greyback> kgunn: when is my scenegraph session? I can't find it...
[14:48] <MacSlow> mzanetti, yup
[14:49] <mzanetti> MacSlow: can you review this? I'll take your fullscreen branch then
[14:49] <kgunn> greyback: mmm...let me check....i followed instructions....which may not have resulted in a "planned session" :)
[14:49] <MacSlow> mzanetti, ok
[14:49]  * greyback totally thought USD was next week
[14:49] <Saviq> kgunn, you should also mark folks (me/ricmm) as essential where we're supposed to run them
[14:49] <didrocks> kgunn: hey, just coming to the info from u-s-c not building :)
[14:49] <didrocks> kgunn: also, it seems that platform-api doesn't have the bump build-dep merged?
[14:50] <kgunn> Saviq: so picky...:).... i thot i had...sorry
[14:50] <Saviq> kgunn, I just don't want to miss it, ya know ;)
[14:50] <kgunn> Saviq: i know you were super pumped about it! ;) (...Borat _not_)
[14:51] <tsdgeos> hmmm
[14:51] <didrocks> argh, I saw a kgunn and was thinking it was the Mir channel, let's move there :)
[14:51] <tsdgeos> should we delay our standup tomorrow given it is at the same time of vUDS opening so we can listen to Jono/Mark?
[14:54] <Saviq> mzanetti, there should be only one expanded item per container (i.e. others collapse when you expand a new one)
[14:54] <Saviq> mzanetti, that's not the case yet - that expected?
[14:54] <mzanetti> Saviq: ah right. sure. no forgot that. but its easy
[14:54] <mzanetti> Saviq: but the general approach seems ok, right?
[14:54] <Saviq> mzanetti, just looking at the code - it behaved correctly, yeah
[14:56] <Saviq> mzanetti, looking good, yeah
[14:56] <mzanetti> ok, cool
[14:57] <Saviq> mzanetti, we'll need an ExpandingColumn, too, in case you don't want a ListView
[14:57] <mzanetti> yep
[14:57] <mzanetti> Saviq: altough that would be just setting height: contentHeight; interactive: false
[14:58] <Saviq> mzanetti, nope
[14:58] <Saviq> mzanetti, you'd have to use a Loader to get different delegates
[14:58] <MacSlow> mzanetti, there are three merge-conflicts with  your generic-lockscreen branch atm
[14:58] <Saviq> mzanetti, in a ListView
[14:58] <Saviq> mzanetti, also, for naming I'd go Expandable, ExpandablesListView / ExpandablesColumn or so
[14:59] <mzanetti> MacSlow: oh... fixing asap
[14:59] <Saviq> as ExpandingListView feels like it itself would be expandable
[14:59] <Saviq> mzanetti, for ExpandablesColumn, think of:
[14:59] <mzanetti> yeah, I got it
[15:00] <mzanetti> no repeater
[15:00] <Saviq> ExpandablesColumn { ExpandableFoo { } ExpandableBar { } ExpandableBaz {} }
[15:00] <Saviq> yeah, no model
[15:00] <mzanetti> ack
[15:00] <Saviq> so slightly trickier, but not a whole lot
[15:01] <mzanetti> MacSlow: I'm wondering why the SIM pin lock in trunk still is 4 digits only given that we merged this already: https://code.launchpad.net/~mzanetti/unity8/sim-pin-variable-length/+merge/191625
[15:01] <Saviq> mzanetti, one more thing, though, you need to limit expandedHeight
[15:01] <mzanetti> yep.
[15:01] <mzanetti> there's no fllickable in there yet
[15:01] <Saviq> mzanetti, ok coll
[15:01] <mzanetti> that's what I'm waiting on design for
[15:01] <Saviq> cool
[15:02] <mzanetti> Saviq: there are a few issues with closing it in that case
[15:02] <mzanetti> design-wise
[15:02] <Saviq> mzanetti, yeah I know
[15:02] <Saviq> mzanetti, progressing good :)
[15:03] <mzanetti> thanks
[15:07] <kgunn> greyback: weird...the scenegraph session didn't get approved...don't know why
[15:07] <MacSlow> mzanetti, I can't trigger the pin-entry on my device (unlocked sim).
[15:08] <greyback> kgunn: ok. Bit late to add now?
[15:08] <MacSlow> mzanetti, I used the simentry-example from lp:unity-notifications
[15:08] <MacSlow> mzanetti, and there it works correctly.
[15:08] <mzanetti> MacSlow: not sure what you mean
[15:09] <dandrader> tsdgeos, what motivated you to report https://bugs.launchpad.net/bugs/1250412
[15:10] <dandrader> tsdgeos, ie., what unity8 use case is affected by it
[15:10] <tsdgeos> dednick: cimi's
[15:10] <tsdgeos> Cimi: ↑↑
[15:10] <mhall119> hey guys, who's still developing on Unity 7 in here?  I have some non-work-related questions
[15:10] <dandrader> tsdgeos, you mean this? https://bugs.launchpad.net/unity8/+bug/1193414
[15:10] <Cimi> mhall119, Trevinho
[15:10] <dednick> tsdgeos: eh?
[15:11] <tsdgeos> dednick: sorry, wrong d-autocompletion
[15:11] <dednick> ah
[15:11] <kgunn> greyback: i think so...
[15:11] <mhall119> Trevinho: ping when you're around
[15:11] <tsdgeos> dandrader: well, the branch he's working on to fix that
[15:11] <MacSlow> mzanetti, what did you run to check what pinlength is used?
[15:11] <kgunn> greyback: for sure...even it does get add late...no prep...just a review of where we're at
[15:11] <Trevinho> mhall119: pong
[15:11] <mzanetti> MacSlow: there is no such thing as a pinlength any more
[15:12] <greyback> kgunn: okies, keep me posted anyway
[15:12] <tsdgeos> dandrader: i don't remember the branch exactly
[15:12] <tsdgeos> dandrader: but basically anything that needs the topmostitem feature in IMA
[15:13] <tsdgeos> s/enables/needs
[15:13] <dednick> damned qt private data exports...
[15:13] <mhall119> Trevinho: hey, how hard would it be to build a new desktop session (an alternative to ubuntu-desktop) that uses Unity, without it's settings conflicting with ubuntu-desktop's Unity settings?
[15:14] <mhall119> I tried to do this with Xfce years ago with moderate success
[15:14] <MacSlow> mzanetti, but in Greeter/PinLockscreen.qml there's still this property "pinLength"... I'm confused now.
[15:15] <mzanetti> MacSlow: yeah. ignore that. just don't use it in the notification
[15:15] <Trevinho> mhall119: mhhm... well unity settings are stored all in gsettings, but some via comipz other directly...
[15:15] <Saviq> didrocks, (how) can you mark people as essential for a session on UDS?
[15:15] <Trevinho> mhall119: so... for compiz side all you need is just to add a new compiz profile
[15:15] <Saviq> didrocks, pinging you as you're marked as the person to ask for that on the session participation page
[15:15] <Trevinho> mhall119: for gsetttings side I think you need to force a different backend when starting the session
[15:16] <mhall119> Saviq: only the meeting's creator (and possibly track lead) can mark people as essential
[15:16] <seb128> Saviq, just subscribe them to the bluepprint and tick the "presence required" box?
[15:16] <Trevinho> although, this last one would probably affect even compiz settings, so should apply to all
[15:16] <mhall119> Trevinho: blegh, I was going to have to do that with Xfce too, which was hit-or-miss
[15:17] <Saviq> seb128, hmm there seem to be sessions without blueprints (http://summit.ubuntu.com/uds-1311/meeting/22084/unity8-shell-discussion/)
[15:17] <mhall119> which means in order to have separate Unity/Compiz settings, I also necessarily have to have different GEdit settings (and different settings for any app using gsettings)
[15:17] <seb128> Saviq, ok, so what mhall119 said then
[15:17] <mhall119> seb128: the Launchpad "require" option is no longer strictly enforced in Summit
[15:18] <mhall119> LP "required" = Summit "would really like to attend but not absolutely critical"
[15:18] <Trevinho> mhall119: I see... mh, well, I didn't check gsettings much, probably other guys are much more experienced with it than I am, but I don't know if it's possible to define a different profile for  just a class of setings... it seems tha compiz is doing that in some way, but I didn't study that much
[15:18] <seb128> mhall119, oh? since when? what's the right way to make sure people don't have conflicts?
[15:18] <MacSlow> mzanetti, so there also is no "x-canonical-pin-length" anymore?
[15:19] <mzanetti> MacSlow: nope
[15:19] <mzanetti> MacSlow: that merge actually already removed that... I guess it came back somehow which is what it breaks again
[15:19] <seb128> Saviq, I can add participants I think ... who do you need?
[15:20] <didrocks> Saviq: can do as well if needed
[15:20] <MacSlow> mzanetti, no idea what what merge might have reverted that
[15:21] <mzanetti> MacSlow: fixed the merge conflicts
[15:21]  * mzanetti -> food
[15:21] <mhall119> seb128: for a while now, since before Copenhagen at least
[15:22] <mhall119> seb128: Summit will warn about conflicts with "really would like to attend", but it won't block them
[15:22] <seb128> mhall119, ok, that's good enough I guess (if people schedule do take the warnings into accounts and tweak to resolve those)
[15:23] <MacSlow> mzanetti, ok
[15:25] <mhall119> seb128: with auto-scheduling turned off for vUDS, it really doesn't make much of a difference either, it was mainly removed to make auto-scheduling/rescheduling less disruptive to the schedule
[15:26] <seb128> right
[15:26] <seb128> mhall119, thanks
[15:27] <Cimi> Saviq, tsdgeos so I have API shared between carousel and filter grid, but when I use a loader to load those I guess I need to alias all those properties
[15:27] <Cimi> is there a way to avoid that and duplicating code?
[15:27] <tsdgeos> i don't think so
[15:30] <tsdgeos> Cimi: do you have the branch where you need the topmostItem enabled IMA ?
[15:30] <tsdgeos> i forgot the url
[15:31] <Cimi> tsdgeos, it was a patch
[15:31]  * Cimi looks history
[15:31] <Cimi> http://paste.ubuntu.com/6382346/
[15:31] <tsdgeos> dandrader|lunch: ↑↑↑
[15:32] <tsdgeos> dednick: ping
[15:32] <dednick> tsdgeos: plop
[15:33] <tsdgeos> dednick: i was wondering why you went that weird QGlibCallbackEvent instead of just doing a QMetaObject::invokeMethod that my quick test shows it seems to work too
[15:33] <tsdgeos> i think it's simpler (doesn't need a new class)
[15:33] <dednick> tsdgeos: you use queud connection?
[15:33] <tsdgeos> yep
[15:34] <dednick> tsdgeos: because it goes onto the post queue. we don't want that
[15:35] <tsdgeos> ah right, you're sending it instead of posting it
[15:35] <tsdgeos> which tbh in this specific case i don't see why it should make any difference
[15:36] <dednick> tsdgeos: yeah, otherwise it's async, and the values we use in the callbacks may not be valid fot the dee model. Would get much more compicated to cache.
[15:37] <tsdgeos> hmmm
[15:37] <tsdgeos> ok
[16:03] <dednick> qt stacktrace over 125 levels deep. sigh...
[16:06] <tsdgeos> mzanetti: what do we do with https://bugreports.qt-project.org/browse/QTBUG-32251 ?
[16:06] <tsdgeos> kill it?
[16:06] <tsdgeos> or?
[16:08] <tsdgeos> dednick: so there's no way we can fix it inside deleteLater? mhr3's idea no good?
[16:09] <dednick> tsdgeos: mhr3's seems to be working, but i'm just testing and getting a few "out of context" deletes (this special case) which i don't know where are coming from in unity8.
[16:09] <dednick> tsdgeos: and the stack is so deep, that i can't get to the bottom :(
[16:10] <tsdgeos> lol
[16:10] <dednick> but it seems to be to do with changing the theme name
[16:10] <mhr3> dednick, you sure you're not getting stack overflow?
[16:10] <tsdgeos> tbh i'd prefer a fix in deleteLater than this fix
[16:11] <mhr3> such deep stack sounds like something broken
[16:11] <dednick> tsdgeos: yes, well we would have to fix it elsewhere if not in qt. gsettings-qt is another place i've found which will suffer.
[16:11] <tsdgeos> dednick: if you want i can try to help you with this effort, i even fixed the qt event loop ordering events incorrectly once (took me two days to fix it and two weeks to convince the Qt guys they had a bug in there) :D
[16:12] <dednick> tsdgeos, mhr3: http://pastebin.ubuntu.com/6438140/
[16:12] <mhr3> some debug symbols would be nice :)
[16:12] <dednick> tsdgeos: yeah, help would be appreciated.
[16:12] <mhr3> dednick, can you pastebin the patch?
[16:13] <mzanetti> tsdgeos: good question...
[16:13] <tsdgeos> mzanetti: i'm voting to kill it
[16:13] <tsdgeos> and open a new clean one if we need later
[16:13] <mzanetti> tsdgeos: ok
[16:13] <tsdgeos> this one's already linked to a dead review request
[16:13] <dednick> mhr3: um... i apt-source'd it.
[16:13] <tsdgeos> which makes it "unclean it"
[16:14] <dednick> mhr3: how do i gen changes?
[16:14] <mhr3> dednick, apt-source again and diff the dirs?
[16:14] <tsdgeos> dednick: my "i know nothing about deb" way is doing what mhr3 says :D
[16:14] <tsdgeos> not sure if there's a more correct way
[16:14] <dednick> :)
[16:14] <mhr3> tsdgeos, yey, i'm not the only one! :)
[16:18] <mhr3> dednick, also, consider installing pkg-create-dbgsym for the next build :)
[16:18] <mhr3> (that will give you .ddebs in your build-area)
[16:20] <dednick> mhr3: http://pastebin.ubuntu.com/6438169/
[16:22] <dednick> mhr3: meh. most of that is from libqt5declarative, which i'm not building myself
[16:31] <tsdgeos> dednick: can you explain a bit the logic of the patch?
[16:32] <mhr3> i was about to ask about the isWidgetType
[16:32] <mhr3> why events are not delivered to non-widgets?
[16:32] <mhr3> i guess those don't go through coreapplication?
[16:33] <dednick> hm, yeah, i'm not sure about that
[16:37] <dandrader> Saviq, ping
[16:43] <dandrader> Cimi, I'll investigate https://bugs.launchpad.net/unity8/+bug/1193414 taking into consideration the patch I've written to Qt (https://codereview.qt-project.org/71241) and if/how InverseMouseArea would benefit from it
[17:07] <om26er> mterry, hey! can you point me to the code in unity8 which turns on the screen when a call arrives ?
[17:08] <mterry> om26er, I'm guessing that's deeper than unity8.  the way screen display is controlled is that powerd talks over dbus to unity-mir.  I'm not sure which piece of code pokes powerd upon a call arriving though
[17:09] <mterry> om26er, something in the ofono stack?
[17:09] <om26er> mterry, I am thinking telephony-service. will as salem_
[17:10] <om26er> *ask
[17:10] <cwayne> Saviq: hey, re: our discussion awhile ago about choosing a background based on whether the device is a phone/tablet/desktop.. is there a UDS session to address this?
[17:11] <Saviq> dandrader, pong
[17:11] <Saviq> cwayne, I don't think there is, but we might hijack one of the convergence sessions
[17:11] <dandrader> Saviq, so what's the procedure to have a qt patch backported?
[17:12] <salem_> mterry, the code currently lives in powerd itself. but we should move it to another place.
[17:12] <salem_> om26er, ^
[17:12] <Saviq> dandrader, I'd say easiest is to:
[17:12] <Saviq> a) branch lp:ubuntu/qtdeclarative-opensource-src
[17:12] <om26er> salem_, so telephony-service asks powerd to turn on the display when a call arrives ?
[17:12] <Saviq> b) quilt -import <patch file>
[17:13] <Saviq> c) resolve any patch issues
[17:13] <Saviq> d) quilt refresh
[17:13] <salem_> om26er, no, powerd talks directly with ofono.
[17:13] <Saviq> e) bzr commit / propose merge
[17:13] <Saviq> dandrader, or, if you don't want to learn what quilt is and stuff ;)
[17:14] <Saviq> dandrader, file a bug against lp:ubuntu/qtdeclarative-opensource-src
[17:14] <Saviq> dandrader, and attach the patch file - ideally backported to 5.2 if required
[17:14] <Saviq> dandrader, but if you don't backport it - whoever will integrate it, will
[17:15] <dandrader> Saviq, ok, thanks
[17:15] <Saviq> dandrader, don't hesitate to ping if you need pointers
[17:46] <sil2100> mhr3: hi! lp:unity-scopes-api is to be daily-released sooner or later?
[17:46] <sil2100> (although the term daily-release is not as accurate now as it was before)
[17:46] <mhr3> sil2100, the sooner the better
[17:47] <sil2100> mhr3: ok, I'll review the packaging then and prepare
[17:47] <mhr3> sil2100, but at least having autolanding would be nice
[17:48] <mhr3> sil2100, i mean automerging of branches to trunk
[17:49] <sil2100> mhr3: right, let me work on that as well
[18:43] <dednick> mhr3: so you coming to the office tomorrow?
[20:01] <mhr3> dednick, yep, afternoon
[20:48] <Cimi> mhr3, you're worse than me!
[20:48] <Cimi> :P
[20:50] <veebers> Saviq: Hey I saw the unity-ci runs succeeded finally. Was it an infrastructure thing, unity thing or generally unstable?
[20:51] <Saviq> veebers, depends - last issue I saw was https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252386
[20:53] <veebers> Saviq: ah ok, cheers
[20:53] <Saviq> veebers, but yeah, it's getting better
[20:53] <Saviq> veebers, just slow - stuff's queued up
[20:54] <veebers> Saviq: Ack, it's good to have the labs back though :-)
[20:55] <Saviq> indeed
[23:13] <mhr3> Cimi, nope, you still hold the record :P