[07:26] <didrocks> Saviq: hey! I saw robru released unity8 without qmenumodel (both were listed in the landing ask), is there any risk if I kick an image without qmenumodel?
[07:39] <Saviq> didrocks, the bug won't be fixed
[07:39] <didrocks> grrr, I wonder how robru confirmed the fix then…
[07:39]  * didrocks *sigh*
[07:40] <Saviq> didrocks, well, it's a race
[07:40] <Saviq> didrocks, so he might not have encountered it
[07:41] <didrocks> ok
[07:41] <didrocks> Saviq: I'm building qmenumodel right now
[07:41] <didrocks> will deliver and quick an image with it
[07:41] <Saviq> didrocks, cool, thanks
[07:42] <Saviq> didrocks, I found the issue with bug #1256061 - it's unity8 and the indicator in the end - have a fix for unity8 ready, need yet to write a test
[07:42] <didrocks> Saviq: argh, ok. I'll have to explain that to management then :/
[07:43] <didrocks> on the "why did we release unity8 without the fix"
[07:43] <didrocks> Saviq: I'll try to put it nicely ;)
[07:44] <Saviq> didrocks, well, that bug wasn't blocking
[07:44] <didrocks> Saviq: for the unity8 release yeah, it was
[07:44] <Saviq> didrocks, ah right, damn
[07:44] <didrocks> Saviq: do you think this is going to land soon?
[07:44] <Saviq> but was attributed to qtubuntu
[07:44] <didrocks> if so, we can bundle it to the same image :)
[07:44] <Saviq> didrocks, well, today
[07:45] <didrocks> Saviq: if it's in the incoming hour, we can
[07:45] <Saviq> didrocks, but some hours ahead for sure
[07:45] <didrocks> but ok, so will be too late
[07:45] <didrocks> nevermind, keep getting things landing :)
[08:40] <dandrader> Saviq, for getting https://bugs.launchpad.net/unity-api/+bug/1258057
[08:41] <dandrader> Saviq, sorry, I meant this http://paste.ubuntu.com/6557929/
[08:41] <dandrader> Saviq, did you just "bt" or did you also add some arguments
[08:41] <dandrader> for printing out variables on each frame
[08:42] <Saviq> dandrader, that was `bt full`
[08:42] <dandrader> ah
[08:42] <dandrader> didn't know that one, always used just "bt"
[09:11] <dandrader> Saviq, is that a normal output for testLauncher from unity-api? http://pastebin.com/d4EKTZ9k (btw, Ubuntu's pastebin refused this text)
[09:12] <dandrader> I wonder if I'm missing something in my setup...
[09:12] <Saviq> dandrader, looks that way
[09:13] <dandrader> the test didn't fail though...
[09:13] <Saviq> dandrader, yeah, that's just warnings
[09:13] <Saviq> dandrader, should be cleaned up anyway, true
[09:14] <dandrader> Saviq, so you don't get those warnings?
[09:14] <Saviq> dandrader, yes I do
[09:15] <dandrader> ah, ok. then my setup is fine
[09:15] <Saviq> dandrader, sorry, the "looks that way" was to your previous message
[09:15] <dandrader> Saviq, I didn't get any crash in the tests. but testApplication failed, but without crashing
[09:16] <Saviq> dandrader, under 5.2 on i386?
[09:16] <dandrader> Saviq,  that's with the "stable" qt5 branch on a i386 chroot
[09:16] <Saviq> dandrader, ah, stable is 5.1
[09:16] <Saviq> erm
[09:16] <Saviq> 5.2.1
[09:16] <Saviq> dandrader, maybe it was fixed between 5.2 and 5.2.1
[09:16] <dandrader> so that's good news I suppose
[09:17] <Saviq> dandrader, yeah, would be awesome to bisect and get the commit into our packages
[09:17] <dandrader> will check why testApplication is failing...
[09:30] <Cimi> mzanetti, ping :)
[09:30] <mzanetti> hi Cimi :)
[09:31] <Cimi> mzanetti, did you go any further with the exploration? is there anything you suggest ding?
[09:31] <Cimi> *doing
[09:32] <mzanetti> Cimi: did you find out if its related to that hack?
[09:32] <Cimi> nope, didn't try actually
[09:33] <mzanetti> Cimi: iirc there was some discussion lately regarding dynamically adding/removing tabs. I think the Tabs component gained support for that recently. So I'd say way to go would be to check out if that hack is actually needed any more and if removing it fixes the issue
[09:33] <mzanetti> as that's the only thing I can think of what's different in apps and unity8
[09:34] <mzanetti> maybe dednick can explain what exactly is this hack for
[09:34] <mzanetti> I didn't fully understand the bug report tbh
[09:49] <tsdgeos> https://code.launchpad.net/~aacid/unity8/verticalJournal/+merge/198897 is up if anyone wants to do some view reviewing
[09:49] <tsdgeos> Saviq: i'll do hJournal next and try to share as much code as possible with the vJournal
[09:50] <Cimi> mzanetti, it does not fix the issue
[09:53] <mzanetti> Cimi: strange
[09:54] <Saviq> tsdgeos, yup, great
[09:54] <mzanetti> Cimi: I guess at this point I would start with a new file and Tabs, and starting to build the same thing (with repeater etc) until the issue is reproducable outside of unity
[09:55] <Cimi> mzanetti, I think it might be for the loaders?
[09:55] <tsdgeos> dandrader: totally right
[09:55] <tsdgeos> dandrader: and something like what listviewwithpageheader.cpp has on the top
[09:55] <tsdgeos> explaining a bit the code won't hurt either
[09:56] <mzanetti> Cimi: Don't know... but yeah. the fact that the width is set multiple times suggests something like this
[09:58] <xnox> Saviq: tsdgeos: can we leave out policy changes from cross-compilation fixes? i.e. at the moment unity8 generates dbus code at build time, and I simply fixed it to succeed when cross-compiling.
[09:58] <xnox> Saviq: tsdgeos: changing when dbus code is generated, or stored. is not my proposal at all.
[09:59] <tsdgeos> xnox: as said it looks good to me, but i'll let Saviq be the one to decide
[09:59] <xnox> tsdgeos: cause i have tasty cmake upload which will cross-compile unity8 .... if above is merged.
[10:00] <xnox> tsdgeos: ah, looks like Saviq agrees to keep regenerating dbus code at build time.
[10:01] <Saviq> xnox, tsdgeos, yeah
[10:01] <Saviq> didrocks, good news
[10:02] <Saviq> didrocks, https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1256061
[10:02] <Saviq> didrocks, that bug is actually invalid...
[10:03] <didrocks> Saviq: oh, it's magically fixed?
[10:03] <didrocks> I'll flash latest
[10:03] <didrocks> and switch to French
[10:04] <xnox> tsdgeos: hm, jenkins gave "Needs Fixing" review, is there actually something I need to fix?
[10:04] <tsdgeos> nah
[10:05] <tsdgeos> it's some crap we need to fix
[10:05] <Saviq> xnox, some flakiness still
[10:05] <tsdgeos> really really
[10:05] <xnox> tsdgeos: ok, thanks =)
[10:07] <mhr3_> tsdgeos, something already using the vertical journal?
[10:07] <tsdgeos> mhr3_: the test :D
[10:08] <mhr3_> tsdgeos, maybe you want to hook it up with lp:~unity-team/unity8/new-scopes? ;)
[10:08] <tsdgeos> mhr3_: i just hooked it up where Saviq told me to
[10:09] <Saviq> tsdgeos, *hook* as in actually make use of it
[10:09] <Saviq> tsdgeos, mhr3_, let's get it merged into unity8 trunk
[10:09] <Saviq> tsdgeos, mhr3_ then merge trunk into new scopes, and make use of it
[10:09] <mhr3_> sure, i'm thinking step 2 already :)
[10:10] <Saviq> tsdgeos, mhr3_ oh yeah, we can go with new-scopes + vjournal in a branch already
[10:10] <Saviq> mhr3_, only we don't have variable height cards yet ;)
[10:10] <mhr3_> :(
[10:10] <Saviq> mhr3_, or a scope that gives us data that could be used for that, for that matter :P
[10:10] <mhr3_> Saviq, details :P
[10:11] <Saviq> mhr3_, I *know*
[10:12] <mhr3_> Saviq, btw json-defaults was looking for you, and there's one more branch built on top of it
[10:12] <mhr3_> fwiw those are really simple branches :)
[10:26] <Saviq> mhr3_, yeah, on my list for today
[10:34] <Saviq> didrocks, news?
[10:36] <didrocks> Saviq: flashing right now, under a tons of things :p
[10:40] <Saviq> didrocks, k
[10:47] <didrocks> Saviq: not fixed here
[10:47] <didrocks> Saviq: I move to French
[10:47] <Saviq> didrocks, rebooted?
[10:47] <didrocks> set to 19h in the system settings ui
[10:47] <didrocks> (after a reboot)
[10:47] <didrocks> and it's written 7:45
[10:47] <didrocks> for instance
[10:47] <Saviq> didrocks, but no AM/PM?
[10:47] <didrocks> no AM/PM
[10:47] <didrocks> just 7:45
[10:47] <Saviq> didrocks, let me check
[10:48] <Saviq> didrocks, ok I think I know what's happening then
[10:49] <Saviq> didrocks, the default setting is 12hr
[10:50] <didrocks> Saviq: this default setting is in unity8?
[10:50] <Saviq> didrocks, no, it's for the datetime indicator
[10:50] <Saviq> didrocks, that string comes directly from the indicator now
[10:50] <Saviq> didrocks, preformatted
[10:50] <Saviq> gsettings get com.canonical.indicator.datetime custom-time-format
[10:51] <nic-doffay> didrocks, ping
[10:51] <didrocks> Saviq: can you ensure the indicators guys are in the loop then?
[10:51] <didrocks> nic-doffay: pong
[10:51] <nic-doffay> didrocks, going to look into this: https://bugs.launchpad.net/unity8/+bug/1260379
[10:51] <didrocks> no need to ping me when I'm talking on that channel, just ask :p
[10:51] <nic-doffay> where should I start.
[10:51] <didrocks> nic-doffay: ah great!
[10:51] <Saviq> larsu, around?
[10:52] <Cimi> mzanetti, found
[10:52] <Cimi> mzanetti, line 141 of MenuContent.qml
[10:52] <mzanetti> Cimi: \o/
[10:52] <Cimi> that binding does not work
[10:52] <didrocks> nic-doffay: I would say, look at the unity8 file, ship an upstart override file with the extra shutdown period
[10:53] <Cimi> mzanetti, if you put title: "Example" at line 103 and you remove that binding, the indicator icon is rightly placed
[10:53] <mzanetti> interesting
[10:53] <Cimi> mzanetti, obviously the reason why this is causing the style to break is obscure
[10:53] <Cimi> to me
[10:54] <Cimi> mzanetti, because you get the title (the text)
[10:54] <mzanetti> Cimi: so I guess the binding does work, but because it waits for the loader.item to be loaded it overwrites width a second time which breaks the tab
[10:54] <Cimi> but breaks other bindings
[10:54] <mhr3_> Saviq, you were trying to build libunity-scopes on saucy and it failed?
[10:54] <Cimi> mzanetti, good spot
[10:54] <Saviq> mhr3_, yes
[10:54] <larsu> Saviq: yep
[10:54] <mhr3_> Saviq, do we need to fix that?
[10:54] <Saviq> mhr3_, exceptions in tests
[10:55] <Saviq> larsu, are you maintaining indicator-datetime?
[10:55] <mzanetti> Cimi: ok.. but in this case the proper fix is indeed inside the style (I'd say)
[10:55] <mhr3> Saviq, fwiw i'm running it fine on saucy
[10:55] <mhr3> but i'm building the pkg locally...
[10:55] <mzanetti> Cimi: a tab should not break if you change title at runtime
[10:56] <Saviq> mhr3, https://launchpad.net/~phablet-team/+archive/desktop-deps/
[10:56] <larsu> Saviq: no, charles is
[10:56] <Saviq> larsu, I've tracked down bug #1256061 to be, in fact, an indicator-datetime issue
[10:56] <mzanetti> Saviq: see, told ya :) (re: OSK swipe down from everywhere)
[10:56] <Saviq> mzanetti, ;P
[10:57] <Saviq> larsu, ok, will assign to him then
[10:57] <larsu> Saviq: yep, looks like it. We should fix this for real and send a time stamp...
[10:57] <Saviq> larsu, yeah, another bug
[10:57] <Saviq> larsu, I actually already have a branch that "fixed" it by ignoring what the indicator sent up completely
[10:58] <Saviq> larsu, but wasn't real happy with it, and it didn't take all the other settings into account etc.
[10:58] <larsu> Saviq: right, sending a time stamp doesn't even make sense for the current time
[10:58] <Saviq> larsu, exactly
[10:58] <larsu> what settings are those?
[10:58] <larsu> whether to show the year, 24h, etc?
[10:59] <Saviq> larsu, https://wiki.ubuntu.com/TimeAndDate?action=AttachFile&do=view&target=settings-clock.png
[10:59] <larsu> right
[11:00] <dednick> Cimi: ping
[11:00] <Cimi> dednick, pong
[11:00] <dednick> Cimi: hey, can i get you to do a review for me? https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/visual-updates/+merge/193301
[11:00] <dednick> when you have some time.
[11:00] <nic-doffay> didrocks, what am I looking for in this crash file?
[11:00] <Cimi> dednick, sure, now
[11:01] <dednick> Cimi: thanks
[11:01] <dandrader> Mirv, what's the plan for trusty regarding Qt? is our target to endup shipping 5.2 or there's no fixed target yet, meaning that it could be 5.2.1, etc?
[11:03] <Saviq> dandrader, 5.2 for sure, if 5.2.1 gets there in time - hopefully
[11:03] <didrocks> nic-doffay: what you want is to have a stop 30 in this override to let the coredump to be collected before upstart is killing it
[11:04] <Saviq> didrocks, "kill timeout 30", no?
[11:04] <didrocks> yep
[11:04] <Saviq> nic-doffay, just have a unity8.override file with that line ↑↑
[11:04] <Saviq> nic-doffay, put it in data/
[11:04] <Saviq> nic-doffay, and add a line to debian/unity8-autopilot.install
[11:05] <dandrader> it's interesting that there's already an enormous diff between qtdeclarative release (5.2) and stable (5.2.1)
[11:05] <Saviq> nic-doffay, to install that .override file into /usr/share/upstart/sessions
[11:05] <Saviq> dandrader, yeah indeed
[11:05] <Saviq> didrocks, unless there's a better place to put it in ↑↑?
[11:06] <didrocks> Saviq: no, thats perfect
[11:09] <nic-doffay> Saviq, right will get going with that then.
[11:10] <Saviq> does anyone else's right-mouse-button get crazy sometimes and does a click as soon as you move the mouse, without you releasing it?
[11:11] <Saviq> like it creates a new folder on-right-click for me, instead of opening the menu :/
[11:11] <Saviq> it does that for a minute at a time and then goes back to normal
[11:11] <Saviq> mhr3, with https://code.launchpad.net/~michihenning/unity-scopes-api/what-for-exceptions/+merge/198872 there will be some actual useful output in the build log
[11:12] <mhr3> Saviq, yea, just got a mail from michi about that branch
[11:12] <dandrader> Saviq, working fine on my desktop
[11:12] <Saviq> dandrader, yeah, I'm not sure if it's my mouse, or the touchpad playing games...
[11:43] <Mirv> dandrader|lunch: as saviq said, 5.2.x is the target for sure. the focus is on 5.2 + backported patches for now.
[11:55] <nic-doffay> Saviq, how should I test for this now?
[12:00] <Cimi> guys, we should fix the scrolling...
[12:00] <Cimi> of flickable
[12:01] <Cimi> velocity and deceleration
[12:01] <Cimi> it's broken on the desktop and on the devices
[12:09] <Saviq> Cimi, filed a bug yet?
[12:10] <Mirv> phew, so much to do... (with Qt 5.2)
[12:10] <Saviq> Mirv, between rc1 and release?
[12:11] <Saviq> nic-doffay, with unity running, go:
[12:11] <Saviq> kill -11 `pidof unity8`; stop unity8
[12:12] <Saviq> nic-doffay, stop unity8 should return after more than 5s
[12:12] <Mirv> Saviq: not really between those, but doing this correctly instead of ad-hoc. symbols updates for all archs (multiple builds), syncing with Debian, rebuilding everything after noticing Debian did now do the qt5core lib rename, patches coming from all directions for enabling tests etc (which should be then contributed back to Debian also at some point)
[12:13] <Saviq> Mirv, right, so basically the real packaging
[12:13] <Mirv> Saviq: so I thought today I would make progress, instead I find myself being back to near beginning with 5.2 final build :)
[12:14] <Cimi> Saviq, I need to test again on my galaxy nexus, but it's definitely broken in the desktop
[12:14] <Mirv> but of course progress made reducing delta, going through changes etc
[12:14] <Cimi> Saviq, try flicking on the sdk components gallery
[12:14] <Cimi> Saviq, it's like crazy :)
[12:15] <Cimi> actually now works
[12:15] <Cimi> :-\
[12:16] <Saviq> Cimi, yeah, seems fine in the pickers
[12:16] <Cimi> Saviq, it's fine now for me
[12:16] <Cimi> Saviq, was badly broken yesterday
[12:16] <Cimi> Saviq, like over scrolling with no limits
[12:18] <Cimi> Saviq, can I test qt 5.2 on maguro?
[12:18] <Saviq> Cimi, you could try
[12:18] <Saviq> Cimi, ppa:canonical-qt5-edgers/qt5-beta2
[12:19] <Saviq> Cimi, but it's probably better to wait a bit
[12:19] <Cimi> Saviq, I wanted to try the scrolling
[12:19] <Saviq> Cimi, it's all in flux now that 5.2 was released finally
[12:19] <Saviq> Cimi, I don't think anything changed tehre
[12:19] <Cimi> Saviq, was broken in all our previous versions
[12:20] <Cimi> Saviq, try seeing the default velocity of the flickable
[12:20] <Saviq> Cimi, and it all basically deserves a QTBUG that the default values are a) pixel-dependent and b) not customizable without rebuilding Qt
[12:20] <Cimi> Saviq, it was 1500 iirc, should be much higher with high dpi
[12:20] <mzanetti> I have a weird issue right now... I cannot drag (flick) any scope upwards unless I pull it down a little beforehand
[12:21] <mzanetti> is that known?
[12:21] <Saviq> Cimi, https://qt.gitorious.org/qt/qtdeclarative/source/e895bc315f9959a5dad80a8f0bf7b73bced0bde1:src/quick/items/qquickflickable.cpp#L61
[12:21] <Saviq> mzanetti, no
[12:21] <Saviq> mzanetti, phone?
[12:22] <mzanetti> yeah
[12:23] <Saviq> nic-doffay, so the real test there is to see that the package built and the file gets installed into /usr/share/upstart/sessions/
[12:23] <Saviq> nic-doffay, if it is - that's all we can do TBH
[12:23] <nic-doffay> Saviq, killing it from a separate console has strange results.
[12:24] <nic-doffay> Unity8 jus segfaults.
[12:25] <Saviq> nic-doffay, that's what -11 does
[12:25] <Saviq> nic-doffay, that's SIGSEGV
[12:26] <Saviq> nic-doffay, but anyway - more real-life test
[12:26] <Saviq> hmm crap
[12:26] <nic-doffay> Saviq, getting this too: stop: Unknown job: unity8
[12:26] <Saviq> nic-doffay, as phablet
[12:27] <nic-doffay> Saviq, so run on device then run as phablet user.
[12:27] <Saviq> nic-doffay, man, run on device won't do you any good
[12:28] <Saviq> nic-doffay, that file will only get installed where it needs to when packaged
[12:28] <Saviq> nic-doffay, run_on_device doesn't install anything
[12:28] <nic-doffay> Saviq, what's the deal with stop: Unknown job: unity8
[12:28] <Saviq> nic-doffay, you're not logged in as phablet, most likely
[12:29] <Saviq> nic-doffay, or you managed to uninstall unity8
[12:29] <nic-doffay> Saviq, the former then.
[12:29] <Cimi> Saviq, that's bad
[12:30] <Saviq> Cimi, you've been complaining about this for what, half a year now?
[12:30] <Saviq> Cimi, did you file a bug?
[12:30] <Cimi> nope
[12:31] <Cimi> I'm a lazy guy (my main flaw) and not registered yet to qt bugs
[12:31] <Cimi> I'm going to to this today and I will be digia's worst nightmare
[12:31] <Cimi> perfectly in time for Friday the 13th
[12:33] <Saviq> nic-doffay, just file the merge proposal
[12:33] <tsdgeos> Saviq: ok i think i know why that test_show_scope_on_load is failing
[12:33] <Saviq> nic-doffay, we'll know soon enough whether it's correct
[12:33] <Saviq> tsdgeos, pray tell
[12:33] <tsdgeos> Saviq: now i want to know if i change the test of the code :D
[12:34] <nic-doffay> Saviq, yeah was trying to avoid that though!
[12:34] <tsdgeos> let me to a pastebin explaining
[12:34] <Saviq> nic-doffay, it's this kind of change
[12:34] <Saviq> nic-doffay, to test for real you'd have to make unity8 crash on exit
[12:35] <Saviq> nic-doffay, which isn't difficult, btw, if you want - it's just a case of tweaking the main() to not destroy the view or the application, but return application->exec() straight away
[12:35] <Saviq> nic-doffay, then, without your .override file, upstart will kill unity8 before apport's managed to collect the full crash report
[12:35] <Saviq> nic-doffay, with it, upstart will wait for up to 30s (as opposed to 5s) before killing
[12:36] <Saviq> nic-doffay, giving time for apport to collect the crash file
[12:36] <nic-doffay> Saviq, I'll give that a go while waiting for jenkins.
[12:37] <Saviq> nic-doffay, you can do 'stop unity8; start unity8 BINARY=$PWD/builddir/unity8' to launch the locally built unity8 under upstart
[12:37] <nic-doffay> Saviq, cool thanks
[12:37] <Saviq> nic-doffay, having built it first with run_on_device, and logging in as phablet, unity8 is built in /home/phablet/shell/builddir/unity8
[12:38] <Saviq> nic-doffay, and BINARY=... just tells upstart to launch that binary instead of the system-installed one
[12:38] <tsdgeos> damn it's hard to write the thoughts down
[12:41] <tsdgeos> Saviq: actually no, scrap that, can't tell :-/
[12:41] <tsdgeos> but i'm going to add a hell lot of console.log and will find out
[12:41] <Saviq> tsdgeos, maan :/
[12:41] <tsdgeos> i'm tired of all those errors
[12:41] <Saviq> tsdgeos, please do
[12:41] <Saviq> tsdgeos, +1
[12:57] <dednick> Saviq: did we decide we would pass https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 ?
[12:57] <Saviq> dednick, I'm still not really sure what it's supposed to fix ;D
[12:59] <Saviq> dednick, but then we decided that the indicators should just put up timestamps (in case of non-current time) or nothing at all (in case of current time), and users' preferences should be applied globally by applied globally by new SDK component(s) - TimeFormatter and RealTime or so
[12:59] <Saviq> dednick, so unless that branch actually fixes something that I'm not aware of, I'd reject it
[12:59] <dednick> Saviq: right, but thats a todo later right...
[12:59] <dednick> Saviq: it's for the datetime alarm menu items.
[12:59] <Saviq> dednick, ah, ok
[13:00] <Saviq> dednick, can we see them already?
[13:00] <Saviq> dednick, like if I add an event in my calendar, will they show up?
[13:00] <dednick> "you can see them", but there are no times.
[13:00] <Saviq> dednick, which that branch is supposed to fix, correct?
[13:01] <mhr3> Saviq, ok with exposing the raw json in the category models purely for the dev-tool usage?
[13:02] <dednick> Saviq: um. it will, when we have an event item :)  It's in ubuntu-settings-components. Currently we're just using the standard item (no time).
[13:02] <Saviq> dednick, so still no way to see the fix, eh? ;)
[13:03] <dednick> nope. but this branch also moves the formatter into Utils :)
[13:13] <dednick> Saviq: oh, and my indicator tests branch is done. :) https://code.launchpad.net/~nick-dedekind/unity8/indicator-page-factory-tests/+merge/198785
[13:13] <Saviq> dednick, yup, saw that
[13:21] <Saviq> dednick, and ohkay, if you twist my arm... can you just add a TODO/FIXME somewhere where it makes sense, and refer to bug #1260728
[13:21] <dednick> Saviq: :) ok
[13:21] <Saviq> xnox, so does that mean that with the new cmake upload and the unity8 branch, we'll be able to cross-build directly? :)
[13:23] <xnox> Saviq: yes, along with pleora of other packages. =))) one time setup: mk-sbuild --target armhf, and after that it's just $ sbuild -A --host armhf unity8*.dsc
[13:23] <Saviq> xnox, YUMMY
[13:23] <Saviq> xnox, do you know if distcc should work fine when cross-building? ;)
[13:24] <xnox> Saviq: once qt*-dev stack is co-installable it will be possible to even do it without a chroot with: dpkg-architecture -aarmhf -c cmake ../ && make
[13:24] <Saviq> xnox, I know ccache does work fine
[13:24] <xnox> Saviq: why do I need distcc, or ccache if it takes 2m20s to cross-compile unity8 clean from start to finish?
[13:25] <Saviq> xnox, nice one, we'll have to transition our run_on_device script to that :)
[13:25] <Saviq> xnox, right, it's much simpler recently ;)
[13:25] <Saviq> xnox, but then I'm thinking of moving to an ultrabook at some time in the near future, will not get the quad-core thing I have now ;)
[13:25] <xnox> Saviq: .... cross-building happens on amd64/i386 which is fast and multi-core (typically) so simply DEB_BUILD_OPTIONS=parallel=12
[13:25] <Saviq> xnox, yeah -j9 is my default
[13:25] <dednick> Saviq: done. i just put it in the Timeformatter header.
[13:26] <Saviq> dednick, cheers
[13:26] <Saviq> xnox, and well, it's not just about unity8, I actually compile other things as well ;)
[13:26] <xnox> Saviq: you do want to set it via DEB_BUILD_OPTIONS or even specifically in ~/.sbuildrc $build_environment {'DEB_BUILD_OPTIONS' => 'parallel=9'}
[13:27] <Saviq> xnox, I barely do anything else than bzr bd, which does have sbuild -j9 as the builder
[13:27] <Saviq> xnox, when building packages, that is
[13:27] <xnox> Saviq: right. so the only requirement is that distcc / ccache generates / replaces $DEB_HOST_GNU_TYPE-[gcc|g++]
[13:27] <xnox> Saviq: cause that's the compiler that cmake will pick when cross-compiling.
[13:27] <Saviq> xnox, yeah, I thought it *should* work in theory
[13:28] <Saviq> xnox, will do some testing
[13:28]  * xnox has no need though =)
[13:28] <xnox> I have 8 core, 32GB of RAM, and I compile in tmpfs with no iowait ;-)
[13:32]  * dandrader makes a mental note that "good" and "bad" in git bisect mean the other way round when you're looking for the commit that fixes something
[13:35] <Saviq> xnox, well, I'm 4 core HT, 8GB RAM and compile in shm, too (and SSD to boot)
[13:35] <Saviq> xnox, but as I said, am thinking of moving to an ultrabook, at which point I'd like to offload some of that umph ;)
[13:35] <davmor2> xnox: man that is an awesome phone :D
[13:35] <seb128> Saviq, larsu: so the timestamp issue is back on the indicator side?
[13:36] <Saviq> seb128, yeah
[13:36] <xnox> davmor2: =))))) not very portable, and battary UPS only lasts 10m
[13:36] <Saviq> seb128, it's a string straight from indicator-datetime
[13:36] <Saviq> seb128, I did fix it unity8-side, by ignoring what that string says at all, but didn't like the solution for now
[13:36] <Saviq> seb128, bug #1260728 to fix it long-term
[13:36] <seb128> Saviq, ok, thanks
[13:37] <xnox> Saviq: right. I made my machine ssh accessible and my terminal on my ultrabook has gnome-terminal with the following shell set $ ssh -X mydesktop.IP
[13:37] <seb128> Saviq, that's different from the messaging menu one, right?
[13:37] <Saviq> seb128, yeah, that's fixed in u8 trunk
[13:37] <seb128> cool
[13:37] <Saviq> seb128, and released already, btw
[13:37] <seb128> Saviq, good to read ;-)
[13:38]  * seb128 didn't keep up with what was going on this week, just too much stuff changing ;-)
[13:38] <Saviq> seb128, yeah, but it's a good problem to be had :)
[13:38] <seb128> indeed
[13:39] <dednick> larsu: howdy. Do you know why are all the messaging menu items "not sensitive"
[13:40] <Saviq> mpt, hey, q: looking at https://wiki.ubuntu.com/TimeAndDate, there are settings for the clock on the desktop, but not on phone - is that on purpose? would kind-of mean that you can change those when your phone is docked, and it should affect your phone, but you don't get to change those settings on the phone?
[13:41] <Saviq> mpt, or the other way - you can change it on the desktop, but that doesn't affect your phone clock?
[13:41] <Saviq> mpt, also, those settings are *only* meant to affect the indicator? no way for users to select 24h clock under British English, for example?
[13:41] <Saviq> globally, that is
[13:42] <Saviq> mpt, it'd be pretty weird if you ask me, if you chose your clock to be 24h, but it would only affect the indicator and not the rest of the system...
[13:43] <Saviq> mhr3, for https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591
[13:44] <Saviq> mhr3, what I did in JavaScript, and was thinking you'd do as well, is work the other way - parse a JSON file with defaults, and update the values based on data coming from the scope
[13:45] <Saviq> mhr3, your way involves adding lotsa code just to add a new key with a default for any component/template
[13:47] <Saviq> marcusto_, hey, did you have a chance to look at http://json-schema.org/ ?
[13:48] <Saviq> mhr3, oh, and on that note... should those defaults not be applied server-side?
[13:49] <marcusto_> Saviq: hey, yeah I did, and it looks like this lib fits our needs quite well: http://avro.apache.org/docs/1.6.3/api/cpp/html/
[13:49] <Saviq> marcusto_, oh, awesome
[13:50] <marcusto_> Saviq: problem is, until I get something running I'm holding up the web guys on SSS
[13:50] <Saviq> marcusto_, I'm not pushing - was just wondering if json-schema is still something we can plan for
[13:50] <Saviq> marcusto_, hmm, avro has it's own schema does it?
[13:52] <Saviq> mhr3, hmm did I answer your question about exposing raw json for dev-tool? if not - I'd *rather* not in the long run, since we'll have a side-channel for talking to the scope backend directly, could we not get it through there?
[13:53] <marcusto_> Saviq: I've looked at this briefly, but it looks like standard schema. Its def on the todo list
[13:54] <Saviq> marcusto_, it doesn't seem to mention any relation to json-schema.org
[13:54] <Saviq> marcusto_, and looking briefly it does differ slightly (that's not to say it's worse, or bad, for that matter)
[13:55] <Saviq> marcusto_, but it definitely seems less standardized
[13:55] <Saviq> if something that's non-standardized can be even less standardized...
[13:55] <marcusto_> Saviq: hmmm, ok, clearly I have not thought about this enough :p
[13:55] <Saviq> marcusto_, ;)
[13:56] <Saviq> marcusto_, no worries
[13:56] <marcusto_> Saviq: yeah, resources are few
[13:56] <Saviq> marcusto_, we're not blocked on it, it's only a it-would-be-nice-to-have-when-possible type of situation ;)
[13:56] <Saviq> marcusto_, but no worries, we have plenty to do regardless
[13:57] <marcusto_> Saviq: well we are planning on schema validation, just a matter of time
[13:57] <Saviq> marcusto_, yup, great
[14:07] <mpt> Saviq, it’s somewhat on purpose, because there is much more screen real estate for variations on the PC.
[14:07] <mpt> Saviq, but I haven’t thought through what happens when you dock a phone.
[14:08] <mhr3> Saviq, i'm not sure what side-channel you mean
[14:08] <mhr3> Saviq, ultimately it's just exposing it to qml, i don't see any harm in that
[14:08] <mpt> Saviq, I talked about having a locale-independent 24-hour option on Tuesday with … with you, actually.
[14:08] <Saviq> mpt, yeah, that's why I'm asking - 'cause there isn't a setting for it :)
[14:09] <Saviq> mhr3, the one that will let us "upload" a modified JSON string for a category
[14:09] <mhr3> Saviq, that will be internal to the shell, it won't talk to the scope
[14:09] <Saviq> mhr3, otp, back in 0.5h or so
[14:09] <mhr3> Saviq, right, let's hangout afterwards
[14:09] <Saviq> mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591/comments/461511 in the mean time
[14:10] <mhr3> thx
[14:11] <mpt> Saviq, I think the overall setting would go in “Language & Text” (along with settings for decimal places, thousand separators, etc), but with a cross-reference from “Time & Date”.
[14:11] <Saviq> mpt, yup, sounds good
[14:12] <Saviq> mpt, if you didn't see me saying yesterday, MeeGo I think got it right, by allowing you to select:
[14:12] <Saviq> language, format-locale, and 12 vs. 24hr clock
[14:13] <Saviq> format-locale including number format, currency format etc.
[14:13] <Saviq> mpt, feels like a well-balanced solution
[14:17] <larsu> dednick: no, I don't. When did that start?
[14:19] <tsdgeos> dandrader: can you read http://bazaar.launchpad.net/~aacid/unity8/verticalJournal/revision/596 and see if it gives you enough info on what it is supposed to do?
[14:20] <dandrader> tsdgeos, sure
[14:20] <tsdgeos> dandrader: it gives it to me, but i know what it's supposed to do so i don't obviously count :D
[14:22] <nic-doffay> Saviq, I haven't gotten around to testing the branch yet.
[14:22] <nic-doffay> What was wrong with it?
[14:23] <Saviq> nic-doffay, it doesn't actually package the file
[14:23] <dandrader> tsdgeos, "The number of rules is calculated[...]" <- number of *rules*?
[14:23] <tsdgeos> lol
[14:23] <tsdgeos> rows
[14:23] <dandrader> tsdgeos, columns?
[14:24] <tsdgeos> that
[14:24]  * tsdgeos slaps himself
[14:24] <dandrader> hehehe
[14:25] <tsdgeos> dandrader: ok r597 fixes the typo and adds a bit more of info
[14:25] <dandrader> tsdgeos, also, why is the documentation in the class instead of in the header?
[14:25] <dandrader> s/class/cpp
[14:25] <tsdgeos> dandrader: because it''s what e had for listviewwithpageheader.cpp
[14:25] <tsdgeos> but yeah it's weird
[14:25] <tsdgeos> also lvwph.cpp is more about internal
[14:26] <tsdgeos> and the first part of this is more about external
[14:26] <tsdgeos> maybe i can split this one into two?
[14:26] <tsdgeos> so "The implementation is centered around m_columnVisibleItems" and after is on the .cpp and the rest in the .h?
[14:27] <dandrader> yeah, in the .h I would say "what it is" and in the .cpp I would put the comments about "how it's done"
[14:28] <dednick> larsu: no idea. I just added enable item by sensitivity and it stopped responding to clicks.
[14:29] <tsdgeos> dandrader: splitted
[14:31] <tsdgeos> Saviq: mzanetti: greyback: standup?
[14:32] <Saviq> tsdgeos, otp again
[14:32] <greyback> tsdgeos: same for me
[14:32] <Cimi> mzanetti, notes
[14:33] <larsu> dednick: is the service reporting disabled actions? Or is it something in qmenumodel?
[14:33] <dednick> larsu: looks like it's in qmenumodel. the can_activate is false for the menu item actions.
[14:35] <dednick> larsu: because action_target is null, but parameter_type is not.
[14:35] <dednick> larsu: same old story
[14:35] <dednick> !
[14:36] <larsu> dednick: ah right. Didn't we fix this back when we first found it?
[14:36] <larsu> apparently not :)
[14:36] <dednick> larsu: i thought so :)
[14:36] <dednick> larsu: been fixed in a few places
[14:37] <larsu> dednick: I'll make the service put a target on there, that will be easiest
[14:37] <larsu> because we want to keep the logic for "normal" menu items
[14:43] <codebrainz> hi. is there a way to have a program added to a blacklist or something to opt-out of the GTK+ menu stealing thing?
[14:43] <codebrainz> the global menu or libdbusmenu or whatever it's called
[14:44] <tsdgeos> yes there is
[14:44] <tsdgeos> at least there's an envvar
[14:44] <tsdgeos> but i don't remember it :D
[14:44] <tsdgeos> <--- not useful
[14:45] <codebrainz> yeah, that's what we tell all the bug reporters, but it'd be cool to opt out at the distro level
[14:45] <tsdgeos> Saviq: obviously all the runs wiht more logs are now passing :D
[14:45] <codebrainz> to avoid the continuous stream of bug reports about our main menu, which isn't really our main menu :)
[14:45] <Saviq> tsdgeos, hit it again!
[14:45] <tsdgeos> i am
[14:45] <tsdgeos> re-running only the qmluitests instead of the whole thing
[14:45] <tsdgeos> for faster turnaround
[14:46] <Saviq> tsdgeos, yup
[14:47] <codebrainz> maybe on ubuntu we could install a script along with the binary and have the script clear UBUNTU_MENUPROXY before calling the real binary?
[14:47] <Saviq> codebrainz, is there a reason for this particular app to opt-out from globalmenu?
[14:48] <codebrainz> Saviq, tons of bug reports to our project not caused by our project
[14:48] <Saviq> codebrainz, caused by the global menu integration?
[14:49] <codebrainz> yes
[14:49] <Saviq> codebrainz, can you forward the bugs to the project that causes them, so that it's fixed instead of disabling it?
[14:49] <codebrainz> we do, but quite frankly it's super annoying and not very cool to mess with an app that others have to support :)
[14:50] <codebrainz> none of our devs use unity, we only test/support normal GTK+
[14:50] <tsdgeos> Saviq: yeah the code is not really awesome, for example in kate if you do "Alt" it shows the menu but then if you press the accelerator (i.e. Alt+F) you get the F written in the text area instead of popping-up the file menu
[14:50] <tsdgeos> i fixed that already last year
[14:50] <tsdgeos> and somehow it broke again
[14:50] <tsdgeos> not cool :D
[14:50] <tsdgeos> and last year is was less busy than now
[14:51] <tsdgeos> that helped finding a time to fix it
[14:52] <Saviq> codebrainz, dunno, don't see that as a reason to disable it, rather a reason to make it more obvious to people reporting bugs against the upstream project that they should report it against ubuntu instead
[14:53] <codebrainz> Saviq, that's highly optimistic
[14:54] <codebrainz> I wonder if we could put the main menu bar inside another GtkBox to break the heuristics used to steal the menu from the window?
[14:54] <Saviq> codebrainz, who does the packaging for ubuntu, btw, and - what's the project, btw?
[14:54] <tsdgeos> codebrainz: i guess the "easiest" for you is setting that envvar as the first thing in your main.cpp?
[14:54] <tsdgeos> if you really really really really want to disable it
[14:54] <codebrainz> I'm not sure setting the envvar from main() would do it, would it?
[14:54] <codebrainz> Saviq, the app is Geany
[14:55] <codebrainz> hyperair is the packager AFAIK
[14:55] <tsdgeos> codebrainz: i'd say it would, but not sure tbh
[14:56] <codebrainz> tsdgeos, it might, if set before gtk_init() actually
[14:57] <Saviq> codebrainz, I dunno, if people use the apport to report bugs on ubuntu, they will get to the ubuntu project first
[14:57] <codebrainz> they use our bug tracker
[14:57] <codebrainz> some do anyway
[14:57] <Saviq> codebrainz, I really don't feel like that's the right solution to the problem
[14:57] <Saviq> codebrainz, feels short-sighted
[14:58] <codebrainz> Saviq, stealing the menu from an app with a hack, is *definitively* not the right solution :)
[14:58] <Saviq> codebrainz, yeah, I know Ubuntu/Unity/Canonical is evil
[14:58] <Saviq> that's established
[14:58] <codebrainz> no no, I rather like Ubuntu, I use Xubuntu myself
[14:58] <codebrainz> I just hate this hack because it does something evil
[14:59] <Saviq> codebrainz, it's a design decision, and at that time it was the only way to apply it
[14:59] <Saviq> codebrainz, with gtk2 it still is, afaik, and with gtk3 is better, iirc?
[14:59] <codebrainz> I can only hope it is
[14:59] <codebrainz> we don't have full/proper gtk3 support yet
[14:59] <Saviq> codebrainz, I think it's basically a first-class concept that the menu is exported
[15:00] <Saviq> codebrainz, to support MacOS, for example
[15:00] <mhr3> Saviq, got time for the hangout?
[15:00] <Saviq> mhr3, right, forgot to ping you
[15:00] <Saviq> mhr3, sure
[15:00] <mhr3> let's do it then
[15:00] <codebrainz> Saviq, the gtk3 way seems OK, but the dbusmenu hack thing is just plain wrong IMO
[15:01] <Saviq> codebrainz, again, only way to apply the design decision that was made
[15:01] <Saviq> codebrainz, we'd have done it otherwise if was possible
[15:01] <Saviq> and we did, with gtk3, with qt etc.
[15:01] <codebrainz> Saviq, just because you did it the only way possible doesn't make it any cooler :)
[15:02] <Saviq> codebrainz, sure it does, because *we did it* ;)
[15:02] <Saviq> codebrainz, instead of saying it's impossible
[15:02] <codebrainz> Saviq, it was impossible to do it right, hence all the bug reports :)
[15:02] <tsdgeos> E_NOT_CONSTRUCTIVE_DISCUSSION
[15:03] <seb128> codebrainz, it's working pretty well, there is like 10 apps that are known to not be working correctly and they are mostly doing weird stuff
[15:04] <codebrainz> our app doesn't do "weird" stuff, but it does load stuff dynamically into the menus
[15:05] <seb128> codebrainz, what app are we talking about?
[15:05] <codebrainz> I wonder is there a way we could detect the UI changes taking place with a widget signal and pop up a one-time dialog warning the user what is happening and where to report bugs?
[15:05] <codebrainz> seb128, geany
[15:06] <seb128> codebrainz, ok, we have https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1072109 about that it seems
[15:10] <codebrainz> seb128, there's more than that (especially on our tracker)
[15:11] <larsu> dednick: that should fix it: https://code.launchpad.net/~larsu/indicator-messages/set-targets/+merge/198957
[15:11] <dednick> larsu: cool. will give it a quick test
[15:11] <seb128> codebrainz, you should open a bug with the specific, and maybe talk to "attente" in #ubuntu-desktop to see if he can help you to get those fixed (if not there is a blacklist, he can add geany to it)
[15:13] <codebrainz> seb128, it's hard enough to support own bugs though, we can't be proxying all of appmenu's bugs because it proxies our menu :)
[15:14] <codebrainz> but if the gtk3 way is less crazy, I could try and convince the team to start supporting that :)
[15:16] <seb128> codebrainz, well, the gtk3 way works with less crazyness/hacks yes
[15:16] <codebrainz> hmmm, maybe we could put a dialog message on our "Report a Bug" help menu item if ubuntu is detected, asking them to use ubuntu's builtin bug reporter?
[15:17] <seb128> codebrainz, with traditional menus we need to do hacks to export parse the menus/export them, where gtk3 gmenus does it by itself
[15:17] <nic-doffay> Saviq, do I specifically need to install the override in autopilot install or is adding the path sufficient?
[15:17] <dednick> larsu: cheers, worked.
[15:18] <larsu> dednick: cool
[15:18] <codebrainz> seb128, yeah I remember looking at the code last year when I submitted a patch to fix an issue on one of the bugs (which AFAIK still hasn't been applied)
[15:18] <seb128> codebrainz, do you have a link to the patch?
[15:18] <codebrainz> i can probably find it, one sec
[15:19] <codebrainz> https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/907635
[15:20] <codebrainz> (the patch just fixes a harmless GTK-critical message, but it's still useful to avoid console spam, if it still applies)
[15:21] <codebrainz> well, it's harmless as long as the program isn't run without assertions :)
[15:22] <seb128> codebrainz, oh, the bug has expired (and it's usually better to file merge proposal) ... in any case we don't use libdbusmenu anymore for the appmenu stuff (only in some specific cases and we are cleaning those out)
[15:22] <codebrainz> seems like users' bug reports showing the console output still shows this critical warning
[15:22] <codebrainz> (often for unrelated bugs)
[15:23] <seb128> they might still run the lts?
[15:23] <codebrainz> it's possible
[15:23] <dednick> Saviq: do we still need to deal with seeds for phone for unity8 dependencies, or is it sorted by the deps?
[15:23] <seb128> tedg, do you think you could review the null check patch on this bug ^
[15:23] <seb128> tedg, https://launchpadlibrarian.net/91512767/libdbusmenu-null-submenu.patch
[15:23] <dednick> Saviq: oh, i think we only needed seeds if there wasn't a dep right?
[15:24] <tedg> seb128, Sure, can you give me the bug number?  (can't seem to get back to there)
[15:24] <tedg> Ah, I see.
[15:25] <seb128> tedg, 907635
[15:25] <codebrainz> for rationale, see: https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#gtk-menu-item-set-submenu
[15:27] <Saviq> dednick, yeah, debian/control is the way to go
[15:28] <Saviq> dednick, it's like: nothing else would depend on unity8, so ubuntu-phone seed depends on it
[15:28] <Saviq> dednick, but for anything else, standard deps are good
[15:28] <didrocks> Saviq: we still have 2 flacky unity8 tests I guess
[15:28] <didrocks> http://ci.ubuntu.com/smokeng/trusty/touch/maguro/64:20131213.1:20131211.2/5443/unity8-autopilot/
[15:28] <dednick> Saviq: cool
[15:28] <codebrainz> seb128, here's the latest bug, not sure it'll get reported to the proper place: https://sourceforge.net/p/geany/bugs/1013/
[15:29] <codebrainz> it's parsing underscores in filenames as mnemonics
[15:30] <Saviq> nic-doffay, how is dpkg supposed to know where to install that file?
[15:30] <nic-doffay> Saviq, what's the purpose of this? usr/lib/python*/*/unity*
[15:31] <nic-doffay> Saviq, I don't know enough about how all this fits in the bigger picture to properly tackle this.
[15:31] <nic-doffay> It's that simple really.
[15:33] <seb128> codebrainz, could you open a bug about that on https://launchpad.net/ubuntu/+source/unity-gtk-module/+filebug ?
[15:33] <alesage> hi I'm getting a ./build error on "Could not determine plugin installation dir.", can someone suggest a remedy? http://paste.ubuntu.com/6567242/
[15:33] <Saviq> alesage, ./build -s
[15:33] <alesage> Saviq, thx
[15:33] <Saviq> alesage, you don't have new libunity-api-dev installed
[15:33] <Saviq> alesage, or ./build -c, for that matter
[15:34] <alesage> Saviq, ok will investigate
[15:34] <codebrainz> seb128, hopefully the bug reporter will
[15:34] <seb128> codebrainz, you could also do it if you want to help your users... ;-)
[15:35] <codebrainz> I don't remember my launchpad login, that patch I submitted was likely the first/last time I used it :)
[15:35] <codebrainz> I can try though, and just link to the source forge bug
[15:35] <codebrainz> (I'm not affected as I use xfce panel)
[15:36] <seb128> codebrainz, I've pinged the maintainer in #ubuntu-desktop, I'm sure a bug would still be useful though
[15:36] <codebrainz> seb128, can you tell me what email address is associated with my account?
[15:37] <codebrainz> it won't show me unless I'm logged in
[15:37] <codebrainz> (I have like 50 email addresses)
[15:37] <seb128> codebrainz, @geany.org
[15:37] <Saviq> nic-doffay, http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
[15:37] <codebrainz> seb128, thanks
[15:37] <seb128> codebrainz, yw
[15:38] <Saviq> nic-doffay, so you need:
[15:38] <Saviq> data/unity8.override usr/share/upstart/sessions
[15:38] <Saviq> or so
[15:38] <nic-doffay> Saviq, yeah that's what the manual seems to say, ta.
[15:40] <codebrainz> seb128, what project/component would that bug go against?
[15:40] <codebrainz> appmenu-gtk?
[15:41] <seb128> codebrainz, could you open a bug about that on https://launchpad.net/ubuntu/+source/unity-gtk-module/+filebug ?
[15:41] <codebrainz> heh, sorry, i missed that the first time :)
[15:57] <codebrainz> seb128, https://bugs.launchpad.net/ubuntu/+source/unity-gtk-module/+bug/1260777
[15:57] <codebrainz> heh
[15:57] <codebrainz> thanks bot
[15:57] <seb128> codebrainz, thanks
[15:58] <codebrainz> np, it actually sounds like an unsolvable issue
[16:03] <Cimi> people don't like my branch? https://code.launchpad.net/~cimi/unity8/searchIndicator-swipe/+merge/198258
[16:03] <seb128> codebrainz, why?
[16:05] <codebrainz> seb128, how could the module know whether an item happened to be created by the constructor that parses mnemonics?
[16:05] <codebrainz> I don't think it can tell, and it can't assume all menu items were
[16:05] <codebrainz> unless there is a flag/property on the menu items or something, not sure
[16:06] <seb128> codebrainz, I don't know that code well, but I think those stuff were working with libdbusmenu, so it should be doable
[16:06] <seb128> codebrainz, let's trust the guys working on that code and see what they come with ;-)
[16:07] <codebrainz> ah yeah, there is: https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#GtkMenuItem--use-underline
[16:08] <codebrainz> so it's totally doable
[16:10] <Saviq> nic-doffay, I *think* you need absolute path in the .install file there
[16:10] <Saviq> or, didrocks, can you look at the .install file change in https://code.launchpad.net/~nicolas-doffay/unity8/upstart-kill-fix/+merge/198931
[16:11] <Saviq> nic-doffay, ah it's still missing data/unity8.override in the .install file
[16:11] <Saviq> didrocks, unping
[16:11] <nic-doffay> Saviq, just pushed it now.
[16:11] <nic-doffay> I was wondering about an abs path though, but we'll see.
[16:12] <Saviq> nic-doffay, relative is correct
[16:12] <Saviq> nic-doffay, see debian/unity8.install
[16:30] <dednick> Cimi: fixed review comments
[16:36] <seb128> codebrainz, I guess you commented on the wrong bug (https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/1260779)?
[16:40] <codebrainz> seb128, totally, I had too many bugs open
[16:40] <codebrainz> can i delete it?
[16:41] <seb128> codebrainz, no, but don't worry about it (or just post a new comment saying "sorry, wrong bug")
[16:45] <Cimi> Saviq, my first qt bug report <3 https://bugreports.qt-project.org/browse/QTBUG-35608
[16:45] <Saviq> Cimi, ;)
[16:45] <Saviq> Cimi, file another one that it's not easily customizable
[16:45] <Saviq> Cimi, separatet
[16:45] <Saviq> -t
[16:46] <Cimi> Saviq, ok
[16:46] <Cimi> the voice "create issue" is fun
[16:46] <Cimi> should be file bug imho :D
[16:46] <Cimi> but let's create an issue :D
[16:48] <Cimi> Saviq, but how would you address the latter?
[16:48] <Cimi> Saviq, why would you want to change *all* values?
[16:48] <Cimi> Saviq, if the default value is sane you don't want to customise it
[16:52] <Cimi> Saviq, I'm waiting your input
[17:00] <Cimi> well filed the second https://bugreports.qt-project.org/browse/QTBUG-35609
[17:00] <Cimi> although I'm not 100% convinced if the first gets fixed
[17:28] <Cimi> dednick, hey dude
[17:28] <Cimi> dednick, the comment i wrote
[17:29] <Cimi> dednick, I have qt 5.2
[17:29] <Cimi> I believe it's thrown because of the new JS engine
[17:31] <dednick> Cimi: hm. give me a sec
[17:31] <Cimi> dednick, or let's do this next week :P
[17:31] <Cimi> dednick,             tryCompare(function() { signalSpyDismiss.count > 0; }, true);
[17:31] <Cimi> :-\
[17:32] <dednick> Cimi: no return maybe...
[17:32]  * Cimi tries
[17:32] <dednick> but succeeds for me, which is a bit odd
[17:33] <Cimi> dednick, no luck for me
[17:33] <Cimi> dednick, which qt?
[17:33] <dednick> 5.0.2
[17:33] <Cimi> dednick, I'm on 5.2
[17:33] <Cimi> dednick, as said, they changed Js
[17:33] <dednick> yeah, but still... it's the same in other places
[17:33] <Cimi> dunno then
[17:34] <Cimi> let me rebase
[17:34] <dednick> Cimi: does 'make testSimpleTextMessageMenu' work?
[17:35] <Cimi> dednick, dismiss fails here
[17:35] <Cimi> FAIL!  : qmltestrunner::SimpleTextMessageMenu::test_dismiss() A value is required for tryCompare
[17:35] <Cimi>    Loc: [/home/cimi/Development/usc/visual-updates/tests/qmltests/Menus/tst_SimpleTextMessageMenu.qml(170)]
[17:36] <Cimi> mzanetti, you should be eod - in case you aren't, any idea on fixing tryCompare with qt 5.2? ^
[17:36] <dednick> Cimi: i think there may have been checks for 5.2 in unity8 which i dont have in usc
[17:36] <Cimi> dednick, that's why I asked mzanetti
[17:37] <mzanetti> hmmm...
[17:37] <mzanetti> can you paste me the line that fails?
[17:37] <mzanetti> Cimi: ^
[17:37] <Cimi> mzanetti,  tryCompare(function() { signalSpyDismiss.count > 0; }, true);
[17:37] <mzanetti> Cimi: I don't think this works with 5.0 either
[17:37] <Cimi> or             tryCompare(function() { return signalSpyDismiss.count > 0; }, true);
[17:38] <Cimi> mzanetti, they both fail
[17:38] <mzanetti> Cimi: with 5.0 too?
[17:38] <Cimi> mzanetti, not with 5.0
[17:38] <Cimi> mzanetti, dednick said it's working for him
[17:38] <dednick> Cimi: eh...
[17:38] <mzanetti> Cimi: yeah. what I'm saying is that this is wrong
[17:38] <mzanetti> and I don't think the test was actually working
[17:38] <dednick> Cimi: it's supposed to be tryCompareFunction
[17:38] <mzanetti> yeah
[17:38] <Cimi> dednick, so why was not failing for you?
[17:38] <dednick> no idea
[17:39] <mzanetti> but tryCompareFunction is something we have in UnityTestCase only
[17:39] <mzanetti> so you'd need to copy that (or upstream into the SDK ideally)
[17:39] <dednick> mzanetti: yeah, i already have it i think
[17:39] <Cimi> dednick, with function works here
[17:39] <Cimi> dednick, but next to fail is
[17:39] <Cimi> compare(signalSpyTriggered.count > 0, true, "should have been triggered");
[17:40] <Cimi> which is false here
[17:41] <dednick> Cimi: yeah, looks like the tests were just bombing on mine, i get that as well.
[17:41] <dednick> now
[17:41] <Cimi> dednick, ok no problem, let me know when you fix them
[17:41] <Cimi> don't worry for today
[17:47] <sil2100> charles: hi! I saw that you put up a branch for fixing the 24/etc in indicator-datetime - it seems to be still failing on CI
[17:47] <sil2100> charles: can you take a look what's up?
[17:47] <charles> sil2100, yes I'm looking at it right now
[17:47] <charles> sil2100: looks like the unit tests are failing because it doesn't have locales configured s.t. we can test in a 12h and 24h locale
[17:47] <charles> sil2100: I'm currently adding hooks to debian/ for this
[17:48] <sil2100> charles: ah, makes sense - thanks for taking care of this!
[17:51] <dednick> Cimi: fixed and pushed
[18:11] <xnox> Saviq: if you are around, can you please do a quick review of https://code.launchpad.net/~xnox/unity-action-api/fix-cross/+merge/198847 ?
[18:33]  * greyback eow
[18:37] <mhr3_> same
[18:37]  * mhr3_ out
[19:58] <Saviq> xnox, hey, so no need to tweak the Qt .cmake modules in the end?
[19:59] <kdub> Saviq, would know where I could find QDBusConnectionPrivate
[20:00] <Saviq> kdub, ESYNTAXERROR
[20:00] <kdub> okay  :)
[20:00] <Saviq> kdub, lookin'
[20:01] <xnox> Saviq: what do you mean? =)
[20:01] <xnox> Saviq: cmake modules are all correct and installed into multiarch paths.
[20:01] <Saviq> xnox, but I meant to actually find moc and such
[20:01] <xnox> Saviq: automoc works correctly out of the box, i fixed that in cmake.
[20:01] <Saviq> xnox, ah, awesome
[20:02] <xnox> Saviq: same with rcc & qmake, but custom utils are need to be handled by hand.
[20:02] <xnox> Saviq: i think the cmake modules should provide standard FOO_EXECUTABLE for all qt tools, e.g. qdoc, dbuscpp, etc.
[20:03] <Saviq> kdub, https://qt.gitorious.org/qt/qt/source/33a34960328cce7a6994d2ea771c82da7bfdb598:src/dbus/qdbusconnection.cpp#L67
[20:04] <kdub> thanks Saviq!
[20:04] <Saviq> xnox, you mean that's the current state after your recent cmake upload or that's the desired state?
[20:11] <xnox> Saviq: rcc/qmake/moc - work out of the box; other tools to be defined by default is a desirable.
[20:11] <sil2100> bregma: hello! I noticed a FTBFS for lp:unity trunk in daily-build - did you guys see that?
[20:11] <xnox> (but low priority, upstream should start exposing those)
[20:12] <Saviq> xnox, ok cool, q: you said "dpkg-architecture -aarmhf -c cmake .." should cross-build locally, doesn't seem to work here?
[20:12] <Saviq> xnox, i.e. I still get a build for amd64
[20:13] <xnox> Saviq: well, that works out of the box, if there are cross-dependencies and cross-compilers installed locally.
[20:13] <xnox> and all the libfoo-dev:armhf packages
[20:13] <Saviq> xnox, ok, /me goes apt-get build-dep -aarmhf unity8
[20:13] <xnox> in practice not many libfoo-dev are multiarch:same, thus one would need to remove & install to change arches.
[20:14] <xnox> Saviq: and that implies to did dpkg --add-foreign-arch armhf & added arch qualified sources in /etc/apt/sources.list
[20:14] <xnox> and ports archive
[20:14] <Saviq> xnox, aah right, haven't done that yet apparently
[20:14] <xnox> yeah, that's what mk-sbuild --target armhf does in a chroot =)
[20:14] <xnox> so dpkg-architecture -aarmhf cmake ../
[20:14] <xnox> is intended to be run inside a suitable chroot =)
[20:15] <xnox> or e.g. under click chroot.
[20:15] <Saviq> xnox, yeah, what I'm thinking about now is to transition ./run_on_device to cross-build in a chroot and rsync the results to the device and run from there
[20:15] <xnox> (well click chroots export vars set by dpkg-architecture -aarmhf already, so actually, it's just cmake ../ under those)
[20:15] <Saviq> xnox, instead of building on the device
[20:16] <xnox> Saviq: well sbuild --host armhf, should cross-build local dir and spit out ../*_armhf.deb
[20:16] <xnox> (without specifying path to .dsc, it should work with building unpacked debian package tree, which unity8 folder is)
[20:17] <Saviq> xnox, yeah, I know, but that's still too long for quickly iterating during development
[20:19] <Saviq> xnox, and requires a writable device
[20:19] <Saviq> xnox, which we shouldn't need for unity8-only dev
[20:20] <xnox> .... dude, that cross-compiles.
[20:20] <xnox> bzr branch lp:unity8; cd unity8; sbuild -A -d trusty --host armhf; adb push ../*_armhf.deb /userdata/
[20:21] <xnox> oh, right
[20:21] <xnox> Saviq: but you can $ dpkg-deb -R *.deb unpack/
[20:21] <xnox> to unpack them
[20:21] <xnox> without installing in a home dir.
[20:21] <Saviq> xnox, sure, that I can do
[20:21] <xnox> and exectue them, or like make an override in the upstart job to run a custom one
[20:21] <Saviq> xnox, but still builds the whole thing every time
[20:22] <Saviq> xnox, usually with installing deps first
[20:22] <Saviq> xnox, unless you have a pre-made specific sbuild chroot
[20:22] <Saviq> xnox, it just does more than we generally need for quick iterations
[20:22] <xnox> e.g. $ echo "exec ~/bin/unity8" > ~/.config/upstart/unity8.override
[20:22] <Saviq> xnox, no need
[20:22] <xnox> Saviq: well full clean build here is 2m20s
[20:22] <Saviq> xnox, yeah exactly
[20:22] <Saviq> xnox, too long
[20:23] <Saviq> xnox, we're talking about during-development-deployment
[20:23] <xnox> Saviq: you can optimise, so for things that I do often i have $ mk-sbuild --target armhf --name unity8
[20:23] <Saviq> xnox, yeah, I know
[20:23] <xnox> pre-installing deps into that, I think you can bring the time lower.
[20:23] <xnox> so i'm not sure what you are asking about?
[20:23] <xnox> you want dirty builds?
[20:23] <Saviq> xnox, I'm not *asking* about anything, really :D
[20:23] <Saviq> xnox, yes
[20:24] <xnox> while qt-dev is not co-installable?
[20:24] <Saviq> xnox, no, permanently
[20:24] <xnox> well, I could point cmake at /var/lib/schroot/unity8-amd64-armhf/* to link/compile against
[20:25] <Saviq> xnox, I just don't want the overhead of building packages when all we're after is as-quick-as-possible possibly-dirty quick deployments onto device
[20:25] <xnox> (such that we can re-use the same chroot, for dirty builds, without chrooting into it)
[20:25] <xnox> (well pre-installed packages)
[20:25] <Saviq> xnox, yeah, we might use the sbuild chroot indeeed
[20:25] <Saviq> -e
[20:25] <Saviq> xnox, even chrooting into it
[20:26] <Saviq> xnox, but bind-mouting
[20:26] <xnox> to be honest this calls out to simply prioritise making all -dev packages multiarch-same which unity8 depends on.
[20:26] <xnox> i never use schroots like them.
[20:26] <xnox> let me see how it can be used in bind-mounting mode.
[20:27] <Saviq> xnox, no worries, unless you want to :)
[20:27] <Saviq> xnox, I'm all-happy with what you enabled for us already
[20:28] <xnox> hm i ponder how save it is to bind-mount /home/ into schroot.
[20:29] <Saviq> xnox, I do it all the time
[20:31] <xnox> so if the named chroot has all the right dependencies one should be able to do: schroot -c unity8-amd64-armhf "cmake .; make"
[20:32] <Saviq> didrocks, seems indeed the retry helped on maguro, awesome
[20:32] <Saviq> "Failed to unlock greeter, trying again..." yay
[20:38] <didrocks> Saviq: yeah… but still flaky then :p
[20:38] <Saviq> didrocks, well, not *really*
[20:38] <Saviq> didrocks, it's just that we don't know when the device is not busy on startup any more
[20:38] <Saviq> didrocks, to deliver the input in a timely manner
[20:39] <Saviq> didrocks, aactually
[20:39] <Saviq> didrocks, we should move to pressing the BFB
[20:39] <didrocks> Saviq: actually, we start the test 5 minutes after the boot
[20:39] <Saviq> didrocks, instead of swiping the greeter
[20:39] <didrocks> so the device isn't busy
[20:39] <Saviq> didrocks, but unity8 is starting
[20:39] <Saviq> didrocks, being restarted with testability
[20:39] <didrocks> ah yeah
[20:39] <didrocks> yep on that one
[20:39] <Saviq> didrocks, and loading dash and everything
[20:39] <didrocks> need to either send an signal
[20:39] <didrocks> to be more reliable
[20:40] <didrocks> or use qmltestrunner (shhh) ;)
[20:40] <Saviq> didrocks, we don't want to open a "ok, signal me and I'll unlock" security hole ;)
[20:40] <Saviq> didrocks, qmltestrunner might not really help in that case
[20:40] <Saviq> didrocks, what would help would be having control of the time
[20:41] <Saviq> didrocks, so with each input movement you'd tell QML how much time passed
[20:41] <Saviq> didrocks, so it's never jerky in that sense, which it is now, 'cause input just doesn't get timely to the gesture recognizer, which rejects it if it's not smooth enough
[20:42] <Saviq> didrocks, but yeah, maybe we should move to the BFB - but still would need to swipe the launcher in, so not *really* more reliable
[20:45] <didrocks> Saviq: totally make sense, should be more reliable
[20:46] <didrocks> or
[20:46] <didrocks> hum
[20:46] <didrocks> we are not really testing unlocking the greeter
[20:46] <Saviq> didrocks, yeah, that's tested regardless
[20:46] <didrocks> should be one test
[20:46] <didrocks> maybe for the other
[20:46] <didrocks> we should ship a flag/a way only with this AP test
[20:46] <didrocks> to get the greeter always unlocked?
[20:49] <Saviq> didrocks, what you called out as flaky in your email... must not have included the latest release of unity8: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/64:20131213.1:20131211.2/5443/unity8-autopilot/570019/
[20:50] <Saviq> didrocks, there would have to be a "greeter unlocked, continuing" message, or two "failed to unlock greeter"
[20:50] <didrocks> Saviq: well, the result if flaky
[20:50] <didrocks> like, I rerun the test, it pass
[20:50] <Saviq> didrocks, even with the latest unity8?
[20:50] <didrocks> yeah, this is with latest
[20:51] <Saviq> didrocks, the log suggests it's not :/
[20:51] <didrocks> Saviq: http://people.canonical.com/~ogra/touch-image-stats/20131213.1.changes
[20:51] <didrocks> image 64
[20:52] <Saviq> didrocks, I need camera on the devices then :/, I'm done guessing
[20:52] <didrocks> Saviq: I think the CI team has one
[20:52] <Saviq> didrocks, yeah, sorry for bothering you
[20:52] <Saviq> didrocks, go have your weekend
[20:52] <didrocks> well, trying to promote the image first :)
[20:54] <Saviq> didrocks, ah, those tests don't use the helpers
[20:54] <didrocks> ahah!
[20:54] <didrocks> :)
[20:54] <Saviq> didrocks, where the retrying is done
[20:54] <Saviq> didrocks, will have to fix that
[20:54] <didrocks> see, everything has an explanation!
[20:54] <didrocks> :)
[20:54] <didrocks> Saviq: great ;)