[08:33] <Saviq> mornin'
[08:33] <Saviq> what did I miss? ;)
[08:36] <Zhenech> [GitHub] Subscribed to credativ/puppet-anysyncd notifications
[08:36] <Zhenech> ups
[08:45] <mhr3> Mirv, btw do you have mediascanner2 in the qt5.2 transition? we added a qml plugin to it very recently, so it probably needs rebuild
[08:45] <tsdgeos> Saviq: not much i'd say
[08:46] <Saviq> mhr3, does it use private headers? if not - it should not need rebuilding
[08:46] <Saviq> tsdgeos, cool beanz
[08:47] <tsdgeos> Saviq: i don't think what Thomi says makes any sense, or at least any sense for my problem
[08:47] <tsdgeos> Saviq: so i guess all i have left is debug this stuff myself?
[08:47] <mhr3> Saviq, no, but doesn't it need to relink against the core5a binary?
[08:47] <Saviq> mhr3, ah, right, damn ABI break
[08:48] <Saviq> tsdgeos, so you think your issue is not what I described?
[08:49] <tsdgeos> Saviq: you say objectName evaluation is "not taken into account" or something
[08:49] <tsdgeos> i say "the object is simply not there"
[08:49] <tsdgeos> or not updated at all
[08:49] <tsdgeos> i can scroll a list and autopilot vis will still show the old children
[08:49] <tsdgeos> even after restarting autopilot vis
[08:50] <Saviq> tsdgeos, I might not have read into your email properly
[08:50] <tsdgeos> well i did not add that extra info (the objects not updating)
[08:50] <tsdgeos> but still it can't be waht you say
[08:50] <tsdgeos> since i have
[08:51] <tsdgeos> objectName: foo + index
[08:51] <tsdgeos> and all children names are
[08:51] <tsdgeos> fooNumber
[08:51] <tsdgeos> and the index is not really changed there
[08:51] <tsdgeos> so all items have the evaluation
[08:51] <tsdgeos> just one at least is missing
[08:52] <tsdgeos> of course it still could be something similar to what you say but i don't think it may be the easiest explanation
[08:53] <Saviq> tsdgeos, what I was saying (the problem we encountered) was that ap managed to select a object0 before it became object1 after the binding got updated
[08:54] <tsdgeos> Saviq: right, but how can that cause object0 not existing at all?
[08:55] <Saviq> tsdgeos, sure, it can't
[08:55] <tsdgeos> and that's what i'm seeing
[08:56] <Saviq> tsdgeos, so yeah, as I said I might not have read your email properly - was Sunday evening after all ;D
[08:56] <tsdgeos> sure :-)
[08:57] <Saviq> tsdgeos, so yeah, please reply to my email saying I'm full of shit
[08:57] <Saviq> oh yay, no WiFi after flashing...
[08:58] <Mirv> mhr3: incidentally, I found out about mediascanner2 on Friday and I've just built it
[08:59] <mhr3> Mirv, very well
[08:59] <tsdgeos> Saviq: so back to my question, do you have any clue how/where to start debugging that?
[09:01] <Saviq> tsdgeos, /me looks
[09:09] <tsdgeos> Saviq: ah, and we discovered some compiz regression that made some tests fail
[09:09] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/vjog_compiz_workaround
[09:09] <tsdgeos> basically it's not obeying window sizing sometimes
[09:11] <Saviq> tsdgeos, hmm after applying the patch on top of new-scopes-cleanup it doesn't seem to unlock the screen even... does it work for you?
[09:12] <tsdgeos> it was defenitely working on friday
[09:13] <tsdgeos> yeah works today too
[09:13] <tsdgeos> http://paste.ubuntu.com/7066602/
[09:14] <tsdgeos> Saviq: i'm doing this with 5.0 though
[09:15] <Saviq> tsdgeos, I'm on 5.0 currently, too
[09:15] <tsdgeos> ok
[09:15] <tsdgeos> and you get stuck on greeter when rnning autopilot?
[09:17] <Saviq> tsdgeos, yes
[09:17] <tsdgeos> try again? :D
[09:17] <Saviq> tsdgeos, looks like it's looking for the home scope and fails
[09:17] <tsdgeos> Saviq: are you up to date?
[09:17] <tsdgeos> or maybe i didn't push
[09:17] <tsdgeos> that can very well be
[09:17] <Cimi> tsdgeos, did you have any luck with autopilot?
[09:18] <Saviq> tsdgeos, ah, actually it didn't switch to apps scope on startup
[09:18] <Saviq> tsdgeos, s/didn't/doesn't/
[09:18] <tsdgeos> Cimi: well, i thinking i have found an autopilot bug, proving it is hard though
[09:18] <tsdgeos> Cimi: did you manage to get past the "everything fails" point?
[09:19] <tsdgeos> Saviq: nothing left for pushing here
[09:19] <Cimi> tsdgeos, I stop when you told me you were dealing wih it :)
[09:19] <tsdgeos> Cimi: ok
[09:19] <Cimi> I can try again now
[09:19] <Saviq> tsdgeos, yeah, the "switch to apps on startup" seems somewhat flaky :/
[09:20] <Cimi> tsdgeos, just read your mail
[09:21] <tsdgeos> Saviq: weird, never had that problem on friday
[09:21] <Cimi> tsdgeos, when did this dashcategory error start?
[09:21] <tsdgeos> Cimi: i have no clue
[09:21] <Cimi> tsdgeos, it's a new scopes error or also in trunk?
[09:26] <tsdgeos> Cimi: the test works in trunk but the whole QML tree is different, so that proves nothing
[09:48] <Saviq> biab
[09:56] <om26er> tsdgeos, are you taking new-scopes introduced regressions as bugs or should I wait for it to first land in trunk ?
[09:57] <tsdgeos> om26er: if it is indeed a regression/bug, sure
[09:58] <om26er> sure, the scrolling in the Apps scope have apparently become much jerky on my mako -- will report in lp.
[11:17] <Cimi> tsdgeos, ok they fail for trunk here as well
[11:17] <Cimi> tsdgeos, on a different machine
[11:17] <Cimi> tsdgeos, I have this QQuickLoader.isCurrent failed error
[11:18] <tsdgeos> no idea :
[11:18] <tsdgeos> you'll have to try to dig more yourself
[11:18] <tsdgeos> otoh it should not be that hard for us to run the autopilot tests
[11:18] <Cimi> yeah :(
[11:36] <Cimi> tsdgeos, are you trying to
[11:36] <Cimi> understand as well?
[11:36] <tsdgeos> Cimi: no, it works for me, i'm fixing the tests in new-scopes that don't work because of the code changes
[11:37] <Cimi> @unity who else has issues with autopilot run unity8 ?
[11:37]  * mzanetti has *always* issues with AP :D
[11:37] <Cimi> mzanetti, can you run
[11:37] <mzanetti> Cimi: I fiddled a while with it last week and got it to run eventually
[11:37] <Cimi> autopilot run unity8 > log
[11:38]  * mzanetti tries
[11:38] <Cimi> then a nice grep FAIL log | pastebinit :)
[11:44] <mzanetti> Cimi: anything you're interested in particular?
[11:44] <mzanetti> Cimi: I don't want to run all of them now because they either fail or It'll mess up my desktop if I kill my notification system
[11:50] <Saviq> tsdgeos, Cimi, the QQuickLoader.isCurrent thing, AFAICT, is dash not switching to Apps on startup
[11:51] <Cimi> I'm replying to a mail, will be back soon :)
[11:51] <Cimi> and reply to you :)
[12:05] <Cimi> Saviq, so we have a fix for that
[12:05] <Cimi> ?
[12:21] <Saviq> Cimi, no, that's something I found just today with tsdgeos's cleanup branch
[12:21] <Cimi> Saviq, weird
[12:21] <Cimi> Saviq, I have that bug with trunk
[12:21] <Cimi> ;)
[12:22] <Saviq> Cimi, well, if you're going "autopilot run unity8", you're not actually running trunk most probably, but the system-wide installed version
[12:22] <Saviq> Cimi, you need `make -C install`, `PYTHONPATH=tests/autopilot autopilot run unity8` to run the local build
[12:23] <Saviq> always check out what autopilot says ni "loading tests from..."
[12:23] <Saviq> in
[12:24] <Cimi> Saviq, oh!!
[12:24] <Cimi> Saviq, ok, nevermind :D
[12:54] <tsdgeos> Saviq: actually now i'm having a problem with the correct scope not being loaded, it's sad, isCurrent is true, but it's not really the current one, having a look
[13:10] <mzanetti> didrocks: when you have some time, could you please review the packaging changes in here and related branches? https://code.launchpad.net/~mzanetti/unity-api/new-screenshot-and-focusing-api/+merge/199810
[13:11] <didrocks> mzanetti: sure, will do in ~20, that's ok?
[13:11] <mzanetti> didrocks: not urgent at all
[13:11] <didrocks> ok ;)
[13:43] <didrocks> mzanetti: hum, where are your packaging change? :)
[13:43] <didrocks> or the diff isn't correct?
[13:46] <mzanetti> didrocks: well, it's only bumping unity-application-iml version
[13:47] <didrocks> mzanetti: ah ok, that part that we marshmall
[13:47] <mzanetti> didrocks: and the others bump their "Provides" and "Requires" accordingly
[13:47] <mzanetti> so yeah, that's the question. is that enough?
[13:47] <didrocks> mzanetti: yeah, that's perfect :)
[13:47] <mzanetti> nice, thanks
[13:48] <didrocks> mzanetti: yw, commented (to +1)
[13:48] <mzanetti> purrfect
[13:48] <mzanetti> greyback: jfi ^
[13:48] <greyback> mzanetti: ack from me so
[14:00] <kgunn> mhall119: mornin', hey i put in for 2 sessions at uds...and they're still in "proposed" can you help get them on the calednar?
[14:00] <kgunn> http://summit.ubuntu.com/uds-1403/kgunn72/meetings
[14:13] <mhall119> kgunn: what track?
[14:13] <mhall119> kgunn: you need to get a track lead to approve it and schedule it
[14:13] <mhall119> track leads are listed here: http://summit.ubuntu.com/uds-1403/tracks
[14:15] <kgunn> mhall119: thanks
[14:20] <MacSlow> mterry, did you have better luck with the newer version of the egl-spinner or didn't you try yet?
[14:20] <mterry> MacSlow, I didn't try yet...  Let me do that
[14:20] <elopio> tsdgeos: is there something I can do to help with the autopilot updates?
[14:21] <tsdgeos> elopio: i'm on it, just need some more time to debug some stuff
[14:21] <elopio> tsdgeos: ok, let me know if you need a hand.
[14:21] <MacSlow> mterry, vanvugt tried it earlier today on his mako too and it worked there too.
[14:21] <tsdgeos> tx
[14:22] <mterry> MacSlow, hrm
[14:22] <MacSlow> mterry, I hope you'll have better luck this time around
[14:22] <MacSlow> mterry, when it crashes again a backtrace would be helpful if you can get one
[14:23] <mterry> MacSlow, I did find where it crashed...  But will see if it happens again
[14:23] <mterry> MacSlow, works like a charm  :)
[14:24] <MacSlow> mterry, rev7 with the text-rendering?!
[14:24] <mterry> MacSlow, yup.  might as well merge that into the shared USC branch then
[14:24] <MacSlow> mterry, awesome!
[14:24] <mterry> MacSlow, has Christina seen this yet / had a chance to comment?
[14:25] <mterry> MacSlow, I know she was OK with the general idea, but curious about details
[14:25] <MacSlow> mterry, I cc'ed here in the last email (~30 minutes ago) which has a link to the latest video... so I hope she'll reply with some feedback
[14:25] <mterry> cool
[14:26] <MacSlow> mterry, from my side it basically just cleaning up the code and making it nicer to maintain... so I would (after that) hand off to you and trun back to notification-duties.
[14:27] <mterry> MacSlow, sure
[14:27] <MacSlow> mterry, although I _love_ GL! :)
[14:27] <mterry> :)
[14:27] <mterry> MacSlow, well if Christina wants changes you can dive back into it  :)
[14:28] <MacSlow> mterry, I take any excuse to do that :)
[14:28] <MacSlow> kgunn, you didn't read that *waves.hands* ;)
[14:33] <greyback> kgunn: in "alsamixer", if you hit F5, there's a "mic boost" option, maybe you can turn it down?
[14:34] <Cimi> mhr3, dednick btw, tomorrow we can meet 1pm in front of brixton tube station
[14:35] <dednick> Cimi: ok. cool
[14:39] <mhr3> Cimi, ok
[14:42] <Cimi> kgunn, if you want to stay in mumble, maybe we can try different settings, or later when you have time
[14:44] <Cimi> tsdgeos, Saviq
[14:44] <Cimi> cimi@vostro:~/Development/unity8/new-scopes-cleanup/builddir$ grep -B 3 FAIL LOG | pastebinit
[14:44] <Cimi> http://paste.ubuntu.com/7067998/
[14:45] <tsdgeos> thats' bad
[14:45] <tsdgeos> stuff like test_passphrase_screen_wrong_password should be passing
[14:45] <Saviq> yeah, something weird with shift, too - "FFFFFf" instead of "FFFFFF"
[14:46] <tsdgeos> i'm down to http://paste.ubuntu.com/7068005/ failing
[14:46] <Cimi> tsdgeos, some context?
[14:46] <Cimi> grep -B3 ?
[14:46] <tsdgeos> Cimi: what do you mean some context?
[14:47] <Cimi> tsdgeos, apart the error
[14:47] <Cimi> sorry
[14:47] <Cimi> the name of the failing test
[14:47] <Cimi> tsdgeos, I run tests  with > log
[14:47] <tsdgeos> Cimi: they fail because they are checking toatlly wrong stuff
[14:47] <Cimi> then I grep -B3 FAIL log
[14:49]  * greyback needs to run to bank, bbiab
[14:49] <mzanetti> dandrader: so, this Model of apps, that's still the ApplicationManager, right?
[14:51] <kgunn> Cimi: i got about 10 min...wanna try real quick
[14:51] <kgunn> mumble
[14:52] <tsdgeos> and actually the 4 are basically the same
[14:52] <tsdgeos> the preview opening doesn't work
[14:52] <tsdgeos> because we changed the way preview opening works
[14:52] <dandrader> mzanetti, no, it's a simple ListModel of qml items
[14:52] <dandrader> mzanetti, it's a list model of MirSurfaceItems (qquick items holding mir surface gl textures)
[14:52] <dandrader> mzanetti, then ListView has a Window.qml delegate that takes a suface and reparent it to itself
[14:53] <mzanetti> dandrader: ah, but shouldnt the MirSurfaceItems be the Delegates?
[14:53] <mzanetti> and the model still hold ApplicationInfo objects?
[14:53] <mhr3> Cimi, l4d or l4d2? :)
[14:54] <mzanetti> dandrader: at least that's what I though of when doing the right edge
[14:54] <Cimi> mhr3, l4d2
[14:54] <mzanetti> dandrader: so all we'd need to do in that case would be to replace "Image" with "MirSurfaceItem" in the SpreadDelegate.qml
[14:54] <dandrader> mzanetti, no, MirSurfaceItems are created from the qpa/cpp/appMan side. it essentially wraps a gl texture that's bound to a mir (EGL) surface
[14:55] <dandrader> mzanetti, so that the qml side can manipulate that texture as a QQuickItem fairly easily,
[14:55] <mzanetti> ok... so the ApplicationInfo objects will become MirSurfaceItems?
[14:55] <dandrader> mzanetti, no, they're are still there
[14:55] <mzanetti> but then we have 2 models
[14:56] <dandrader> mzanetti, yes
[14:56] <mzanetti> ok... I think I understand
[14:56] <mzanetti> but is that really way to go?
[14:56] <dandrader> mzanetti, the concept of an application is one thing, more abstract, a client surface is another one
[14:57] <mzanetti> yeah.
[14:57] <mzanetti> that's why I said, the MirSurfaceItems should be the delegates
[14:57] <dandrader> mzanetti, and stage wants to arrange an shuffle around surfaces/client windows
[14:57] <mzanetti> but the stage still needs to represent all running apps
[14:58] <mzanetti> and not some other model of surfaces
[14:58] <mzanetti> dandrader: so we can't create such MirSurfaceItems in QML as we like?
[14:58] <mzanetti> for example, one in the app-spread, one in the runningappsgrid etc
[14:59] <mzanetti> but still showing the same surface
[15:03] <dandrader> mzanetti, at the moment no. mir tells the QPA that there's new surface and then QPA creates a MirSurfaceItem that makes use of it, so that the mir surface can be used by the QML scene
[15:03] <dandrader> mzanetti, then QPA informs the QML side that there's a new MirSurfaceItem available
[15:04] <dandrader> mzanetti, QML side (unity8) then reparents it to the view delegate to have it on the scene
[15:04] <mzanetti> dandrader: what I mean is this: I'm ok if we need to create such MirSurfaceItems somewhere in C++, but I don't think we should only have that model available in qml... Can't we wrap that somehow? So that I can just say this in QML:
[15:04] <mzanetti> AppSurface { appId: "foobar" }
[15:05] <mzanetti> and that then just finds its MirSurfaceItem somehow and paints its contents in the AppSurface {} item
[15:05] <mzanetti> so we can still do things like:
[15:05] <mzanetti> ListView { model: ApplicationManager; delegate: AppSurface { appId: model.appId } }
[15:06] <mzanetti> otherwise this sounds like a hugely complex thing to me to match surfaces with apps in QML all over the place
[15:07] <dandrader> mzanetti, I think it would be good if you checked out the current stage code to get an idea on how that all fits together
[15:08] <mzanetti> dandrader: what is the current stage code?
[15:08] <dandrader> mzanetti, lp:~unity-team/unity8/mirCompositor
[15:08] <mzanetti> ok. I'll check it out
[15:10] <dandrader> mzanetti, also an application can have many surfaces (on the desktop at least)
[15:10] <mzanetti> dandrader: true... but that doesn't really invalidate my point
[15:11] <dandrader> just something to keep in mind
[15:11] <mzanetti> yeah, sure
[15:51] <greyback> someone do me a favour please: run "xev | grep -A 3 KeyRelease" and hit SysReq
[15:53] <Zhenech> greyback, http://paste.debian.net/86897/
[15:53] <greyback> Zhenech: perfect, thank you
[15:54] <Zhenech> it's a thinkpad, so I actually pressed Fn+PrtSc if that matters
[15:54]  * greyback has almost managed to remap his macbook's eject key to sysreq
[15:55] <greyback> Zhenech: I've a macbook, no such key so playing with remapping
[15:55] <greyback> I've mapped eject to printscreen, which is close :)
[15:55] <Zhenech> post it on the web, newer thinkpads miss that one too
[15:55] <greyback> will do
[15:57] <tsdgeos> eean: is it ok for you if i kill the get_details autopilot tests? they don't do much, do they?
[15:57] <tsdgeos> what?
[15:57] <tsdgeos> eean: sorry
[15:57] <tsdgeos> elopio: read ↑↑↑↑
[16:03] <elopio> tsdgeos: I need that to check the application details shown on the click scope
[16:03] <elopio> if you remove the test, I might break the helper without noticing
[16:03] <tsdgeos> ?¿
[16:06] <tsdgeos> elopio: ↑↑
[16:06] <tsdgeos> not sure i understand what you men
[16:06] <tsdgeos> mean
[16:07] <MacSlow> mterry, pushed rev8 of the egl-spinner, which should be easier to read and alter. Until we get feedback from Design, I'll leave it as-is. If you run into any issues just ping me.
[16:08] <mterry> MacSlow, thank you!
[16:08] <MacSlow> mterry, yw
[16:16] <elopio> tsdgeos: I mean that if something changes on unity and get_details doesn't return what I expect it to return
[16:16] <elopio> then the click scope tests will start failing without a clear reason
[16:16] <elopio> why do you want to remove them?
[16:17] <tsdgeos> elopio: because i don't see the point
[16:18] <tsdgeos> i mean it's not testing anything else than "we're showing stuff on screen"
[16:19] <elopio> tsdgeos: it's testing that get_helpers returns the title, the subtitle and the description.
[16:19] <elopio> the real user tests is in the click scope, where we check that the title, subtitle and description match the ones of the application we are opening.
[16:19] <elopio> but lets say we remove this test in unity.
[16:20] <elopio> and for some reason, unity no longer shows the description anymore.
[16:20] <elopio> without the test, we are with no clue about how it will affect other tests that might be using the helper.
[16:22] <tsdgeos> ah
[16:23] <tsdgeos> so you're using that helper from somewhere else?¿?
[16:23] <tsdgeos> elopio: ↑ ?
[16:24] <elopio> tsdgeos: yes. On the unity-scope-click suite.
[16:24] <elopio> tsdgeos: all the things you will see with tests in test_emulators.py are because I'm using them somewhere else.
[16:24] <tsdgeos> elopio: well
[16:24] <tsdgeos> that sucks
[16:24] <tsdgeos> i mean i suck probably :D
[16:24] <elopio> they are not user tests, just to make sure that the helpers remain working.
[16:24] <tsdgeos> is that documented?
[16:24] <tsdgeos> because i had no idea
[16:25] <tsdgeos> elopio: maybe it's better you fix those tests then
[16:25] <tsdgeos> those = unity8
[16:25] <tsdgeos> because i'm not going to go over unity-scope-click suite and fix them to work with new-scopes
[16:25] <elopio> tsdgeos: yes, mzanetti told me to add a big comment on test_emulators.py explaining it.
[16:25] <elopio> it's after the copyright.
[16:26] <mzanetti> poor elopio... first needed to convince mzanetti and now tsdgeos :D
[16:26] <elopio> tsdgeos: you won't need to go over unity-scope-click suite as long as you keep the signatures of the helpers.
[16:26] <tsdgeos> elopio: i can't keep the signature of the helpers
[16:26] <tsdgeos> because everything has changed in previews
[16:26] <tsdgeos> it's a different world
[16:26] <elopio> and if you have to break a signature, then you talk to the devs of the scope tests, and coordinate with them the updates.
[16:26] <tsdgeos> right
[16:26] <elopio> in this case, I'm the dev of the scope tests :)
[16:26] <tsdgeos> i don't want to do that
[16:27] <Saviq> tsdgeos, don't want to do what?
[16:27] <tsdgeos> be a good citizen
[16:27] <Saviq> ;)
[16:27] <tsdgeos> feeling moody today
[16:27] <tsdgeos> sorry
[16:28] <Saviq> tsdgeos, those helpers are ours, we need to commit to them, and yeah try and maintain the signatures, but obviously in this case we'll need to break them
[16:28] <Saviq> click scope tests will need to be redone just as well
[16:28] <elopio> tsdgeos: I'm here to help with whatever you need.
[16:28] <elopio> I'm used to moody devs, don't worry ;)
[16:29] <tsdgeos> elopio: well basically
[16:29] <tsdgeos> the get_details thing doesn't apply anymore
[16:29] <tsdgeos> since you can have a random number of stuff in a preview
[16:30] <tsdgeos> there is not just one title
[16:30] <elopio> tsdgeos: what I suppose we should do is to make it specific for the application preview.
[16:30] <tsdgeos> you can have 10 of them
[16:30] <elopio> tsdgeos: the application preview will still return title, subtitle and description, right?
[16:30] <Saviq> elopio, I don't think so, that knowledge needs to move towards the click apps scope
[16:30] <tsdgeos> the application preview doesn't exist in our autopilot world
[16:30] <Saviq> elopio, it's the scope that decides what will be displayed, we have no control over it, effectively
[16:30] <tsdgeos> is just a preview the same it was
[16:31] <tsdgeos> that sentence made no sense
[16:31] <tsdgeos> is just a preview as the others
[16:31] <tsdgeos> so that's why i want to remove the whole get_details thing
[16:31] <elopio> tsdgeos, Saviq: yes, so we need to move this get_details to the autopilot helpers that live in unity-scope-click
[16:31] <tsdgeos> i don't think it makes sense
[16:31] <Saviq> tsdgeos, and we need to facilitate that ↑↑
[16:31] <elopio> tsdgeos: then, I agree with you that it needs to be removed.
[16:32] <elopio> just, we need to be in sync so the tests in unity-scope-click are broken just for a little time.
[16:32] <Saviq> elopio, or not at all, we can land them together with new-scopes
[16:32] <elopio> tsdgeos: remove the helper, remove the test, and when we have all the other helpers working, I will  prepare a branch for the scope.
[16:32] <tsdgeos> elopio: cool thanks
[16:33] <elopio> tsdgeos: thanks to you.
[17:04] <tsdgeos> Saviq: elopio: i just pushed something that makes the last tests i had written down as not passing pass again, hopefully it should not regress the rest of the tests
[17:04] <tsdgeos> will check first thing tomorrow in the morning
[19:34] <Saviq> mzanetti, hey, tried hi-dpi Unity7? worth checking out probably :)
[19:34] <Saviq> mzanetti, it's in the archive already, iiuc
[19:43] <bschaefer> Saviq, yup it is, dont open the dash or hud though :)
[19:55] <popey> is there an easy way on current build of unity 8 on nexus 7 to get the sidestage, or do I need the bleeding edge stuff shown at MWC?
[20:42] <Saviq> popey, no, no easy way, and it won't be enabled soon either, it was using a hack to rotate the shell, which we need to replace with a proper implementation
[20:55] <popey> Saviq: thought so, thanks
[22:10] <kgunn> mhall119: ok...so i got my sessions approved but not scheduled
[22:10] <kgunn> http://summit.ubuntu.com/uds-1403/all/
[22:10] <kgunn> see i'm listed here...but no date/time
[22:10] <kgunn> any ideas (day before :)
[22:13] <mhall119> kgunn: still up to the track lead to schedule it
[22:13] <kgunn> ug...they've all gone home
[22:26] <hitsujiTMO> kgunn: any one i've clicked on has a time
[22:28] <hitsujiTMO> ahh, yours is the only one without a time
[22:35] <mhr3> mhall119, do you use your @canonical mail?
[23:28] <mhall119> mhr3: sometimes, why?