[08:19] <Saviq> tsdgeos, mzanetti, unity8-ci now runs both vivid and wily jobs for MPs against lp:unity8
[08:19] <tsdgeos> saw one
[08:19] <tsdgeos> but was all failures?
[08:19] <tsdgeos> but maybe it was conflicts
[08:19] <tsdgeos> did you put a dummy MR to test?
[08:19] <Saviq> this was a trunk-only build http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/6281/console
[08:20] <Saviq> oh, ENOSPC
[08:22] <Saviq> looks like testing wily on mako is busted
[08:22] <Saviq> qmluitests on wily timed out
[08:30] <mzanetti> Saviq, ack
[08:32] <Saviq> mzanetti, so, I wanted to push overlay to trunk, not merge (to keep history ~flat)
[08:32] <mzanetti> wfmsilo
[08:32] <mzanetti> wfm
[08:32] <Saviq> mzanetti, so I'll do that now (merge trunk into overlay - just translation updates)
[08:32] <mzanetti> not sure where that "silo" came from
[08:32] <Saviq> and push overlay into trunk
[08:32] <mzanetti> right
[08:32] <mzanetti> ok... then delete the overlay branch probably to avoid confusion
[08:33] <mzanetti> @unity: ^^   jenkins runs vivid tests on trunk now. we can kill the overlay. please merge towards trunk again now
[08:34] <mzanetti> like last time, I can resubmit already approved branches myself when building the next silo...
[08:34] <Saviq> mzanetti, which MP is still en route to overlay?
[08:34] <mzanetti> there are some...
[08:34] <Saviq> mzanetti, I mean you said there was something in silo already
[08:34] <Saviq> or maybe I misunderstood
[08:34] <mzanetti> Saviq, sure... but some branches people started to work on in the last days/week
[08:34] <mzanetti> we just redirect them...
[08:34] <mzanetti> no prob
[08:35] <Saviq> ok, I'll do that now to get jenkins to work on them
[08:35] <Saviq> and so that I can delete overlay
[08:35] <mzanetti> yep
[08:35]  * mzanetti checks the silo list
[08:37] <Saviq> OMG LP pushes commit over when resubmitting!
[08:37] <mzanetti> Saviq,
[08:37] <mzanetti> https://requests.ci-train.ubuntu.com/#/ticket/359
[08:37] <mzanetti> don't delete just yet
[08:37] <mzanetti> that one is QA granted
[08:37] <Saviq> oh
[08:39] <Saviq> mzanetti, do we need to do anything to publish?
[08:42] <mzanetti> Saviq, not that I know... it's still trainguards who do that
[08:54] <tsdgeos> can someone remind me how do i run unity8 manually on the phone?
[08:54] <tsdgeos> long list of env vars required afair
[08:58] <tsdgeos> ok, not that many
[08:58] <tsdgeos> MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver  /usr/bin/unity8
[09:59] <tsdgeos> i need some help here i don't understand something
[09:59] <tsdgeos> i'm stracing the unity8 process
[09:59] <tsdgeos> and this is the output of grepping for 245 in the output
[09:59] <tsdgeos> http://paste.ubuntu.com/12436814/
[09:59] <SolarNRG> Is this the place to ask questions about the unity 3d engine that is used in Kerbal Space Program in a linux environment?
[09:59] <tsdgeos> but then cat /proc/`pidof unity8`/fdinfo/245 still exists
[09:59] <tsdgeos> SolarNRG: nopes
[09:59] <tsdgeos> SolarNRG: see the topic
[10:00] <tsdgeos> so why if the last thing with 245 i have is a close(245) the fd is still there in proc?
[10:01] <tsdgeos> greyback: ↑ you did some of the fd grepping yesterday too, please can you review ↑ ¿
[10:02] <greyback> tsdgeos: lemme try
[10:04] <tsdgeos> fwiw ths strace_output comes from
[10:04] <tsdgeos> sudo strace -p `pidof unity8` &> strace_output
[10:24] <greyback> tsdgeos: I see your confusion, but I've not managed to find that happening here...
[10:24] <greyback> can you "ll /proc/`pidof unity8`/fd/245" and see if it is a file?
[10:30] <greyback> sudo  strace -e trace=desc -p `pidof unity8` 2>&1 | grep -v -P "(read|write|poll)"
[10:30] <greyback> tsdgeos: ^^ tracks just calls with file descriptors, filtering out the noisy ones
[10:33] <greyback> I'm definitely seeing an un-closed eventfd2 call every time I switch an app - exactly when shell asks to suspend it
[10:34] <greyback> tsdgeos: ted had a patch, is it built anywhere?
[10:40] <tsdgeos> greyback: yeah i wasn't asking that :D
[10:41] <tsdgeos> greyback: i was asking about what i had written above about the log
[10:41] <tsdgeos> greyback: yes ted's patch is on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060
[10:41] <tsdgeos> and it does indeed fix that case
[10:42] <tsdgeos> but it does have some issues on killing apps
[10:42] <greyback> tsdgeos: I can't answer you, I've not managed to find it happening here
[10:42] <tsdgeos> i just can't figure out which fds are leaking
[10:42] <tsdgeos> ok
[10:42] <tsdgeos> thanks
[10:42] <greyback> sorry
[10:42] <greyback> it would be illogical for the kernel to claim an fd is open, if the app closed it
[10:43] <greyback> so I dunno
[10:49] <tsdgeos> yeah :/
[10:49] <tsdgeos> i'll reboot and try again
[11:08] <greyback_> dednick: there?
[11:09] <dednick> greyback_: yo
[11:09] <tsdgeos> dednick: ah, you set the time MR to Work in progress, why?
[11:10] <greyback_> dednick: hey, am looking at touch_tracing now. I still don't get why you need the C++ loaders for the qml, i.e. why "qmlscene" is not enough. You say it's to specify the mir socket with a "-m" switch. Is that to make it compatible with Mir's system?
[11:10] <greyback_> Mir's benchmarking system I mean
[11:14] <dednick> greyback_: yeah
[11:14] <dednick> they use the command line switches to provide socket opt
[11:15] <dednick> tsdgeos: erm. dunno. give me a sec
[11:15] <dednick> tsdgeos: changed
[11:15] <tsdgeos> oki
[11:16] <greyback_> dednick: pah, that's annoying. Means anything that we'd like to benchmark must provide that switch, which is unrealistic. Could you log a bug to get them use their MIR_SOCKET env var instead for benchmarking, and add a REMOVEME to the C++ linking to that bug
[11:16] <dednick> greyback_: sure
[11:16] <greyback_> thanks
[11:20] <dednick> greyback_: done removeme.
[11:21] <greyback_> dednick: ta
[11:25] <mzanetti> dednick, we're back to trunk
[11:25] <mzanetti> (just saw your new MP)
[11:25] <dednick> mzanetti: so no more overlay?
[11:25] <mzanetti> dednick, you really want to fix your highlight on unity
[11:25] <mzanetti> yep
[11:25] <dednick> hm. dunno why it's not working.
[11:26] <greyback_> dednick: xchat?
[11:26] <greyback_> I have the same issue
[11:26] <dednick> greyback_: hexchat
[11:26] <dednick> so probably same
[11:26] <mzanetti> right... hexchat did not do any notifications for me... that's why I threw it away
[11:27] <dednick> i get the nick highlight, just not others :/
[11:28] <dednick> tsdgeos, mzanetti: retargeted
[11:28] <mzanetti> ta
[11:32] <tsdgeos> dednick: k
[11:39] <ltinkl> dednick, could you please have a look and review https://code.launchpad.net/~lukas-kde/unity8/betterDesktopIndicators/+merge/271455 when you get a moment? tia
[11:39] <dednick> ltinkl: sure
[11:50] <ltinkl> dednick, left 2 comments in your i18n-RelativeDateTime MPs
[11:51] <dednick> ltinkl: and i've left you some :)
[11:51] <ltinkl> dednick, sure :)
[11:53] <dednick> ltinkl: i can only see one. :/
[11:53] <dednick> the i18n
[11:53] <dednick> which is done in a different branch
[11:54] <dednick> ltinkl: https://code.launchpad.net/~nick-dedekind/unity8/message.notification.translations/+merge/270151
[11:55] <dednick> ltinkl: might just move it to there though...
[11:56] <ltinkl> dednick, ye, either is fine with me
[12:10] <ltinkl> dednick, is that the correct link? getting 404 there
[12:11] <dednick> ltinkl: i've moved it to the other time formatting branch
[12:40] <tsdgeos> ltinkl: you realized you comented on a branch that's already been merged?
[12:41] <tsdgeos> anyone has any idea of what creates fd of type anon_inode:dmabuf ?
[12:41] <ltinkl> tsdgeos, mir?
[12:42] <tsdgeos> i mean the syscall
[12:46] <tsdgeos> maybe strace doesn't intercept those
[12:48]  * tsdgeos keeps digging
[12:54] <ltinkl> dednick, the UITK LiveTimer, is that a new thing? I can't find it on https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.Components/
[12:54] <dednick> ltinkl: it's new.
[12:54] <ltinkl> dednick, 1.3?
[12:54] <dednick> might only be in staging
[12:56] <dednick> ltinkl: yes, it's in 1.3
[12:56] <ltinkl> dednick, can I use that? :)
[12:56] <dednick> ltinkl: which version are you using?
[12:57] <ltinkl> dednick, 1.1 is there atm, the question is can I use 1.3?
[12:57] <dednick> mzanetti: is unity trunk using 1.3 uitk now?
[12:57] <mzanetti> dednick, no
[12:57] <ltinkl> 1.2 at most?
[12:58] <mzanetti> yes
[12:58] <dednick> mzanetti: is there any eta on 1.3 for unity8?
[12:58] <mzanetti> dednick, I keep on asking that question but noone gives an answer
[12:59] <tsdgeos> dednick: mzanetti: we have at least two regressions
[12:59] <tsdgeos> see top of description of https://code.launchpad.net/~unity-team/unity8/use_sdk_13/+merge/269850
[12:59] <tsdgeos> other thing is if we want to start using it selectively
[12:59] <tsdgeos> i think we do already somewhere
[12:59] <dednick> ltinkl: well i think you can target against 1.3 since we've got a bunch of other branches relying on it. when the time comes we can land them all together.
[12:59] <dednick> mzanetti:^ ? fine?
[13:00] <mzanetti> well, if you want something to get into OTA-7 for sure, better don't rely on 1.3 to land
[13:00] <mzanetti> using 1.3 might block your branch from landing until the apps update to 1.3
[13:00] <tsdgeos> so we have 2 "import Ubuntu.Components 1.3", but they are on tests/
[13:01] <ltinkl> well this is not strictly targetting any OTA
[13:01] <ltinkl> dednick, well anyway, the Timer is not a big deal there, it only runs when the indicator is open anyway
[13:02] <ltinkl> dednick, so I guess I don't really need the LiveTimer
[13:10] <dednick> ltinkl: are you sure it's only run when it's open?
[13:10] <ltinkl> dednick, yup
[13:11] <ltinkl> dednick, running: identifier == "indicator-datetime" // only run when we're open
[13:11] <dednick> yes, i see that. but don't know why that would stop it running
[13:11] <ltinkl> dednick, right, will double check
[13:11] <dednick> the items should exist if it's not open.
[13:11] <dednick> as far as i remember
[13:16] <mterry> mzanetti, overlay is finally dead then?  Shall I resubmit all my open branches?
[13:16] <mzanetti> mterry, yes :)
[13:17] <mterry> not just me, we have a lot extant
[13:17] <mzanetti> mterry, there's a conflict in the tutorial one
[13:17] <mterry> ok
[13:41] <ltinkl> dednick, ok, I changed the timer to: running: identifier == "indicator-datetime" && tzMenuItem.visible // only run when we're open
[13:41] <ltinkl> dednick, and that works, double checked with a debug output with onRunningChanged
[13:41] <ltinkl> dednick, the timer stops when the indicator popup closes
[13:43] <dednick> ltinkl: dont think there's any reason for the "identifier == "indicator-datetime"" is there ?
[13:43] <ltinkl> dednick, ye true :)
[13:45] <ltinkl> dednick, ok, addressed the issues, MP updated
[14:00] <mhall119> Trevinho: I have a question about https://plus.google.com/u/0/+MarcoTrevisan/posts/ZLWYfRMZWNGhttps://plus.google.com/u/0/+MarcoTrevisan/posts/ZLWYfRMZWNG
[14:00] <mhall119> is that a fully functional Unity 8 environment? Can you run click apps inside it?
[14:01] <Trevinho> mhall119: no, is running on desktop, so click apps aren't working
[14:02] <mhall119> Trevinho: click apps are technically installable on the desktop, is the limitation something to do with Unity8 or LXC?
[14:03] <mhall119> or is it missing some platform services/apis that apps need?
[14:03] <Trevinho> mhall119: well... I didn't try much as I was just interested in getting the shell working...
[14:14] <dandrader> mzanetti, something to keep in mind
[14:14] <dandrader> mzanetti, After rebasing mousePointer over the latest unity8
[14:14] <dandrader> mzanetti, the cursor stopped changing its shape when hovering over window borders
[14:15] <dandrader> mzanetti, and that was because your latest additions to DesktopSpread, a bunch of MouseAreas that you set to invisble or disabled when not used
[14:15] <mzanetti> mhm
[14:15] <mzanetti> I thought I did set it to invisible...
[14:15] <mzanetti> is that not enough?
[14:16] <dandrader> mzanetti, but (feels like a bug in QML), a MouseArea that is disabled but still visible (or vice versa) will block MouseAreas behind from getting hover events
[14:16] <dandrader> mzanetti, so they have to be both invisible and disabled
[14:16] <mzanetti> ah ok.
[14:16] <mzanetti> dandrader, ack, will do so. thanks
[14:16] <dandrader> mzanetti, fixed in mouseArea branch
[14:16] <mzanetti> dandrader, don't fix it... I've moved that code around alot
[14:17] <dandrader> mzanetti, and that affects only hover events, presses go through normally
[14:17] <mzanetti> basically I've moved *everything* related to the spread outside of DesktopStage, into a new file
[14:17] <mzanetti> dandrader, yes... I've seen those issues when I introduced that mousearea
[14:17] <dandrader> mzanetti, well, the fix was just a couple of "visble: enabled" entries
[14:17] <mzanetti> ok... I'll get it merged
[14:17] <mzanetti> it's just that each conflict basically gives me 2 copies of the file
[14:18] <mzanetti> because it changed the indentation of the whole file :D
[14:18] <mzanetti> as I removed one wrapping item
[14:18] <mzanetti> anyhow. ack, will pay more attention to setting them both to "off"
[14:18] <mzanetti> thanks for the heads up
[14:19] <dandrader> mzanetti,  s/mouseArea branch/mousePointer branch
[14:19] <dandrader> mzanetti, ok
[14:19] <mzanetti> yep. my braind FEC'd it :D
[14:19] <dandrader> :)
[14:30] <mzanetti> @unity: standup
[14:31] <mzanetti> dednick, special invite :)
[14:31] <mzanetti> we already found someone for the notes. you can join now
[14:32] <Saviq> lol
[14:32] <dednick> mzanetti: lol. thanks
[14:35] <dednick> what do people use for irc these days?
[14:35] <mzanetti> gnome-xchat here
[14:35] <mzanetti> used to use konversation, which I like best
[14:35] <mzanetti> but as of KDE5 it requires a QPA to work properly
[15:10] <kgunn> tsdgeos: so if you and i both confirmed that tedg's branch at least addresses fd leak in that one instance (app open + user app close)
[15:10] <kgunn> shouldn't we aim to land that fix ?
[15:10] <tsdgeos> totally
[15:11] <tsdgeos> it's an improvement already
[15:23] <greyback_> dednick: found deployment issue with https://code.launchpad.net/~unity-team/qtmir/touch_tracing/+merge/267083
[15:32] <dednick> greyback_: doh. ok thanks.
[15:33] <greyback_> dednick: other than that, I think it's good to go
[15:46] <dednick> greyback_: how did you install?
[15:47] <greyback_> dednick: built packages in my armhf schroot, copied to device and installed
[15:49] <Saviq> \o/
[15:59] <mhall119> Trevinho: trying to run mir_demo_server according to your G+ post, I get:
[15:59] <mhall119> ERROR: /build/buildd/mir-0.12.1+15.04.20150324/src/common/sharedlibrary/shared_library.cpp(33): Throw in function mir::SharedLibrary::SharedLibrary(const char*)
[15:59] <mhall119> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
[15:59] <mhall119> std::exception::what: /usr/lib/i386-linux-gnu/mir/server-platform/server-mesa-x11.so.4: undefined symbol: _ZN3mir6events10make_eventExNSt6chrono8durationIxSt5ratioILx1ELx1000000000EEEEj16MirPointerActionjffff
[15:59] <mhall119> I'm installing it on vivid from the citrain stable-phone-overlay PPA
[16:00] <Trevinho> mhall119: mhmh.... Weird
[16:00] <Trevinho> mhall119: I've compiled everything from trunk
[16:00] <mhall119> maybe it's not in the PPA yet then
[16:00] <Trevinho> mhall119: it seems that soemthing needs to be compiled though as make_event got an API change I think
[16:01] <Trevinho> mhall119: I can provide a raw deb-src for you btw
[16:01] <Trevinho> mhall119: as I've also done a rebase on the wily version
[16:01] <mhall119> I only have server-mesa-x11.so.4 while your example uses .so.5
[16:01] <mhall119> Trevinho: sure, I'm willing to give compiling a try
[16:01] <Trevinho> mhall119: yeah, from wily is .4 anyway
[16:01] <Trevinho> so, let me do that
[16:14] <Trevinho> mhall119: sorry for the delay https://transfer.sh/FuIAh/mir-0.15.1-15.10.20150903-0ubuntu1-x11-backend1.tar.gz
[16:15] <popey> Trevinho: have you seen bug 1496414 ?
[16:15] <Trevinho> popey: yeah... it's quite tricky, though
[16:15] <popey> :(
[16:15] <Trevinho> popey: as unity uses Alt for showing menus
[16:15] <Trevinho> so, probably it's better to fix the screenshotter
[16:15] <popey> any chance we can tweak the timing?
[16:15] <popey> of how quickly the title bar changes?
[16:16] <Trevinho> popey let me check I think there's a flag, but maybe it's private
[16:16] <Trevinho> i.e. hardcoded :/
[16:16] <popey> not sure how we could fix the screenshot tool other than force it to be delayed
[16:16] <Trevinho> popey: however.... if you're really quick in pressing the keys you can avoid the blurred thing to show :)
[16:16] <popey> which is a bit mad, because if I press alt+prtscr I want a screenshot now, not later
[16:16] <Trevinho> popey: yeah, delay is the only thing I've in mind
[16:17] <popey> also, that will affect other desktops which use the same screenshot tool
[16:17] <popey> the bug is ours, not theirs
[16:17] <Trevinho> sure
[16:22] <Trevinho> popey: mh, so it's hardcoded to 180ms... We can easily add a setting for that
[16:22] <popey> yay
[16:28] <mhall119> Trevinho: thanks, compiling now
[16:28] <mhall119> Trevinho: do I have to install the built .deb or can I try doing this from the local build dir?
[16:31] <Trevinho> mhall119: I didn't build the debs, I installed that in a temporary install prefix (you can use something like https://gist.github.com/3v1n0/c270e6583a22845e067f to easily add one)...
[16:55]  * popey hugs Trevinho 
[16:55] <Trevinho> :)
[16:58] <mhall119> Trevinho: wow, this takes forever to build
[16:59] <Trevinho> mhall119: no.. just disable test and android stuff
[16:59] <mhall119> how?
[16:59] <Trevinho> mhall119: I don't have the cmake command handy, but use cmake-gui and set to build only mesa-kms (if you want) and mesa-x11, then look for tests options and disable them
[17:01] <mhall119> oh man, where has cmake-gui been all my life?
[17:05] <davmor2> mhall119: in the repo?
[17:05] <mhall119> davmor2: ?
[17:05] <davmor2> mhall119: guessing at where cmake-gui had been all your life :)
[17:32] <popey> andyrock: thanks for the link on bug 1421575 - am building unity locally to test
[17:33] <andyrock> let me know it it helps
[17:49] <popey> andyrock: promising!
[17:50] <popey> andyrock: I monkeyed around with display resolution, switched monitors on and off and no corruption
[17:50] <andyrock> well keep testing it
[17:50] <popey> ya
[17:50] <andyrock> thanks!!
[17:50] <popey> np
[17:51] <popey> do i need any package other than unity, out of the ones I build?
[17:51] <popey> I figured I dont need all the unity2d ones.
[21:06] <Trevinho> popey: I would have prepared a silo for some hours now, if we weren't just out of them :(