[05:16] <RAOF> You know what I *really* want to do while dog tired? Start writing an X window manager.
[05:16] <RAOF> That'll be awesome.
[07:04] <RAOF> duflu: Oh, is client initiated window resize implemented?
[07:04] <duflu> RAOF: No. That depended on the attribute thing, which half the team disliked
[07:05] <RAOF> Ah, ok. So worrying about how to handle resize in xmir-rootless is somewhat premature :)
[07:15] <duflu> RAOF: There's still time. Technically we haven't released 0.1.3 which is the first release with MirResizeEvent
[07:16] <RAOF> Well, it doesn't particularly matter to me if it's not available in 0.1.3
[07:51] <duflu> RAOF: I mean I told Gerry the resize event design might change in 0.1.3/0.1.4. And having not released 0.1.3 yet we have lots of freedom still
[07:52] <RAOF> Ah, cool.
[07:52] <RAOF> Well, I don't particularly care about the events as such; I can pull that data from the buffer.
[07:52] <RAOF> I care about the ability to resize from the client, though.
[07:55] <anpok_> is that something the shell still could deny?
[07:59] <RAOF> Yes
[08:04] <duflu> ... in theory. Not implemented yet because nothing beyond the shell /can/ resize surfaces yet :)
[08:04] <duflu> It's just a virtual function the shell could override I think
[08:04] <RAOF> Well, ye.
[08:21] <duflu> Hmm, didn't expect that. I just noticed clients only get input events iff the gesture started inside the client surface
[08:22] <duflu> I guess that's correct
[08:23] <duflu> Hmm, and only if it starts inside the client's creation size. That's wrong.
[09:56] <duflu> alf_: Shall I merge the fix manually?
[09:57] <alf_> duflu: I was about to do it (almost done)
[09:57] <duflu> alf_: OK, thanks. I shall vanish then
[09:57] <alf_> duflu: Enjoy!
[10:07] <alan_g> alf_: does that resolve the remaining CI issues?
[10:08] <alf_> alan_g: duflu's fix?
[10:09] <alan_g> alf_: I'm still catching up - it looked as though it was related to your fix failing
[10:11] <alf_> alan_g: No, duflu's MP updates our cross compilation tools for a change in upstream packaging
[10:13] <alan_g> alf_: OK, I'd noticed that you MP had failed for "E: Couldn't find these debs: android-platform-headers" and wondered if we were nearly there yet.
[10:13] <alan_g> *your
[10:25] <ogra_> alan_g, alf_, the package was renamed (upstream) to "android-headers"
[10:25] <ogra_> (update your build deps)
[10:26] <alan_g> ogra_: ogra_ that's what alf_ is merging (above)
[10:27] <ogra_> oh
[10:28] <alf_> ogra_: alan_g: Actually the fix was to remove the dependency completely from our cross tools, since it turned out we didn't actually need it
[10:29] <alan_g> alf_: Yeah, that's the best sort of "update". ;)
[10:29] <ogra_> :)
[10:32] <alf_> alan_g: @test-framework-wait-for-server-startup, it resolves some of our CI problems (and improves our pass rate), but it seems there are still other issues not addressed by the MP. I would like to get this MP merged (even manually if needed), so that when we get failure we at least know it's some other problem
[10:33] <alan_g> alf_: I'm happy with that approach. (I guess you want me to change my vote?)
[10:34] <alf_> alan_g: Only if you are happy with the handling of the shutdown tests
[10:35] <alan_g> alf_: that's what I'm looking at. ;)
[10:39] <alf_> alan_g: http://paste.ubuntu.com/6588244/ is a minimal example to exercise the valgrind behavior which was worked around in the last commit
[10:44] <alf_> alan_g: wait_for_server_process_to_finish() ?
[10:46] <alan_g> alf_: terminate_server_and_wait_for_shutdown()?
[10:48] <alf_> alan_g: so, shutdown_server_process => terminate_server_and_wait_for_shutdown , wait_for_shutdown_server_process => wait_for_server_shutdown ?
[10:50] <alf_> alan_g: anyway, as you said, this is for later...
[10:50] <alan_g> alf_: I can't think of anything better. But I don't quite feel convinced. :(
[10:55] <tvoss> greyback, ping
[10:55] <greyback> tvoss: pong
[11:13] <xnox> hello again.
[11:13] <xnox> what's equivalent to figuring out screen size / resolution under mir?
[11:14] <xnox> are there mir API docs?
[11:23] <RAOF> xnox: There are; http://unity.ubuntu.com/mir/
[11:24] <xnox> RAOF: excellent. and are there any command-line utility that exposes/prints MirDisplayInfo width & height?
[11:24] <RAOF> xnox: http://unity.ubuntu.com/mir/mir__client__library_8h.html is the client API
[11:25] <RAOF> xnox: mir_demo_client_display_config is a demo client that'll do that.
[11:27] <alan_g> alf_: @http://paste.ubuntu.com/6588244/ - the lack of a join() is likely a licence for inconsistent behaviour.
[11:39] <nic-doffay> Hey everyone, I'm looking to get an FPS count from mir, can anyone give me any tips?
[11:45] <alan_g> nic-doffay: some of the demo apps outout an fps count to the console. Is that what you need?
[11:51] <nic-doffay> alan_g, I'd like to output the frames somewhere in unity8.
[11:58] <alan_g> nic-doffay: I'm not sure where unity8 calls mir_surface_swap_buffers() (I assume it is in platform-api) - but those are the calls you'd need to count.
[11:59] <anpok_> and then maybe extrapolating the frame delay would be also of interest
[12:04] <nic-doffay> alan_g, should I just grep that call?
[12:12] <alan_g> nic-doffay: I guess you could also detect the unity8 client server-side and intercept the calls there. C.f. http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/surfacefactory.cpp (although that just identifies the unity8 surface, it doesn't intercept the call you want to count)
[12:13] <nic-doffay> alan_g, I'll the first approach I think.
[12:14] <alf_> alan_g: sure in a normal situation, but it shouldn't matter in the case since the process aborts (join() wouldn't be called anyway in this scenario)
[12:19] <alan_g> alf_: rephrasing: I'm not sure how well the C++ memory model copes with posix signals - there could well be dragons around here.
[12:19] <alf_> alan_g: ok
[12:22] <nic-doffay> greyback, ^
[12:28] <nic-doffay> Saviq, is qt client FPS enough for our purposes?
[12:29] <Saviq> nic-doffay, probably, yeah
[12:36] <nic-doffay> Saviq, could this just be done from Qt?
[12:36] <Saviq> nic-doffay, yeah of course
[12:36] <Saviq> nic-doffay, only place it can be done, really, if we want it cross-display-server
[12:37] <nic-doffay> Saviq, I mean look for something in the scenegraph. I was pointed towards QML_RENDERER_TIMING
[12:37] <Saviq> nic-doffay, yes
[12:51] <xnox> So i've pushed mir_demo_client_display_config to the phone, yet all it says "Can't get connection" whilst unity8 is running.
[12:51] <xnox> how can I get display size from the running unity8/mir ?
[12:59] <anpok_> xnox: how do you start it?
[12:59] <alf_> xnox: You need to connect to the server that unity8 connects to (or to the system compositor)
[13:00] <xnox> anpok_: ./mir_demo_client_display_config from adb shell.
[13:00] <xnox> alf_: how do I do that?
[13:01] <xnox> hm, is mir socket a well-known value?
[13:01] <alf_> xnox: you can pass -f
[13:02] <kgunn> xnox: also...can you retarget your mp from lp:mir to lp:mir/devel ?
[13:03] <xnox> kgunn: why is lp:mir the default merge proposal target then on the lp-project?
[13:03] <xnox> kgunn: how would I know that you are using custom series for development....?
[13:03] <xnox> kgunn: shouldn't there instead be stable series and lp:mir the devel one?
[13:06] <alf_> xnox: @mir socket, are you running as root?
[13:06] <alf_> xnox: if os try as phablet
[13:06] <xnox> kgunn: I followed http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html
[13:06] <xnox> alf_: fails with both phablet & sudo user. let me try -f
[13:07] <alf_> xnox: -f requires the path
[13:07] <xnox> ..
[13:07] <alf_> xnox: try /var/run/user/[userid]/mir_socket
[13:09] <xnox> i am running android emulator, and i want to find out the current screen resolution & DPI.
[13:09] <xnox> /var/run is  a symlink to /run/ ;-)
[13:11] <xnox> using mir_socket as root or as phablet user still gives me Can't get connection.
[13:12] <alf_> xnox: I don't know if you need special permissions (e.g. given by starting to upstart) to be able to connect to unity8
[13:13] <alf_> xnox: ...given by starting through upstart...
[13:13] <xnox> ... i have root & have apparmor disabled.
[13:13] <xnox> is only one client at the time supported?
[13:14] <alf_> xnox: not that I know of
[13:14] <xnox> alf_: I installed fbset and it gets the the framebuffer resolution and i'm happy with that for now =)
[13:15] <alf_> xnox: ok
[13:15] <xnox> alf_: but i would want to get the screen size & dpi from mir/unity, such that i know what mir/unity8 thinks it is.
[13:15] <xnox> either by connecting to unity8's mir_socket or somehow talking to unity8 asking it to export that information.
[13:16] <xnox> e.g. in the unity8 logs I see "creating surface at (0, 0) with size (480, 800) with title 'Qml Phone Shell'"
[13:16] <greyback> xnox: client will be denied connection unless it called with "--desktop_file_hint=dialer-app"
[13:16] <xnox> but i really do not want to get that via API of a sorts, instead of parsing logs which might not be there.
[13:18] <xnox> greyback: (a) that's a .desktop file lauching hack of the qmlscene apps (b) i'm launching mir_demo_client_display_config from command-line (c) i'm not use upstart-app-launch (d) mir_demo_client_display_config obviously does not have such a flag
[13:18] <xnox> greyback: so how do I hint / get the connection to the running instance of unity8/mir?
[13:18] <greyback> xnox: for (a) it's for /any/ app that connects to mir/unity8, not just qmlscene apps
[13:19] <xnox> hm, ok.
[13:19] <xnox> greyback: i don't actually want to run anything =/ only print / retrieve resolution & dpi. Maybe mir_demo_client_display_config is too much for that task?
[13:19] <greyback> xnox: flag is not actually for the client application, it should be ignored by the client. unity8 is the thing that cares about that flag
[13:20] <greyback> xnox: unity8 does have a basic dbus interface to get screen size right now (not dpi though)
[13:21] <xnox> greyback: ah, that's better =) let me check it out.
[13:21] <greyback> xnox: check out com.canonical.Unity.Screen
[13:21] <xnox> greyback: excellent!
[13:21] <xnox> greyback: thanks a lot =)
[13:22] <greyback> xnox: oh no, it was actually removed
[13:22] <greyback> xnox: it could be restored. Why do you need it?
[13:24] <xnox> greyback: at the moment autopilot hard-codes the screen resolution based on device codenames, emulator can run with any resolution / dpi therefore we actually need to query it at runtime to figure out the right resolution/dpi and it must match what mir/unity8 will think it is.
[13:24] <xnox> greyback: i'm actually not sure if unity8/mir is running when autopilot starts up, if it doesn't we can surely start mir/unity8 just to query that.
[13:25] <xnox> greyback: here is the current "resolution" detection http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/display/_upa.py
[13:26] <alf_> kgunn: alan_g|lunch: the latest errors at https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/100/console , especially the failure of Process.a_successful_exit_function_succeeds, looks very suspicious. It makes me think that there is a problem (race?) in our test process handling code...
[13:26] <xnox> greyback: autopilot simulates the touch events based on resolution hence it needs to know the geometry.
[13:26] <alf_> kgunn: alan_g|lunch: that is causing all the remaining issues we are seeing
[13:26] <greyback> xnox: gotcha. What solution would you prefer? dbus interface? Or a simple Mir client that can read the display info itself?
[13:30] <xnox> greyback: not sure. i think a simple mir client would be useful beyond just autopilot, and easy enough to itegrate.
[13:30] <xnox> greyback: i'll ping thoami to see if he'll prefer a dbus api as well / in addition / or just that.
[13:31] <greyback> xnox: ok
[13:31] <xnox> greyback: e.g. at the moment autopilot cannot change the resolution at runtime, but clearly unity8/mir can and so can the android emulator.
[13:32] <xnox> greyback: in the perfect world that mir client would query running instance if there is one, otherwise start-dummy-mir and query that and exit/clean-up. such that one can query "current or the probably would be" resolution.
[13:33] <greyback> alf_ any ideas on how that could be done?
[13:37] <alf_> greyback: xnox: mir clients/servers don't have any knowledge of existing servers, that should be handled externally in a script tailored for the specific scenario (e.g., check if unity8 is running and connect a client to its socket, otherwise start a mini server)
[13:38] <xnox> alf_: that should be ok. so it's just the mir client that needs to connect to an  existing server and query info from it.
[13:41] <kgunn> xnox: fair....i'll followup to change that
[14:24] <alan_g> alf_: It is possible. I remember we had some problems in the shutdown code that I never really dug into.
[17:54] <racarr> bregma: https://code.launchpad.net/~robertcarr/mir/nested-internal-egl-on-mesa-with-caveat/+merge/199329
[17:54] <racarr> this should work for you with no multimonitor
[17:54] <racarr> if you have a second monitor you probably needtoliterally unplug it
[17:55] <bregma> racarr, sweet, multimonitor is not (yet) a requirement
[17:55] <racarr> it shouldbe fixed sooner than later anyway just some sort of bug
[17:56] <bregma> I'll play with it today, when my test rig gets freed up again
[17:56] <racarr> I haven't tested unity8/usc yet...
[17:56] <racarr> ok great!lemme know
[17:56] <racarr> all the appropriate demos work now so it should work but I reinstalled my machine and don't feel like rebuilding the entire unity8stack at this exaaaaccct
[17:57] <racarr> moment
[17:57] <racarr> but will soon haha
[19:43] <bregma> racarr, that seemed to do the trick: now U8 crashes trying to connect to the phone sensors (because the desktop is not a phone and does not have sensors) ... which means your fix worked, all you need to do is get it committed
[19:45] <bregma> now the question is, can Mir be tuned so it doesn't try to connect to the Android accelerometer when it's not running on an Android kernel, or at least not crash?
[19:47] <bregma> at least this problem is not in Mir itself, so not your problem
[20:15] <racarr> bregma: problem is in platform APII guess
[20:15] <racarr> need stub sensors build on desktop?
[20:41] <bregma> racarr, my current problem is in libqubuntumirserver.so, there are a lot of confusingly named libraries involved, I think every combination of 'ubuntu' 'mir' and 'server' is used by every project involved in the Unity8 stack
[20:51] <racarr> bregma: That'sbecause that's the qt platform integration plugin
[20:51] <bregma> yep
[20:51] <racarr> there is qtubuntumirserver (for unity8) and qubuntumirclient/qubuntusurfaceflinger (just called qubuntu)
[20:51] <racarr> but they get sensors from platform API
[20:51] <racarr> so it should be fixed at that level,
[21:37] <tvoss> bregma, can you file a bug against the platform api to fallback gracefully if sensors are not available?
[21:38] <bregma> tvoss, should it be the platform_api or the qtubuntu_sensors that falls back gracefully?
[21:38] <tvoss> bregma, hmmm, I think it really should be platform api
[21:39] <bregma> OK, I'll file the bug against it
[22:06] <tvoss> bregma, thanks


