[07:05] <ashadiqi> can i chat now?
[09:43] <anpok> what is the cross-compilation safe way of querying QT_INSTALL_QML path within cmake?
[09:43] <anpok> i have seen scripts calling qmake -query QT_INSTALL_QML? But that seems to fail in sbuild
[09:53] <anpok> oh ok Saviq already reported that
[10:01] <anpok> boneheads /o\
[10:24] <Saviq> anpok, yeah, the "safe" way is ${CMAKE_INSTALL_LIBDIR}/qt5/qml
[10:29] <Saviq> AlbertA, could you please confirm in bug #1364453 what needs to happen
[10:29] <ubot5`> bug 1364453 in unity8 (Ubuntu) "Brightness setting does not persist across reboots" [High,Confirmed] https://launchpad.net/bugs/1364453
[10:41] <anpok> Saviq: thx works
[11:01] <facundobatista> Buenas
[13:05] <dandrader> dednick, I wonder how come this wasn't crashing http://paste.ubuntu.com/8318782/   As was doing some qtmir changes this test was crashing and I did this change to fix it.
[13:19] <greyback>    Actual   (): USD0.99
[13:19] <greyback>    Expected (): 0.99USD
[13:19] <greyback> what do I set to fix that test?
[13:24] <Saviq> greyback, LC_ALL=C
[13:24] <greyback> Saviq: I guessed that, thanks
[13:25] <greyback> just wanted confirmation while I waited :)
[13:48] <dednick> dandrader: erm.
[13:49] <dednick> dandrader: i guess the memory was still valid
[13:50] <dednick> dandrader: were you doing test in a debug build maybe?
[13:51] <dandrader> dednick, yeah. maybe debug builds clear out freed memory right away
[13:51] <dandrader> but release ones don't just bother (aka optimization)
[13:52] <dandrader> *just don't
[13:52] <dednick> dandrader: ya. probably
[13:57] <kgunn> popey: hey, so these are both yours...kinda feels like a dup...wonder if there's a slight nuance diff i'm missing (before i dup)
[13:57] <kgunn> bug 1355422
[13:58] <kgunn> bug 1334855
[13:58] <popey> yeah, they're same
[13:59] <popey> i expect i forgot i filed one
[13:59] <popey> yeah, 2 months between them, i certainly forgot ☻
[13:59] <popey> feel free to dupe them.
[14:02] <Saviq> karni, https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/2
[14:03] <karni> Saviq: yes
[14:06] <karni> Saviq: I'm supposed to run this on the device, or can I adb pull the log and run it on it?
[14:06] <karni> on my PC
[14:06] <Saviq> karni, device
[14:06] <Saviq> karni, although at this point (I assume it's uploaded to errors.u.c it already has all the data)
[14:07] <karni> there's no .uploaded file yet
[14:07] <Saviq> karni, enough if there's an .upload one
[14:07] <Saviq> karni, in general if you have a .crash file, use apport-cli to file it to LP
[14:07] <karni> not either
[14:07] <Saviq> karni, then yeah, on device
[14:07] <karni> ok
[14:07] <Saviq> karni, 'cause the .crash doesn't have info from the device yet
[14:10] <karni> Saviq: Can I force the upload of the crash files? I'm reading apport-cli and apport-collect manual, and I've got other important work to do as well :(
[14:10] <karni> I don't know what's the package name of scope runner
[14:10] <karni> and apport-collect won't just take the crash file
[14:10] <Saviq> karni, just apport-cli /path/to/crash
[14:11] <Saviq> karni, let me know the bug number and I'll dupe as needed (you'll have to subscribe me 'cause bug will be private initially)
[14:11] <karni> Saviq: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1368243/comments/3
[14:12] <Saviq> karni, you can remove the "Reason" line from the .crash file
[14:12] <Saviq> karni, you should be able to upload then
[14:13] <karni> Saviq: the crash file does not contain a "Reason" word
[14:13] <Saviq> karni, looks like the crash collection didn't work then
[14:13] <Saviq> karni, steps to repro would be great (or removing the .crash and getting it to crash again, hoping the core will be good)
[14:14] <karni> Saviq: repro is very simple. fresh flash (as of today), and open Photos scope
[14:14] <karni> I'll include that in the report
[14:14] <Saviq> karni, k
[14:15] <seb128> you guys know qml right? do you see anything wrong in http://paste.ubuntu.com/8319172/
[14:15] <seb128> taht's driving me crazy
[14:15] <seb128> why isn't a text entry widget in a mainview with nothing else getting the keyboard focus by default, even with "focus: true" set
[14:15] <Saviq> seb128, because you don't have a FocusScope with focus: true
[14:16] <seb128> Saviq, I though the scope was useful when you had groups of widgets
[14:16] <Saviq> seb128, you need at least one, but in any case I'd recommend Component.onCompleted: forceActiveFocus()
[14:18] <seb128> Saviq, thanks, I guess that works, but it still seems qml is being overly complex there
[14:18] <seb128> those sort of things should just work :/
[14:19] <Saviq> seb128, yeah, but setting focus: true without a FocusScope doesn't do much
[14:20] <seb128> Saviq, the concept of focusscope is not easy to grasp, at least to me
[14:20] <seb128> on a normal column layout, there should be one scope and whatever widget has focus: true should get the focus
[14:20] <Saviq> seb128, http://qt-project.org/doc/qt-5/qtquick-input-focus.html
[14:20] <seb128> without needing of magic
[14:20] <seb128> Saviq, I read that in the past, I guess I need to read it again
[14:21] <seb128> that's the sort of things that seem to just work in other toolkit, I wonder why it doesn't in qt :/
[14:21] <Saviq> seb128, within a FocusScope there's a chain/hierarchy of items, only one on each hierarchy level can have focus: true
[14:21] <Saviq> seb128, that's basically a "cache" of focus
[14:21] <Saviq> seb128, meaning that when the FocusScope gets focus, the last child to have focus: true gains activeFocus
[14:22] <seb128> Saviq, well, in my example there is nothing else that could get focus
[14:22] <Saviq> seb128, this way you can move focus between FocusScopes while maintaining the focus chain within them
[14:22] <seb128> well I can change the pastbin to MainView { TextInput { }}
[14:22] <Saviq> seb128, but only FocusScope handles these
[14:22]  * Saviq has no idea how MainView deals with that
[14:22] <seb128> Saviq, I appreciate it allows for complex scenarios to work
[14:23] <seb128> but it makes simple cases not work
[14:23] <seb128> like one widget on a page
[14:23] <seb128> and focus: true does nothing
[14:23] <seb128> I'm sure I'm not the only appdev to struggle with that ;-)
[14:23] <seb128> Saviq, thanks for the help/explanations!
[14:24] <seb128> Saviq, also on the same example, clicking on the button unfocus the entry, is that normal or a bug?
[14:24] <seb128> http://qt-project.org/doc/qt-5/qml-qtquick-controls-button.html states
[14:24] <seb128> "This property specifies whether the button should gain active focus when pressed.
[14:24] <seb128> The default value is false.
[14:24] <seb128> "
[14:25] <Saviq> seb128, you most probably need to set focus: true on the MainView, too
[14:25] <seb128> setting that property to false works
[14:25] <seb128> so I guess the "default value is false" has an iossue
[14:25] <seb128> Saviq, oh, that works indeed ;-)
[14:26] <Saviq> seb128, wonder if MainView is a FocusScope actually
[14:49] <dednick> Cimi: hey. can you look over the changes i've made to https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/indicator-polishing/+merge/229083 since you approved?
[14:49] <Cimi> dednick, why are you not in the hangout? :)
[14:50] <dednick> Cimi: i am!
[14:55] <dednick> seb128: with the datetime sync issue in u8 indicators, how long does it take to resync once the screen is back on?
[15:03] <Saviq> dednick, under a minute
[15:03] <Saviq> dednick, it looks like it doesn't get the update until it changes again
[15:04] <dednick> Saviq: hm.
[15:04] <Saviq> dednick, but folks confirmed that if they dbus-query it, it's correct there
[15:04] <seb128> dednick, yeah, less than a minute usually
[15:04] <seb128> but it doesn't seem to be on minute changes
[15:05] <dednick> seb128: after the dbus query does the indicator ui sync? or still wrong for a bit?
[15:33] <dednick> seb128: you see the datetime thing on krillin?
[15:33] <seb128> dednick, yes
[15:33] <seb128> dednick, that's the device I'm testing on
[15:33] <dednick> seb128: can't seem to get it to fail on mako
[15:33] <dednick> seb128: will try on krillin
[15:33] <seb128> thanks
[15:33] <seb128> how much did you try?
[15:33] <seb128> it's not consistently happening
[15:33] <seb128> but I can see it several time a day
[15:34] <dednick> 2 or 3 times now. bit painfull waiting constantly :)
[15:35] <seb128> well, I don't think waiting/trying after a few minutes is going to work
[15:35] <seb128> though it might, who knows
[15:35] <Saviq> dednick, you did disconnect it from usb did you?
[15:35] <dednick> Saviq: ya
[15:35] <seb128> typically I pick my krillin from my pocket after an hour not using it, to look at the time
[15:36] <dednick> seb128: my last try was about 20 minutes, but no sync issue i could see
[15:36] <dednick> but if it's random...
[15:36] <seb128> yeah
[15:36] <seb128> what sort of info would you need when it happens?
[15:36] <seb128> the dbus call to the indicator display the right time
[15:36] <seb128> the greeter/lock and panel are off though
[15:38] <dednick> seb128: doesn't it sync straight after you reconnect usb?
[15:39] <seb128> dednick, not sure, going to tell you next time
[15:39] <dednick> seb128: how did you check that the datetime was in sync while the indicator was since it's re-syncing quickly
[15:39] <seb128> oh, good point, so "no, it's not resyncing my plugged"
[15:39] <dednick> seb128: or did you just connect it, then check
[15:39] <seb128> I did connect and check
[15:39] <dednick> ah
[15:40] <dednick> mh
[15:40] <seb128> it took like 45 seconds before having it updated
[15:40] <seb128> I had time to poke around and run the command several times
[15:41] <seb128> dednick, ok, in fact just having it
[15:41] <dednick> seb128: i know that indicator-datetime goes to sleep sometimes when the screen is off (charles, this is correct right?). So i'm just wondering if it's that.
[15:41] <seb128> my device says :39
[15:41] <seb128> I connected to usb, no update
[15:41] <seb128> still outdated
[15:41] <dednick> seb128: can check process state of indicator-datetime?
[15:42] <charles> seb128, is this the issue? https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1359802
[15:42] <seb128> dednick, if the indicator was not running, then the "--object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header" would be outdated
[15:42] <seb128> charles, yes
[15:43] <charles> seb128, dednick, that one's on my short-term TODO after the brightness slider in i-power
[15:43] <dednick> seb128: erm, well it would resume the process through dbus call no?
[15:43] <seb128> dednick, well, that's not enough to have the unity synced thoguh
[15:43] <seb128> I can call the dbus check, get a result
[15:43] <seb128> and still see unity outdated
[15:44] <charles> seb128, if unity is out of sync with the service, that's not the same as 1359802
[15:44] <seb128> charles, indeed not
[15:44] <dednick> charles: yeah, the header seems to be correct
[15:44] <Saviq> dednick, one other thing I noticed that might be related
[15:44] <seb128> dednick, charles, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1365530
[15:44] <Saviq> dednick, when you get a push notification in the notification center menu
[15:44] <dednick> seb128: and calling that dbus method doesn't cause the resync?
[15:45] <seb128> dednick, need to check again to be sure, but iirc no
[15:45] <dednick> seb128: ok. thanks
[15:45] <Saviq> dednick, the LED doesn't light up until you turn the screen on
[15:45] <dednick> LED?
[15:45] <dednick> Saviq: ah.
[15:46] <dednick> Saviq: you mean the notification LED?
[15:47] <seb128> dednick, charles: hum, just tried, in that case the indicator dbus info was outdated
[15:47] <seb128> so maybe several issues there
[15:48] <charles> seb128, how far out of date?
[15:48] <charles> >1 minute?
[15:48] <seb128> charles, 3 minutes
[15:49] <Saviq> dednick, yeah
[15:49] <seb128> it displayed 44 where time was 47
[15:49] <charles> seb128, you queried indicator-datetime on dbus and it returned a time that was 3 minutes off from the wall clock?
[15:49] <seb128> charles, correct
[15:49] <seb128> $ gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime --method org.gtk.Actions.Describe phone-header
[15:49] <seb128> ((true, signature '', [<{'title': <'Upcoming events'>, 'visible': <true>, 'label': <'17:44'>, 'accessible-desc': <'17:44 (a retourné des alertes)'>, 'icon': <('themed', <['alarm-clock', 'alarm']>)>}>]),)
[15:49] <seb128>  
[15:49] <seb128> where computer was on 17:47
[15:49] <charles> seb128: !
[15:49] <seb128> which is the time the phone displayed 15 seconds later
[15:50] <dednick> i'm going to start blaming indicator-datetime ;)
[15:50] <charles> lol
[15:50] <charles> seb128, that's a variation on this theme that I haven't seen before. Is it still happening for you?
[15:50] <seb128> dednick, well, I had cases where the indicator info was right but the unity ui was behind
[15:50] <seb128> charles, "still"?
[15:50] <seb128> the phone is awake now
[15:50] <seb128> let me a few minutes
[15:50] <seb128> but it happens consistently enough
[15:51] <seb128> like I've been 3 occurences in the 15 minutes where we started discussing that
[15:51] <charles> seb128, we've discussed this before but in the past iiuc it's always been unity8 and indicator-datetime being out of sync with each other
[15:52] <charles> rather than datetime being (>1 min) out of sync with the wall clock
[15:52] <charles> seb128, could you please write up how to reproduce that in #1359802 and I will investigate today
[15:52] <seb128> charles, how to reproduce? "wake up your phone, look at the clock"
[15:52] <seb128> not sure what else to write
[15:53] <seb128> charles,
[15:53] <seb128> http://paste.ubuntu.com/8319927/
[15:53] <seb128> just tried again and got ^
[15:54] <seb128> basically "press power button to suspend the krillin, unplug from usb, wait a few minutes, press power button, notice time is off, plug usb cable, adb shell and run commands"
[15:54] <charles> ack
[15:55] <charles> I don't understand why it would lag behind like that
[15:55] <charles> it's easier to explain not updating at all
[15:55] <charles> but how can it lag 3 minutes behind like that?
[15:56] <seb128> I'm happy to help getting debug info if you tell me what to try/do
[15:56] <seb128> charles, well, it might be "not updating", 3 minutes is about the time I let it on the desk while typing on IRC
[15:56] <seb128> hum, just woke it up
[15:56] <seb128> it was on :54
[15:56] <seb128> when I turned it off at :53
[15:56] <seb128> and it should be :56
[15:57] <seb128> ok, just turned :57
[15:57]  * seb128 turns off and wait another 5 minutes
[15:57] <charles> seb128, so, maybe I'm not asking the question right:
[15:57] <charles> 1359802 is about not updating the clock for [1..60] seconds after we wake up from sleep
[15:58] <charles> so if the clock went to sleep at :45 and you woke it up at :50, it might still read :45 for up to 60 seconds
[15:58] <seb128> k
[15:58] <seb128> that might be what I'm seeing here
[15:58] <charles> so I'm less worried about the size of the offset there (5 minutes) than the time to update (<=1 minute)
[16:01] <charles> seb128, if it "fixes" itself in <=1 minute after wakeup then we're still talking about the known bug in 1359802
[16:01] <seb128> charles, ok, let's assume it's that and see if some issue is remaining once that's fixed
[16:01] <charles> ack
[16:02] <seb128> charles, but I had cases some ~10 days ago where the indicator time was right on dbus but the unity ui was not
[16:02] <charles> after that lands I'll start blaming dednick again
[16:02] <seb128> but let's do one issue at tim
[16:02] <seb128> e
[16:02] <charles> seb128, there was one fix for that a couple of weeks ago that I think dednick landed already
[16:02] <seb128> right
[16:02] <charles> seb128, that was around the same time that the datetime indicator was showing up completely empty
[16:02] <seb128> I had that fix for sure
[16:02] <seb128> it was like a week after the fix landed
[16:03] <charles> ugh
[16:03] <seb128> jibel confirmed that
[16:05] <dednick> i'm wondering if fixing 1359802 will just hide the other problem by forcing a reconnection or something
[16:07] <dednick> i'm sorting out my krillin device now. hopefully will be able to put some logging in to find out what's up.
[16:07] <dednick> if i can reproduce it :)
[16:09] <Saviq> bug #1359802
[16:11] <dednick> Saviq: ya, it's possible there are 2 bugs
[17:09] <mzanetti> bregma: hi, I think we're good to go with this now. I've fixed all of Saviq's concerns: https://code.launchpad.net/~mzanetti/unity/new-key-in-launcher-schema/+merge/232199
[17:09] <mzanetti> bregma: what do I need to do to get this released?
[17:10] <bregma> mzanetti, you just wait until I do the next Unity landing (soon...)
[17:11] <mzanetti> bregma: ok, cool. thanks. Can you ping me when it happened so I can release the unity8 related changes for it?
[17:11] <bregma> mzanetti, sure
[17:11] <mzanetti> cheers
[18:24] <dandrader> greyback, still there?
[18:24] <greyback> dandrader: yeah
[18:25] <dandrader> greyback, For the MirSurfaceItem test in qtmir I'll need to create a QGuiApplication and a QQuickWindow, just to be able to send touch events to it via QTest::touchEvent() (unless I abstract that away, but I would rather not)
[18:26] <dandrader> greyback, so is that a problem is qtmir's "make check" has such a "UI" test?
[18:26] <greyback> dandrader: probably yes. We want those tests to run on a headless system
[18:27] <greyback> dandrader: I wonder what my Mir guys have
[18:28] <dandrader> greyback, so I would need that xvfb setup... so much work
[18:28] <greyback> a mock mir server that doesn't talk to hardware would do
[18:28] <greyback> is this testing Mir stuff? You need the mirserver QPA?
[18:29] <dandrader> greyback, did you read my first sentence? :)
[18:29] <greyback> dandrader: I don't understand what you're trying to test
[18:29] <dandrader> greyback, I think I will just abstract away MirSurfaceItem::touchEvent() for now. enough for me to test the touch sequence validation thingy
[18:30] <dandrader> greyback, a scheme similar (but simpler) to what was done for QtEventFeeder
[18:30] <greyback> ok
[18:30] <dandrader> greyback, if you disable an item that is currently receiving a touch sequence
[18:30] <dandrader> greyback, that item will never get a QEvent::TouchEnd for that sequence
[18:31] <dandrader> greyback, QQuickWindow won't send it
[18:31] <dandrader> greyback, sounds like a QT bug, although I wouldn't be surprised if they say that you shouldn't disable a touch owner in the first place
[18:31] <greyback> dandrader: /me surprised by that. How does a MouseArea deal with it?
[18:31] <dandrader> (this kind of stuff)
[18:32] <dandrader> greyback, so I'm adding this touch sequence validation before forwarding touch events to the mir surface
[18:32] <dandrader> greyback, so things keep working regardless of whether qt fixes that or not
[18:32] <greyback> ok, I understand what you're doing at least
[18:33] <greyback> am just curious, can MultiPointTouchAreas be confused in a similar fashion?
[18:33] <dandrader> greyback, the right question is: how does a client-side QQuickWindow deal with it?
[18:34] <greyback> it presumably just waits for the TouchEnd
[18:34] <dandrader> greyback, its mouse event emulation gets stuck, just like unity8's QQuickWindow without that qteventfeeder fix
[18:34] <greyback> dandrader: could this go in qtubuntu then?
[18:34] <greyback> similar event processing that you added to qtmir
[18:35] <dandrader> greyback, it could. but I chose to put it in MirSurfaceItem. fixed earlier in the flow of events
[18:36] <greyback> dandrader: I just think of using qt apps with another mir server - they would potentially exhibit the same problem?
[18:36] <greyback> dandrader: it probably should be fixed in MirSurfaceItem yes, as other toolkits may have the same difficulty
[18:37] <dandrader> greyback, you could add validation on both sides
[18:37] <greyback> dandrader: keep doing what you're doing anyway. Can look at qtubuntu if we actually see a need to fix that
[18:38] <dandrader> greyback, the next step, if we have the time, would be to tackle that issue in Qt itself: reporting a bug and proposing a patch
[18:38] <greyback> dandrader: right
[18:38] <dandrader> greyback, more important than a qtubuntu-side validation imho
[18:38] <greyback> and presumably getting Mir to behave better :)
[18:39] <dandrader> greyback, that's what racarr is doing if I'm not mistaken
[18:39] <greyback> him and RAOF