[03:06] <bmatusiak> what is the "-customized" for?
[07:43] <penk_> dpm: ping
[07:43] <penk_> dpm: do you want me to fix the uriHandler? # https://code.launchpad.net/~reminders-app-dev/reminders-app/uriHandler/+merge/239961
[07:49] <dpm> morning penk_, yeah, that'd be awesome. I put it on a team branch in case anyone needed to modify Riccardo's original branch
[07:50] <penk_> dpm: alright
[09:21] <davmor2> nik90: you had a click package floating around I have a little time if you still need people to look at it
[09:22] <davmor2> nik90: if you do can I have the link again please
[09:30] <rpadovani> penk_, ping
[09:31] <penk_> rpadovani: pong
[09:31] <rpadovani> penk_, about https://bazaar.launchpad.net/~reminders-app-dev/reminders-app/uriHandler/revision/290, you cannot put the witch in onOpened, because could be called before the connection to the evernote server is set
[09:31] <penk_> rpadovani: I understand you want to make sure evernote is connected when handling uri
[09:32] <penk_> rpadovani: but, the onIsConnectedChanged happens before onOpened, commands is always undefined
[09:33] <rpadovani> penk_, you have a point. I'll think a solution to both cases this afternoon, thanks for rising up
[09:33] <penk_> rpadovani: and, if it's connected, and stay connected, next onOpened commands won't be handled, since there's no isConnected change..
[09:33] <penk_> rpadovani: if there's a better way to handle this, please advice :D
[09:34] <penk_> rpadovani: I'll be EOD soon
[09:34] <rpadovani> penk_, sorry, just landed from US, not so wake up to think to a solution right now :-) I'll ping you tomorrow morning, is ok?
[09:35] <penk_> rpadovani: no hurry, take your time
[09:36] <JamesTait> Good morning all; happy Checklist Day! :-D
[10:06] <nik90> davmor2: hey, here's the click pakcage link https://www.dropbox.com/s/ur1wgkwpxbaua8i/com.ubuntu.clock_3.2.83_armhf.click?dl=0
[10:06] <nik90> davmor2: and the MP https://code.launchpad.net/~nik90/ubuntu-clock-app/implement-location-finding/+merge/231793 which has the descriptions of what to test
[10:08] <davmor2> nik90: I'll have a look for you in a minute :)
[10:09] <nik90> davmor2: yay thnx
[10:53] <brendand> nik90, do you know about the clock app test failures?
[10:53] <nik90> brendand: I have seen some flaky test failures during jenkins failures, but nothing concrete
[10:54] <nik90> brendand: is that what you are seeing as well?
[10:54] <nik90> s/jenkins failures/jenkins merges
[10:55] <brendand> nik90, on the dashboard -- http://paste.ubuntu.com/8745502/
[10:55] <nik90> brendand: yup that's the issue that I was seeing as well
[10:56] <nik90> brendand: is this consistent failures?
[10:56] <brendand> nik90, it seems to be consistent here
[10:57] <nik90> brendand: recently there was a change made in the jenkins environment where it required a wm to be installed in the xvfb environment to make clock tests pass. Does the QA dashboard setup also do it when running the tests?
[10:57] <brendand> nik90, failing in the same way for the past 30 images or so
[10:58] <brendand> nik90, no they run on device
[10:58] <nik90> oh
[11:00] <brendand> nik90, i'm going to have a closer look now
[11:00] <brendand> nik90, do you have a mako to reproduce it on?
[11:00] <nik90> brendand: ClockPage.isReady failed: True != dbus.Boolean(False, variant_level=1) , this variable isReady will only be set to true, if the clock app gets input focus.
[11:00] <nik90> I haven't run it on mako yet, let me try
[11:01] <nik90> I usually run the test suite on my desktop
[11:03] <brendand> nik90, i have a feeling i know what this could be
[11:04] <brendand> nik90, there is a focus bug triggered if you use passphrase security
[11:04] <nik90> ah, yeah that could potentially cause the failure
[11:05] <brendand> nik90, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1373985
[11:05] <brendand> nik90, it seems ci are using that during smoke testing
[11:06] <brendand> nik90, so clock app will never get focus
[11:06] <brendand> nik90, or might not in most cases
[11:06] <brendand> nik90, i'll see if they can change that
[11:07] <nik90> brendand: hmm, locally 4 out of 5 tests passed on my mako
[11:08] <nik90> 1 failed due to the focus issue, but I would say its more flaky..
[11:09] <brendand> nik90, no it's not flaky :)
[11:09] <brendand> nik90, flaky implies you don't know why it's failing
[11:09] <brendand> nik90, i do know
[11:10] <nik90> brendand: but that's the things, I expect 3 tests to fail due to the focus issue, but for me on my mako only 1 failed
[11:10] <nik90> the other 2 passed
[11:10] <brendand> nik90, if you refocus the dash it goes away
[11:10] <nik90> ah that could be it
[11:21] <nik90> brendand: in the qa dashboard, which channel should I be looking at? touch_stable?
[11:21] <brendand> nik90, yeah
[11:24] <davmor2> nik90: hmmm if clock is using location should it not trigger the trust-store to ask for permission to use location service?
[11:26] <davmor2> nik90: also is there an option to add seconds to the digital view?
[11:30] <brendand> davmor2, not necessarily. camera-app stopped doing that, on purpose
[11:30] <brendand> davmor2, maybe nik90 copied Kaleo's code to do that
[11:30] <brendand> although camera-app might be special
[11:53] <kalikiana> elopio: please review this one https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/pilotTracing/+merge/239575
[11:57] <davmor2> nik90: on a plus side it correctly locates me in Wolverhampton
[11:58] <davmor2> nik90: however I must travel to wyre piddle now and see if it guesses where I am then :)
[12:14] <DanChapman> t1mp, hey.. quick question, if a TextArea is set as read-only should you still be able to click hyperlinks and get the linkActivated signal?
[12:15] <t1mp> zsombi: ^
[12:33] <ahayzen> Hey, is jenkins paused? i haven't seen trigger-ci-job run for 19hrs?
[12:34] <popey> fginther: ^
[12:34] <popey> I know there was an overnight issue that the IS team were working on. dunno if that affected things.
[12:35] <ahayzen> ah probably that
[12:39] <ahayzen> popey, i hope your issue is as a result of a unity reset, otherwise i have no idea what is happening
[12:46] <popey> ahayzen: i think you're probably right
[12:47] <ahayzen> lecture time o/ ..... popey, i may be a little late to the standup as i have an exam
[12:52] <nik90> davmor2: It should trigger the trust-store, I did not copy any code from the camera-app. It prompted me with the dialog when I ran it the first time
[12:52] <nik90> davmor2: but nice it know that it found your location correctly
[12:55] <nik90> davmor2: and no there is no option to add seconds to digital view. If you think it is important, file a bug report and I will take it up with the designer.
[12:56] <davmor2> nik90: no it was more that it was there on analog view but not on digital
[12:57] <justCarakas> popey what is the IS team ? Islamic State Team ?
[12:57] <popey> now now
[12:57] <akiva-thinkpad> !politics
[12:58] <akiva-thinkpad> :P
[12:58] <popey> The people who look after the computers we break.
[12:58] <justCarakas> ah okey :p
[12:58] <justCarakas> o/ akiva-thinkpad
[13:25] <zsombi> DanChapman: that's a good question... tbh, I 've never checked that behavior with TextArea ro TextEdit... Check how TExtEdit behaves, and if that behavior differs from TextArea, file a bug!
[13:26] <DanChapman> zsombi: ok i'll try out TextEdit and see if it differs. Thanks :-)
[13:45] <mihir> nik90: I did kind of smoke test with your mp and it works I will do more and will let you know
[13:56] <mivoligo> mzanetti: hi
[13:57] <mzanetti> mivoligo: hi
[13:58] <mivoligo> mzanetti: sorry I was silent recently but I had pretty bad week
[13:58] <mzanetti> mivoligo: no worries... I've been away too
[13:59] <mzanetti> sad to hear you had some bad times though....
[14:00] <mivoligo> mzanetti: my daughter's bike has been stolen but I had hope in CCTV in the building
[14:00] <mzanetti> pff... /me doesn't believe in CCTV
[14:00] <mivoligo> mzanetti: here it's everywere
[14:00] <mzanetti> sure it is... but does it any good?
[14:00] <mzanetti> anyways
[14:01] <mivoligo> mzanetti: unfortunately turns out it has been broken since September
[14:02] <mzanetti> see... all it does is making good people feel uncomfy... I don't think anyone stealing a bike is dumb enough to smile into the camera
[14:02] <mivoligo> right
[14:02] <nik90> mihir: cool
[14:02] <nik90> davmor2: ah true
[14:03] <nik90> davmor2: not sure what the reasoning was to not show seconds in the digital view.
[14:03] <mivoligo> mzanetti: anyway, I'm working on the icon right now
[14:03] <mzanetti> cool :)
[14:04] <mivoligo> mzanetti: if I do it as an rectangle, will it be automatically clipped to Ubuntu shape on the phone?
[14:05] <mzanetti> mivoligo: yes, it will be on the phone. however, it won't be in some other places. so what I usually do is to make a rounded rect
[14:06] <mzanetti> mivoligo: just round corners a tiny bit
[14:06] <mivoligo> ok
[14:08] <mivoligo> mzanetti: are the sides clipped a bit as well or just the corners?
[14:09] <mzanetti> mivoligo: it'll also clip top/bottom a wee bit in the dash
[14:09] <mzanetti> as the aspect ratio isn't square
[14:09] <mivoligo> mzanetti: what sizes do we need?
[14:10] <mzanetti> you mean in pixels or in aspect ratio?
[14:10] <mivoligo> pixels
[14:10] <mzanetti> svg :P I'll export then various stuff when uploading to the store
[14:11] <mivoligo> I know but I wonder what's the minimal used size
[14:11] <mzanetti> I think atm its 256x256 but it did already change once
[14:11] <mzanetti> minimal used size kinda depends on the user settings/display pixel density etc
[14:12] <mivoligo> mzanetti: cos I'm doing it rather complicated :D
[14:12] <mzanetti> so the store wants me to upload a 256x256 pixel image at least atm
[14:12] <mzanetti> but again, what's displayed at the user's screen might differ significantly
[14:13] <mivoligo> mzanetti: ok, do you know what size is on the phone?
[14:14] <mzanetti> 7.5x8 grid units in the dash, 6.8x7 grid units in the launcher
[14:14] <mzanetti> or something along those
[14:14] <mzanetti> on a nexus 4 there's 16 pixels per grid units atm
[14:14] <mzanetti> iirc
[14:15] <mzanetti> I think if you use 256x256 pixels as base size we're good.
[14:15] <mzanetti> just make sure to not put essential details within a 10 pixel border to the top/bottom
[14:16] <mivoligo> ok
[14:37] <mhall119> zbenjamin: ping
[14:57] <elopio> kalikiana: will do.
[15:01] <elopio> kalikiana: for now, the toolkit deb is python 2 and 3.
[15:01] <elopio> so
[15:01] <elopio> maybe you should also add python-autopilot-trace
[15:05] <kalikiana> elopio: we run it with python3
[15:06] <kalikiana> afair we don't want to install everything twice
[15:06] <elopio> kalikiana: yes, but there are aa couple of projects that still use py2 and it would be useful for them.
[15:06] <elopio> we are about to remove the py2 everywhere
[15:06] <kalikiana> hmmmm
[15:06] <elopio> we are about to remove the py2 everywhere
[15:06] <elopio> so I'm not sure if it might be worth it.
[15:07] <zbenjamin> mhall119: pong
[15:07] <kalikiana> elopio: idea, I can try the | magic
[15:08] <elopio> kalikiana: not sure how that would help
[15:08] <kalikiana> elopio: we do that for qt where the packages in the latest release were renamed
[15:08] <kalikiana> qml-blabla
[15:08] <elopio> kalikiana: but how would you tell when you need the 2 or the 3 version?
[15:09] <kalikiana> so it's like qml-module-dragon | qtdeclarative-dragon-plugin
[15:09] <kalikiana> hmmmm
[15:10] <kalikiana> I guess it's not quite the same as you can have both py2 and 3
[15:10] <kalikiana> unlike old and new qt
[15:10] <elopio> kalikiana: also installing the py2 version won't hurt a lot, as we are already installing the 2 versions for a bunch of projects. But also not installing it wouldn't be bad, as the py2 projects will be updated and anyway they have always run without trace.
[15:11] <elopio> kalikiana: so do whatever feels good for you. The change looks correct.
[15:11] <kalikiana> elopio: I'm pushing a rev adding the py2
[15:11] <kalikiana> should be there now
[15:11] <elopio> kalikiana: ok.
[15:12] <elopio> kalikiana: +1. Thanks.
[17:18] <fginther> ahayzen, popey, sorry about the jenkins outage, I got to it right before your ping (then wen to have breakfast)
[17:19] <popey> thanks
[17:25] <popey> hi ahayzen  how was the exam?
[17:25] <ahayzen> popey, easy got 100% \o/
[17:25] <popey> \o/
[17:25] <ahayzen> popey, i did just have the same bug as you on the bus back... unity8 exploded while playing music and now the app cannot launch
[17:25] <snizzo> popey: any news regarding pioneer tshirt?
[17:26] <popey> snizzo: poke mhall119
[17:27] <popey> ahayzen: right, i believe there's a silo (13) currently under test for unity8 crashes
[17:27] <ahayzen> popey, ah good its been so unstable recently
[17:27] <snizzo> popey: ok, will do
[17:27] <popey> and we're aiming to get an image out the door over the next day or so to give to customer on monday
[17:27] <popey> yeah
[17:29] <popey> ahayzen: 17:18:52 < fginther> ahayzen, popey, sorry about the jenkins outage, I got to it right before your ping (then wen to have breakfast)
[17:30] <ahayzen> popey, i see things have landed so all good :)
[17:30] <popey> yeah
[17:31] <popey> did you see my bug about two albums have the same name?
[17:31] <popey> ah victor replied
[17:32] <ahayzen> popey, yeah its just us setting the wrong thing IIRC artist vs album vs albumArtist
[17:32] <popey> got it
[17:32] <popey> good good.
[17:32] <popey> Is there anything outstanding from jouni that you need?
[17:32] <ahayzen> popey, hopefully we can fix
[17:33] <ahayzen> popey, yeah all of the work items left for him + any walkthrough designs (lower priority than work items)
[17:33]  * popey pings him
[17:34] <popey> he's unavailable, so we need to mail him.
[17:34] <popey> I'll do that in a moment.
[17:35] <ahayzen> cool there are still some things we need to improve
[17:35] <ahayzen> eg slow thumbnailing on CardView ... may result in a rewrite of the CardView :/
[17:35] <popey> i notice that it loads the thumbnails slowly, yes.
[17:35] <popey> can we load the ones on screen first?
[17:35] <popey> seems to load all of them? even off-screen ones?
[17:36] <ahayzen> popey, yep limitation of the cardview at the moment
[17:37] <popey> ok
[17:37] <ahayzen> popey, Kaleo started looking at building a more intelligent CardView...but it is really tricky..i've had a few ideas to attempt to speed things up but not sure what the overhead is
[17:37] <popey> do we have a bug tracking it?
[17:37]  * popey can create one if not
[17:37] <ahayzen> don't think so
[17:37]  * popey does that
[17:38] <ahayzen> popey, basically the cardview is always fully loaded...offscreen items aren't destroyed and recreated
[17:38] <ahayzen> popey, which then has the affect of slowing the thumbnailer...and sort of second annoyance is that the thumbnailer starts rendering from the bottom lol
[17:38] <popey> haha
[17:38] <popey> brilliant
[17:39] <ahayzen> exactly
[17:39] <popey> bug 1387816
[17:39] <ahayzen> if it started from the top it probably wouldn't be as bad...but still bad
[17:39] <popey> set medium for now
[17:39] <popey> yeah.
[17:39] <ahayzen> cool it is basically top of my list :P
[17:40] <ahayzen> popey, but because of the way the cards are staggered it is really difficult to get it right and you can't then use the normal things like GridView
[17:41] <popey> right
[17:42] <popey> ahayzen: shall we crank a new click later today, or tomorrow morning?
[17:42] <ahayzen> popey, has anything changed?
[17:42] <popey> not much, wondered if you were planning on landing anything? ☻
[17:43] <ahayzen> popey, nothing has changed since the last click :) ... erm well i assume either me of victor will attempt to fix that artist/album issue and then any other bugs that people think of?
[17:43] <popey> Ok.
[17:44] <ahayzen> popey, i'll let you know if we need one doing :)
[17:44] <popey> Ok, magic.
[17:44] <popey> Nice to see rick posting about it
[17:44] <popey> Anything else to discuss?
[17:44] <popey> I'll mail jouni in a bit.
[17:44] <ahayzen> yeah really cool seeing people using it and the general positive responses :)
[17:45] <popey> Totally!
[17:45] <popey> Makes it worthwhile.
[17:45] <ahayzen> popey, don't think there is anything else we just need it to land aha
[17:45] <popey> heh
[17:45] <popey> Ok, have a good evening!
[17:45]  * popey goes to make food.
[17:45] <ahayzen> popey, you too o/
[17:45] <popey> o/
[17:52]  * balloons waves into the nether
[17:53] <ahayzen> balloons, o/
[17:55] <balloons> howdy ahayzen, time has flown by.. too much going on..
[17:56] <ahayzen> balloons, ...do i dear mention the chaos of music-app ci ? ...
[17:56]  * ahayzen hides
[17:57] <ahayzen> balloons, as in on device... on desktop is fine
[17:57] <balloons> ahayzen, well I was kind of asking for news like that; I've been out of the loop and it's time to return
[17:57] <ahayzen> balloons, same :)
[17:58] <ahayzen> balloons, did you say there was a new way of mocking WIP?
[18:03] <balloons> ahayzen, there is, follow along on the bug report
[18:04] <ahayzen> balloons, so do we not bother attempting to fix the current mess and work towards the new solution? ... and which bug number?
[18:16] <balloons> ahayzen, https://bugs.launchpad.net/ubuntu-app-launch/+bug/1376423
[18:16] <balloons> ahayzen, on the current mess, I would say best effort. I've been removing the stuff we put in where possible
[18:16] <balloons> music is a bit tougher as it really needs a clean env
[18:16] <ahayzen> yeah it does
[18:43] <mihir> balloons: were you able to look at kunal's MR for Jenkins failure ?
[18:45] <balloons> hey mihir I'm trying to catch back up, I just got back :-)
[18:45] <mihir> ahh no issues :D
[18:45] <balloons> no I haven't looked at it since we left dc.
[18:45] <mihir> when you get some free time :)
[18:45] <mihir> even I haven't got much time to work ,will catch up in weekend.
[18:45] <mihir> had to finish office backlog :)
[18:45] <balloons> indeed
[19:06] <ybon> popey: what about a "nearby" scope?
[19:06]  * balloons pokes popey to update topic
[19:10] <popey> ybon: i think I've already seen one of those being worked on...
[19:11] <ogra_> yeah, thats also not very innovative ...
[19:11] <ogra_> do a "far away" scope instead !!
[19:11] <ogra_> everyone has a nearby one
[19:11] <popey> balloons: better?
[19:11]  * balloons pokes popey  again, but ever so slighty harder .. err, wait yep, that's it
[19:13] <sverzegnassi> ajalkane, hi! How are you? I need some info about ubuntu-filemanager-app. Ping me when you have some time
[19:16] <ybon> ah, is there already one in the store?
[19:38] <balloons> mihir, nik90 it's finally happened! http://bazaar.launchpad.net/~autopilot/autopilot/trunk/revision/518
[20:36] <ajalkane> sverzegnassi: howdy, what info do you need?
[20:38] <sverzegnassi> ajalkane, hey! I have some questions about contenthub supports on ubuntu-filemanager-app
[20:38] <ajalkane> Sure
[20:38] <sverzegnassi> I've read the discussions on Bug #1315989, and ATM i've to "workaround" this situation
[20:39] <sverzegnassi> since i need to open pdf files from file manager, and i need to choose ContentType.Pictures to open a document
[20:40] <ajalkane> sverzegnassi: right... so at the moment File Manager can only be used to select pictures from the file system
[20:41] <ajalkane> But that should be easy to change. Basically File Manager should be possible to use for any kind of ContentType
[20:41] <sverzegnassi> i know, the funny thing is that it can be used to open any type of file. are there some news after that bugfixing?
[20:42] <ajalkane> Basically FileManager registers itself as a possible source for "Pictures". But actually you can select any type of file using it, as long as the application requesting the file asks for ContentType.Picture
[20:43] <ajalkane> Last time I heard there is not coming any support for "Any" file type
[20:44] <ajalkane> The best I can do, as I've understood, is to add all ContentHub ContentTypes to FileManager.
[20:44] <sverzegnassi> ATM we have "All" file type but, by doing so, docviewer-app can also read contacts
[20:44] <sverzegnassi> Vice versa, if u add support for ContentType.All in filemanager, the app will be available also in applications that requires a "contact" type
[20:45] <ajalkane> If I've understood correctly you can't register your application to be a "Source" for "All" file types. You can perhaps ask with your application for "All" file types. But it's been many months since I last talked about this with the people doing this
[20:46] <ajalkane> Basically you should be able to use FileManager to select "contact" types. They are for example "*.vcf" files
[20:46] <ajalkane> Docviewer should ask for "Document" types, and perhaps "Pictures"
[20:47] <ajalkane> Then it would get FileManager as one possible source, and perhaps Gallery
[20:47] <sverzegnassi> Yes, but seems that it is not possible to ask two type at the same time
[20:47] <sverzegnassi> types*
[20:48] <ajalkane> ah right... that's true in fact. Well the pictures choise is a bit silly for docviewer anyway?
[20:48] <sverzegnassi> These are the screenshots from the app: http://imgur.com/uG4nDj9,6aHGp4X,RR3K1YY,NMnk8eL#1
[20:48] <ajalkane> Althought that's a good point, why should an application not be allowed to select different kinds of content types
[20:48] <sverzegnassi> As you can see, no Documents peer available.
[20:49] <sverzegnassi> Yeah, that's the point. the actual way it manages files seems to be not so flexible
[20:50] <ajalkane> yep, I left FileManager's Content-Hub support in a bit "unfinished" state as I was waiting if Any file type could be supported
[20:50] <ajalkane> I can try and add a support for Documents etc. to FileManager now and we'll see if it works
[20:51] <sverzegnassi> it would be nice! I think I'll try to workaround this adding just "pictures" type. I hope there is no application that exports document type
[20:58] <ajalkane> I think there's none yet, at least in core. I'll make a branch now of FileManager exporting documents and maybe you can try if it works then.
[21:02] <sverzegnassi> Great! Thank you! If you need, I'm available for any help
[21:07] <ajalkane> sverzegnassi: try this branch https://code.launchpad.net/~ajalkane/ubuntu-filemanager-app/content-hub-all-sources
[21:08] <ajalkane> after installing the click package, you probably need to run this command on device:
[21:08] <ajalkane> /usr/lib/arm-linux-gnueabihf/content-hub/content-hub-peer-hook
[21:09] <sverzegnassi> ok
[21:09] <ajalkane> You can make sure that FileManager has been registered as source with:
[21:09] <ajalkane> gsettings list-recursively | grep content.hub.source.documents
[21:09] <ajalkane> If it lists filemanager you should be good
[21:10] <balloons> ajalkane, howdy! did you get help with autopilot tests? I've been away since dc so just following up
[21:12] <ajalkane> balloons: I did get the autopilot tests working, but I had to disable one that would need the bottom edge page to be brought up
[21:12] <ajalkane> so that's one thing that would need to be done... pulling up the Places from bottom edge and doing those two tests
[21:12] <balloons> ajalkane, that should be a simple conversion to call the header instead
[21:12] <ajalkane> it's not header, it's bottom edge pull up
[21:12] <balloons> ohh, sorry I misunderstood. you made it bottom edge
[21:12] <balloons> well, still, should be quite doable :-)
[21:13] <balloons> ajalkane, and that was related to my bug report about inputting a place right?
[21:13] <ajalkane> I took a look at clock application which has similar, so it's doable... just haven't had time to wrap my head around it yet
[21:13] <ajalkane> balloons: well it will be related to that, but first have to get the existing tests working :)
[21:14] <ajalkane> balloons: this is the current one that has to be solved before tackling the Places' text input field that we talked about in sprint: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1386850
[21:16] <balloons> ajalkane, awesome there is a bug
[21:16] <ajalkane> I'm really trying harder to file bugs for things I know I can't immediately solve :P
[21:17] <ajalkane> oh yeah and what we talked about is this bug: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1385364
[21:22] <sverzegnassi> ajalkane, it works! ( http://imgur.com/VyYf6UH,XpVGMEQ,WCJSuBq,n5P5oEF#2 )
[21:23] <ajalkane> sverzegnassi: great! When you have a branch working with your content-hub changes to get a document into docviewer, let me know. I think it's best I branch from that and re-do my changes on top of that to get exporting into docviewer working from FileManager (and other apps)
[21:24] <sverzegnassi> it would be nice to have some filters on file extensions, in FolderListModel, if it's possible to get the required content type from content hub
[21:25] <sverzegnassi> Sure! I think to push something on LP tomorrow, since I still have to finish some minor changes
[21:25] <ajalkane> I know :(. It's something that must be worked in future. The requesting application can't, unfortunately, specify them. So FileManager will have to do some guesses. But that's something for the future.
[21:26] <sverzegnassi> That's sad! Hope to see it in future! :-)
[21:27] <sverzegnassi> I'm gonna fix also this bug #1387026
[21:28] <ajalkane> alright, that's great! I did some work on that already but it wasn't finished. It'd be nice to be able to open pdfs and txt files from FileManager (and other apps)
[21:31] <sverzegnassi> Absolutely! I've seen there's already supports for this in filemanager. I want to see it working in docviewer-app ASAP!
[21:34] <ajalkane> Cool
[21:37] <sverzegnassi> ajalkane, thank you for your help! I'll let you know when I'll push the branch on LP (tomorrow, I suppose). Cya, good night!
[21:38] <ajalkane> good night sverzegnassi!
[22:18] <DS-McGuire> akiva-thinkpad, o/
[23:37]  * ahoneybun flashes his N4 with Ubuntu again
[23:39] <ahoneybun> mhall119: any news on the shirts?
[23:46] <ahoneybun> yay I have almost 30 users!
[23:49] <ahoneybun> akiva-thinkpad: ping


[00:18] <rick_h__> morning huwshimi
[00:18] <huwshimi> rick_h__: Hi :)
[02:39] <hatch> huwshimi:  hey
[02:40] <huwshimi> hatch: Hello!
[02:42] <hatch> so did you end up figuring out your issue or do u want me to take a look?
[02:43] <huwshimi> hatch: I haven't figured it out. It appears that when I attach the event it then gets triggered by the event's method that created it!
[02:44] <hatch> clickoutside is a complicated and resource intensive event because it is a 'fake' event
[02:44] <hatch> lemme pull down your code and take a look
[02:45] <huwshimi> thanks!
[02:51] <hatch> huwshimi:  do you guys get the show 'The Dome' there?
[02:51] <huwshimi> hatch: Not that I know of
[02:51] <hatch> count yourself lucky, it's horrible
[02:52] <hatch> some tv version of a steven king book - somehow it keeps getting renewed
[02:52] <huwshimi> :)
[03:10] <hatch> huwshimi:  quite the issue we have here heh
[03:10] <huwshimi> hatch: Yeah, fun times!
[03:12] <hatch> so I have a fix, but it sucks
[03:12] <hatch> if you wrap the clickoutside binding in a settimeout then it's ok
[03:13] <hatch> ohh I think I know how to fix it
[03:25] <hatch> ok I was wrong lol
[03:26] <huwshimi> hatch: oh :(
[03:26] <hatch> the problem is how the clickoutside event handler works....
[03:27] <hatch> it's a synthetic event
[03:31] <huwshimi> hatch: This is only an issue because the button that triggers the open is outside the menu
[03:35] <huwshimi> (That's not something that we can change, however)
[03:37] <huwshimi> hatch: Any other ideas?
[03:38] <hatch> huwshimi:  yeah so I'm thinking that's what will have to be done
[03:38] <huwshimi> hatch: The timeout?
[03:38] <hatch> the clickoutside handler is just not written properly
[03:38] <hatch> well that was the wrong thing
[03:38] <hatch> it's not written to be used as we are using it
[03:39] <huwshimi> hatch: OK, well thanks for taking a look.
[03:39] <hatch> huwshimi:  I guess right now in the interest of getting this landed is to render the menu for each token
[03:40] <hatch> er
[03:40] <hatch> render the ... in the menu
[03:40] <hatch> then when it gets clicked, show the real menu
[03:40] <hatch> it's a big performance smack but the real fix is going to take too much time
[03:40] <huwshimi> hatch: swap out button with the real one?
[03:40] <huwshimi> the
[03:40] <hatch> no I mean the ... is part of the menu
[03:40] <hatch> widget
[03:41] <huwshimi> hatch: Oh, so just render everything all the time?
[03:41] <hatch> when it's clicked then show the tooltip portion of the menu
[03:41] <hatch> yeah I think that's going to be the only way this will work, because the clickoutside will capture everything on the various up, down, bubble event phases
[03:41] <hatch> it doesn't filter them to only catch one way unfortunately
[03:42] <huwshimi> :(
[03:44] <hatch> it can be written to work as intended
[03:44] <hatch> unfortunately it'll take too long and I think we'd like to get this landed heh
[03:46] <huwshimi> hatch: Oh, I have a solution.
[03:46] <huwshimi> let me push this up
[03:48] <huwshimi> hatch: https://github.com/huwshimi/juju-gui/commit/370e1510bb44d483da21d36f82e9e477d09a578f
[03:49] <hatch> looking
[03:50] <huwshimi> actually that 'all' could be 'one'
[03:50] <hatch> so I was thinking something like that, but it's touching the DOM x number of times 'just incase'
[03:51] <hatch> hmm
[03:52] <hatch> huwshimi:  you know that's probably an alright idea if it uses a .one
[03:53] <huwshimi> hatch: Yeah, so this: https://github.com/huwshimi/juju-gui/commit/afd157fe01fc39488f0727335cb69b457bbb4d53
[03:53] <hatch> but it's a little bandaidie
[03:53] <huwshimi> yeah
[03:53] <huwshimi> hatch: Is it better than rendering all the widgets?
[03:53] <hatch> much :)
[03:54] <hatch> like orders of magnitude haha
[03:54] <hatch> good work
[03:55] <huwshimi> hatch: OK, I'm going to have some lunch and then add tests. This could probably do with another review tomorrow
[03:55] <hatch> yep for sure I'll review it in the am
[03:56] <hatch> thanks for staying on this :)
[03:56] <huwshimi> hatch: Thanks for that!
[03:56] <huwshimi> np
[03:56] <huwshimi> thank you
[04:07] <hatch> no problem
[08:13] <rogpeppe1> urulama: morning!
[08:16] <urulama> rogpeppe1: heya
[08:17] <urulama> rogpeppe1: how are we doing today, sir?
[08:17] <rogpeppe1> urulama: good thanks
[08:17] <rogpeppe1> urulama: and you?
[08:19] <urulama> rogpeppe1: a bit sleepy, but nothing that proper indian tea could not solve :)
[08:20] <rogpeppe1> urulama: :-)
[08:20] <urulama> rogpeppe1: could you take a look at Jay's PR, please ... https://github.com/juju/charmstore/pull/77
[08:20] <rogpeppe1> urulama: i'm just looking at it already
[08:44] <rogpeppe1> urulama: reviewed
[08:45] <urulama> rogpeppe1: thanks
[08:46] <urulama> rogpeppe1: i've set him towards the baseURL yesterday, but it was too late in the night to actually review the code
[09:13]  * urulama goes make some tea
[09:29] <urulama> rogpeppe1: ping, when you are ready
[09:29] <rogpeppe1> urulama: ok, one mo
[09:30] <rogpeppe1> urulama: ping :-)
[09:30] <urulama> https://plus.google.com/hangouts/_/canonical.com/roger-uros
[09:59] <urulama> frankban, rogpeppe1: give me 5min please, there's a post-man at the door
[10:00] <rogpeppe1> urulama: ok
[10:03] <urulama> frankban: wonna join for a blobstore talk?
[10:03] <frankban> urulama: sure
[10:04] <frankban> urulama: link?
[10:04] <urulama> https://plus.google.com/hangouts/_/canonical.com/roger-uros?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.r0oegfsr6b313oqhn3br43ltqs
[10:05] <urulama> oh, sorry
[10:05] <urulama> frankban: https://plus.google.com/hangouts/_/canonical.com/blobstore?hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.i8ktli6o0tbmsbe5qmtk62eaik
[10:43] <urulama> frankban, rogpeppe1: google does not like us :)
[10:44] <rogpeppe1> urulama: we're back in...
[11:01] <frankban> rogpeppe1: is it better to compare two *charm.Reference by value (e.g. *id1 == *id2) or by str repr (id1.String() == id2.Strng())?
[11:02] <rogpeppe1> frankban: value
[11:02] <frankban> rogpeppe1: cool thanks
[11:04] <rick_h__> morning
[11:06] <frankban> morning rick_h__
[11:06]  * frankban lunches
[11:15] <urulama> morning rick_h
[11:49] <bac> morning
[11:50] <rick_h__> morning bac
[11:51] <urulama> rogpeppe1, frankban: wrote minutes about blobstore. please take a look if anything is missing, lots of topics were covered :)
[11:51] <urulama> rick_h__: you have a minute to chat?
[11:51] <rick_h__> bac: this was funny last night. https://twitter.com/chcholman/status/501906093136969729
[11:51] <rick_h__> urulama: sure thing
[11:52] <rogpeppe1> urulama: looking
[11:52] <urulama> rick_h__: daily standup? https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0
[11:52] <rick_h__> loading
[11:52] <urulama> rick_h__: https://plus.google.com/hangouts/_/g4sy3treomztkk367qiounpbg4a
[11:53] <bac> rick_h__: so you know that person on twitter?
[11:53] <urulama> rick_h__: the first one was "borked", hope the second one works
[11:54] <rick_h__> urulama: trying
[11:54] <rick_h__> bac: so she's in a city nearby and we 'know' each other by knowing some of the same tech people
[11:54] <rick_h__> bac: never met
[11:54] <rogpeppe1> urulama: i hadn't heard of CADF before
[11:55] <urulama> rogpeppe1: ah, its just some standard for auditing in clouds
[11:55] <rogpeppe1> urulama: have you got a good overview link by any chance?
[11:55]  * rogpeppe1 is wary of standards
[12:08] <frankban> urulama, rogpeppe1, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/78 . anyone? thanks
[12:09] <rogpeppe1> frankban: on it
[12:09] <frankban> thanks
[12:17] <urulama> frankban: will be on it after a short lunch
[12:17] <frankban> urulama: thank you
[13:38] <hatch> morning all
[13:39] <rick_h__> morning hatch
[13:39] <hatch> kadams54:  so we also had a monstrous storm last night :) took the power out :)
[13:40] <kadams54> yippee
[13:45] <hatch> http://www.quora.com/How-good-is-YUI-as-an-open-source-JavaScript-library-compared-to-current-alternatives-2014?srid=dOo&share=1
[13:45] <rick_h__> " But now that JavaScript itself will soon have a built in module system and loader, the way forward is to embrace ES6 modules.
[13:45] <rick_h__> "
[13:45] <rick_h__> "will soon" bothers me
[13:46] <rick_h__> :( on the lack of noting the niceities of a deep event system, common api across code, etc.
[13:46] <rick_h__> but yea, it's running its course
[13:47] <hatch> heh there is no way we'll be able to use es6 modules/loader any time soon
[13:47] <hatch> maybe 1yr
[13:47] <rick_h__> maybe
[13:48] <hatch> My next personal project whatever that may be will not use YUI so I can try and find a good collection of modules to provide a similar functionality
[13:48] <hatch> so far I can't find anything that has the event stack :/
[13:48] <hatch> those darn events.....
[13:49] <hatch> maybe I could write something
[13:49] <rick_h__> yea, I bet you still end up writing a lot more code
[13:49] <rick_h__> it's kind of sad that there's not more of a desire to modernize YUI vs deprecate
[13:49] <hatch> Y! is too busy buying mobile companies....lol
[13:59] <luca> rick_h__: just rebooting
[14:43]  * rick_h__ heads back to the house
[14:44] <hatch> kadams54:  did you end up doing the review of my branch yet?
[14:44] <kadams54> hatch: in progress. I'm also having problems with changeState in my branch.
[14:45] <kadams54> So I'll finish off QAing yours and then pester you with state questions ;-)
[14:47] <hatch> yeah sure np
[14:47] <hatch> changeState is really easy to understand and debug once you wrap your head around how it works
[14:47] <luca> hatch: jcastro kadams54 btw is the uncommitted progress icon just the yellow triangle? The yellow triangle technically means pending...
[14:50] <hatch> luca:  right now there is no uncommitted progress icon
[14:51] <hatch> there is the pending icon but that's after juju has ACK'd it and it's really pending
[14:51] <hatch> but there is this odd place between uncommitted and the ACK
[14:51] <hatch> which I have seen be up to 30s
[14:51] <hatch> where it's not pending or not uncommitted
[14:56] <rick_h__> jujugui call in 5
[14:56] <rick_h__> or 4
[14:56] <rick_h__> kanban away please
[14:58] <urulama> rick_h__: i get "this party is over" :(
[14:59] <rick_h__> jujgui https://plus.google.com/hangouts/_/gw35roelf4huu6vmyvyl3z6rgea?authuser=1
[14:59] <luca> hatch: I see, thanks
[14:59] <rick_h__> see if this works
[15:00] <hatch> I'm in the normal standup room
[15:00] <hatch> with ant and matt
[15:00] <rick_h__> ok, it's working now
[15:00] <rick_h__> just doens't like me
[15:00] <rick_h__> jujugui standup time!
[15:00] <urulama> rick_h__: https://plus.google.com/hangouts/_/canonical.com/daily-standup?hceid=cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.j0rk5d371ph8331ijtf48t2uj0
[15:00] <urulama> rick_h__: try this one
[15:01] <rick_h__> bac: ^
[15:01] <bac> oops
[15:01] <bac> joining
[15:03] <bac> having trouble
[15:10] <hatch> rick_h__:  are all of the cards in the ready to code of equal priority? It seems like some of these may be able to be pushed to post 1.0
[15:10] <bac> jujugui: sorry, i cannot get into the hangout
[15:11] <hatch> it's over
[15:11] <hatch> :)
[15:17] <bac> hatch: miss anything good
[15:17] <bac> ?
[15:18] <hatch> rick_h__:  did some break dancing to lady had a little lam
[15:18] <hatch> lamb
[15:20] <kadams54> guihelp: where is views.Templates originally defined/setup?
[15:20] <rick_h__> hatch: we can debate over them
[15:20] <rick_h__> hatch: but they all seemed 1.0 stuff when I looked monday
[15:20] <rick_h__> kadams54: it's built from the /lib/templates or something, /me pulls up a browser to look
[15:21] <rick_h__> kadams54: sorry, the things in app/templates is built into lib/templates.js as compiled handlebars
[15:22] <rick_h__> kadams54: what are you trying to do?
[15:24] <urulama> jujugui: bye, see you later
[15:59]  * rick_h__ goes to get lunch
[16:27] <hatch> jujugui do we have any assets or mockups for ""handle changes from the delta stream and alert with conflicts in ecs"" ?
[16:27] <kadams54> not that I've seen
[16:27] <rick_h__> hatch: no
[16:28] <hatch> I can work on the backend of it np, but I'll send something to luca about it I guess
[16:29] <rick_h__> hatch: yea, I think that card is one that breaks into smaller. we need to plan out where/how to keep the 3 results (current, ghost, delta) and how to resolve that
[16:29] <hatch> yep ok on it
[16:44] <rick_h__> hatch: thanks for the great qa notes on huw's branch!
[16:44] <hatch> :) np
[16:48] <Makyo> jujugui it appears we can't clear config changes, because we don't retain the old ones, just a list of what has changed.  Any thoughts?
[16:48] <rick_h__> Makyo: chat with hatch as I think we need it for that as well
[16:48] <hatch> hmm
[16:48] <rick_h__> Makyo: hatch quick chat?
[16:48] <hatch> yeah.....standup?
[16:49]  * rick_h__ will try again wheee
[16:49] <hatch> if it says it has ended just click refresh a couple times
[16:49] <rick_h__> went to FF
[17:02] <frankban> rogpeppe1: so, should we return nil, nil in a meta endpoint if, for instance, it makes sense only for charms and a bundle is passed?
[17:03] <frankban> rogpeppe1: IIUC, if the meta result is nill, then the result is not included in meta when include is used
[17:04] <rogpeppe1> frankban: yes, that's right.
[17:04]  * rogpeppe1 needs to stop now. wedding anniversary requires prompt stopping :)
[17:04] <rogpeppe1> g'night all
[17:05] <frankban> rogpeppe1: good night
[17:06] <rick_h__> happy anniv rogpeppe1 !
[18:23] <hatch> jcsackett:  thnks for the review, I replied
[19:20] <hatch> kadams54:  review?
[19:21] <kadams54> hatch: yeah, still wrestling with a local env
[19:21] <hatch> hmm, what issues are you having? I've probably had it before haha
[19:21] <kadams54> hatch: the behavior was funky when I ran through, so I wanted to verify and make sure it wasn't just my setup.
[19:22] <hatch> oh ok, what was happening?
[19:23] <kadams54> hatch: the machine would go through OK, but the bare metal container would be left as uncommitted state. I had to force a re-render on the container token before it properly displayed the state.
[19:23] <hatch> oh ok that's possibly a real bug
[19:23] <hatch> actually probably is
[19:23] <kadams54> hatch: So I ran through the QA instructions, deployed, confirmed, waited, then saw the machine change from uncommitted to deployed. But the container stayed as uncommitted.
[19:24] <hatch> the uncommitted state rendering is kind of implemented funky
[19:24] <hatch> the bare metal cannot be uncommitted so that's definitely a bug
[19:24] <kadams54> As far as my local env woes… I think it's the same thing jcsackett's seen. I've run the juju set command, it seems to run successfully, then I refresh in the web browser and nothing is running anymore.
[19:25] <kadams54> Annnnnddd now it works fine. Of course.
[19:25] <hatch> are you juju setting the source?
[19:25] <jcsackett> kadams54: on precise you have to use sha to set the source.
[19:25] <jcsackett> On trusty you can use branch.
[19:25] <hatch> it takes time to pull down and build the source
[19:25] <kadams54> Hmm, I'm on precise, but it just worked with the branch…
[19:25] <hatch> and what jcsackett just said
[19:26] <hatch> ( which I also learnt just recently)
[19:26] <kadams54> hatch: yeah, I gave it 10 minutes :-)
[19:26] <jcsackett> hatch, I'm not sure I'm +1 with your reply; you say it's overkill to put update id on the machine list, but that's the only place you use the method.
[19:26] <jcsackett> Seems like overkill to patch, to me.
[19:27] <hatch> I just figure because it's a limitation of the library and not of our code it should go to the lib
[19:27] <hatch> kadams54:  can you write that bug in the PR and I'll look into it after lunch
[19:27] <jcsackett> I agree it's unnecessary to create our own extension, but can't you just add update I'd for the machine list? We already have one as an object, right?
[19:27] <kadams54> hatch: Yeah, now that I've finally managed to confirm it :-)
[19:28] <kadams54> hatch: FYI, I added the changeState code pretty much as it is in scale-up.js, for navigating to machine view… but it seems to do nothing. That is, if you're in service view when you click on the link, you'll still be in service view.
[19:29] <hatch> jcsackett:  no LML has an internal ID map which is only updated on add and remove so you cannot update the id of a LML object and still have it functional
[19:29] <jcsackett> Aaaah.
[19:29] <jcsackett> That's the missing part of info.
[19:29] <hatch> kadams54: does the service view bubble the change up to the browser.js?
[19:29] <hatch> jcsackett:  oh sorry :)
[19:29] <hatch> I'll add that to the PR
[19:30] <kadams54> Ah, good question. I'll make sure it does.
[19:31] <hatch> kadams54:  typically you will include the steps to reproduce the QA failure
[19:31] <hatch> even though I know how....just for good measure
[19:31] <jcsackett> ok. hatch, knowing that, I'm good. Can you add a test for the patch's added method, though?
[19:31] <hatch> jcsackett:  I can
[19:31] <hatch> plz add to the PR
[19:33] <kadams54> hatch: done.
[19:33] <jcsackett> Will do. Thanks, hatch.
[19:33] <hatch> thanks - I'll get on that right after lunch
[19:33] <hatch> I'm trying to figure out a good strategy to port the gui to Dart without rewriting :D
[20:55]  * rick_h__ runs away night all!
[21:18] <hatch> cya rick_h__
[21:18] <hatch> oh that was like 25mins ago
[21:18] <hatch> heh
[21:37] <lazyPower> heyyyyyy hatch
[21:37] <hatch> wassup boi!
[21:38] <lazyPower> Wanna be a peach and proof something for me? (rough video cut, but almost done)
[21:39] <hatch> yeah sure
[21:39] <hatch> I'm just finishing up a review
[21:39] <lazyPower> https://www.youtube.com/watch?v=CEfFy6tODrQ knew I could count count on ya! ty ty
[21:39] <lazyPower> oooo you're doing a charm review?
[21:42] <hatch> haha no, js review
[21:42] <hatch> lazyPower:  I'll start looking at it in about 5
[21:43] <lazyPower> no rush :) and ooohhh yeah. i almost got excited there for a second.
[21:48] <hatch> lazyPower:  your quiet...
[21:48] <hatch> can you preamp the audio?
[21:48] <lazyPower> that has been preamped
[21:49] <lazyPower> Whats your youtube volume at perchance?
[21:49] <lazyPower> i preamped it and ran it through a compressor
[21:49] <hatch> 100% heh
[21:49] <lazyPower> wow
[21:49] <hatch> and my laptop is also at 100%
[21:49] <lazyPower> really?
[21:49] <lazyPower> oi
[21:49] <hatch> :) maybe it's just my computer
[21:49] <hatch> I'm running in a vm
[21:49] <lazyPower> let me solicit additional feedback - you're on mac right?
[21:50] <hatch> I'm on a mac, in Ubuntu
[21:50] <hatch> lol
[21:50] <hatch> maybe my soundcard default volume is set to low :)
[21:50] <hatch> anyways, continuing
[21:52] <lazyPower> hatch: ty for the feedback though - if i need to up the amps on the audio i'll try to do that on teh final copy
[21:52] <lazyPower> s/amps/decibels/
[22:02] <hatch> lazyPower:  notes pm'd
[22:04] <lazyPower> Thanks man! Much appreciated.
[22:09] <hatch> anytime :)
[22:10] <hatch> When it's done let me know so I can spread it among my network too
[22:10] <hatch> anything to get the juju love out there
[22:39] <jcsackett> hatch: how does one turn the simulator off in gui?
[22:39] <jcsackett> it's massively mucking me up.
[22:39] <hatch> ctrl s
[22:39] <jcsackett> thank you.
[22:39] <hatch> "One does not simply....turn the simulator off"
[22:39]  * jcsackett sort of wants the simulator off by default
[22:39] <hatch> jcsackett:  you can also set it to off in the config-debug.js file
[22:39] <jcsackett> yes, but then i have to fix that before i commit.
[22:39] <hatch> I've been asking for that but always get voted down
[22:40] <jcsackett> i might bring it up on friday (again)
[22:40] <hatch> come to the dark siiiide
[22:40]  * hatch hands you a pin
[22:40] <jcsackett> it is *so* annoying when you're dealing with machine creation/unit creation etc.
[22:40] <hatch> yop
[22:40] <hatch> I'll +1 your vote to banish
[22:41] <hatch> now and convince others behind closed doors like a good politician and make it look like a true democracy when we vote
[22:41] <hatch> lol
[22:41] <hatch> rofl
[22:41] <hatch> oh I crack myself up
[22:53]  * jcsackett laughs
[23:06] <huwshimi> Morning
[23:08] <hatch> morning huwshimi
[23:09] <hatch> lots of comments on your branch but good to land once those are taken care of (they are all tidy up things)
[23:20] <rick_h__> morning hju
[23:20] <rick_h__> mornin huwshimi
[23:20] <rick_h__> tab completion works better when you type correctly :/
[23:21] <huwshimi> haha
[23:24] <hatch> :D
[23:41] <huwshimi> rick_h__: If you happen to have the time, I'd love another review of the more menu: https://github.com/juju/juju-gui/pull/498
[23:43] <rick_h__> huwshimi: will look in a sec here.
[23:44] <hatch> huwshimi:  thanks for making those fixes
[23:44] <hatch> be sure to rebase before landing :)
[23:47] <huwshimi> hatch: Thanks for the review, yeah, lots of changes in there :)
[23:47] <hatch> heh mine is the same, I'm going to have to have fun rebasing that one