[07:02] <Saviq> MacSlow, hey, thanks for the update - got the VM running here, too
[07:04] <Saviq> MacSlow, was missing a dep autopilot should be pulling in
[07:45] <MacSlow> Saviq, np yw... so I can skip the minimal-based VM?
[07:45] <Saviq> MacSlow, yeah
[07:45] <Saviq> MacSlow, I'm trying out some things now
[07:45] <MacSlow> cool
[07:45] <Saviq> MacSlow, but it seems to be working, more or less
[07:46] <Saviq> MacSlow, since you're here, can you check https://code.launchpad.net/~saviq/unity8/upstart-run-on-device/+merge/175663 please?
[08:25] <MacSlow> Saviq, on it
[09:40] <TitusJ> hi
[10:41] <Saviq> MacSlow, 116 vs. 117 is my fault
[10:41] <Saviq> MacSlow, I've been restarting the jobs without looking at the revision properly
[10:41] <Saviq> MacSlow, just restarted the job with r117
[10:42] <MacSlow> Saviq, ah... phew... thought jenkins picked it
[10:42] <MacSlow> Saviq, what strikes me as odd with the failing test, is that there's no real result printed
[10:43] <Saviq> MacSlow, indeed
[10:43] <Saviq> MacSlow, just trying here
[10:43] <MacSlow> Saviq, locally certainly working
[10:44] <Saviq> MacSlow, is it using the palette maybe?
[10:44] <MacSlow> Saviq, yes... gradients for the buttons actually
[10:44] <Saviq> MacSlow, ok, let me try something
[10:50] <mhr3> didrocks, there's something super odd here https://jenkins.qa.ubuntu.com/job/unity-saucy-amd64-autolanding/126/console
[10:51] <didrocks> mhr3: hum, this is a question for gema I think? (the QA team?)
[10:51] <didrocks> mhr3: it seems that it's trying with the fake xorg
[10:51] <didrocks> that andyrock worked to have tests passing in headless chroot
[10:51] <Saviq> MacSlow, yeah, passes on VM, too
[10:52] <mhr3> didrocks, are these expected?
[10:52] <mhr3> Failed to create file '/usr/share/glib-2.0/schemas/gschemas.compiled.5VJJ0W': Permission denied
[10:52] <Saviq> MacSlow, let's see what jenkins says (sic!), maybe it didn't have the latest UI toolkit or something
[10:52] <MacSlow> Saviq, maybe a missing package-issue we don't see
[10:52] <mhr3> didrocks, and why do we run both headless and non-headless tests?
[10:52] <MacSlow> Saviq, was also thinking of a too old ui-toolkit package being used
[10:54] <didrocks> mhr3: because andyrock enabled and merged that?
[10:55] <didrocks> and, it was Trevinho, but andyrock talked to me about it :)
[10:55] <didrocks> mhr3: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3420
[11:04] <mhr3> didrocks, i still don't see why does it run twice, the second run is even after dh_install
[11:06] <didrocks> mhr3: the first run is done by the upstream merger
[11:06] <didrocks> mhr3: francis needs to disable them
[11:13] <mhr3> eeeh, i see what's wrong now
[11:13] <mhr3> apparently 180seconds isn't enough for tests that run 50seconds
[12:03] <Saviq> good
[12:09] <greyback> Saviq: glad you're happy :)
[12:09] <Saviq> greyback, :P
[12:10]  * greyback goes out for lunch, back in an hour
[12:41] <Trevinho> mhr3: you should use my script :D
[12:41] <Trevinho> mhr3: it never failed with it, a part the fact that some tests were buggy
[12:42] <mhr3> Trevinho, the build process is being weird... there was a failure before that yet it decided to continue
[12:43] <mhr3> Trevinho, i suppose your nux abi branch needs to land before anything else can?
[12:47] <Trevinho> mhr3: un theory unity should compile and run well with it or without it,...
[12:51] <mhr3> time to go to approve spree then :)
[12:59] <Trevinho> mhr3: want to re-approve it? Howevr, depending on a timeout is not the best thing... I'd increase it even more
[13:00] <mhr3> Trevinho, the weird thing is that the test takes 15seconds to execute and 180seconds wait isn't enough
[13:00] <Trevinho> mhr3: yeah,. you know jenkins is a whole new world
[13:04] <greyback> kgunn: ping
[13:04] <Trevinho> However, armhs build can't take so long... I'd bet it would be faster to just cross-compile it and run make check on that tree over a qemu vm...
[13:04] <Trevinho> armhf*
[13:05] <sil2100> Trevinho, mhr3: https://bugs.launchpad.net/unity/+bug/1202972
[13:05] <Trevinho> sil2100: actually I've a branch for that, it's just taking ages to compile...
[13:05] <Trevinho> sil2100: https://code.launchpad.net/~3v1n0/unity/memory-fixes/+merge/175703
[13:06] <Trevinho> sil2100: it was already in queue last night, I really was hoping that today it was merged...
[13:06] <Wellark> greyback: I'm now working on a new .desktop file parser
[13:07] <sil2100> \o/
[13:07] <greyback> Wellark: \o/ having fun?
[13:07] <Trevinho> sil2100: but... armhfs buids... 2 hours each minimum :/
[13:07] <Wellark> greyback: it is flex to tokenise the file, so I't super fast ;)
[13:07] <sil2100> Trevinho: this is exactly what I would need to land! Ah, yes, that's a big bother ;/
[13:07] <Wellark> greyback: and does not do any unnecessary string comparisons
[13:07] <greyback> Wellark: impressive
[13:07] <Trevinho> sil2100: yeah, I know... I did the branches in parallel... but unfortunately they land async
[13:07] <Wellark> greyback: so perfect fit to live inside the shell
[13:08] <greyback> Wellark: have a branch for it so I can check it out?
[13:08] <mhr3> Trevinho, since when do also IconLoader tests fail?
[13:08] <sil2100> Eh, pandaboards
[13:08] <Wellark> greyback: not yet. still need to finish it
[13:08] <Wellark> greyback: but now, it was at least able to lexer all the .desktop files under my /usr/share/applications
[13:08] <Trevinho> mhr3: sometimes it fails... as i needs looong time to load some thumbnails
[13:08] <greyback> Wellark: ok, no rush. I can survive with what I have for now. Will it have Qt bindings?
[13:08] <Trevinho> mhr3: i increased the timeout a lot, however
[13:09] <Trevinho> mhr3: also I fixed some errors it caused other tests to crash (i.e. it wasn't disconnecting the handlers)
[13:09] <Wellark> greyback: it only has Qt for now. I am aiming it directly for the DesktopfileReader class
[13:09] <mhr3> Trevinho, hmm, at least it's not a race, just hardware being slow
[13:09] <greyback> Wellark: suits me perfectly.
[13:09] <Trevinho> mhr3: yes... just that
[13:10] <greyback> Wellark: note DesktopFileReader API isn't final or anything, you're welcome to adjust if if you see fit
[13:10] <Trevinho> mhr3: I see you also fixed deeeeeee
[13:10] <Wellark> greyback: already have :)
[13:10] <greyback> Wellark: good
[13:11] <Wellark> greyback: it will have:
[13:11] <mhr3> Trevinho, there's still one race :/
[13:11] <Wellark> desktopEntry();
[13:11] <Wellark> actionGroup();
[13:11] <Wellark> customGroup();
[13:11] <Wellark> actionGroup and customGroup take a name of the group
[13:11] <Trevinho> mhr3: probably people is hating me bcause unity is not landing due to the tests being enabled, but I actually think it's a win to fix all these edge bugs we're catching :)
[13:12] <mhr3> Trevinho, yes, and yes :P
[13:12] <sil2100> :)
[13:12] <Trevinho> mhr3: ehehe
[13:12] <Wellark> greyback: those functions return a DesktopfileReader::Group class (or special subclass)
[13:12]  * sil2100 doesn't hate
[13:12] <greyback> Wellark: makes sense, nice
[13:12] <didrocks> Trevinho: mhr3: I want to be able to hide and show my launcher again :p
[13:12] <didrocks> and the fix is stuck for a week because of that ;)
[13:13] <Wellark> greyback: and from the Group you can access all the fields defined in the spec with fast lookup. and in addition any custom entry
[13:13] <Trevinho> didrocks: what?! You want to hide that awesome bar? You don't have, your eyes should always see that fantastic example of software!
[13:14] <didrocks> Trevinho: hum, I paid for pixels! I want them all for my apps :)
[13:14] <didrocks> ;)
[13:15] <greyback> Wellark: cool. Let me know when you've a branch to show me
[13:15] <Trevinho> didrocks: ehehe
[13:15] <Trevinho> mhr3: don't get... should I re-approve ~mhr3/unity/fix-scope-tests or you're waiting dee to land or something else?
[13:15] <didrocks> Trevinho: give me my pixels back, NOW! :)
[13:16] <mhr3> Trevinho, you can, but sil wanted the bump first
[13:16] <mhr3> where first == in ~10hours
[13:16]  * Trevinho is bzr branch lp:unity; bzr merge lp:~unity-team/fix-didrocks-launcher; bzr push lp:unity.... ops
[13:17] <Trevinho> mhr3: ah, i see.. it's on queue btw so let's put this back, if it will ever go in
[13:17] <mhr3> didrocks, sil2100, would it make sense to push stuff to trunk and have AP testing crounch through it?
[13:17] <mhr3> cause this is pretty insane
[13:17] <didrocks> mhr3: well, AP won't work
[13:17] <didrocks> mhr3: as we can't build the package, right?
[13:17] <didrocks> mhr3: I would have hope that tests were enabled only if they pass
[13:17] <didrocks> otherwise, revert them
[13:17] <didrocks> and only merge once they pass :)
[13:18] <Trevinho> didrocks: they actually pass... but some dbus stuff is a little unstable, but having them enabled ensures us to that we care about fixing the issues without forgetting about them (as it happende for years)
[13:18] <Trevinho> I'd use that strategy if really we can't do anything
[13:19] <mhr3> didrocks, they always have to pass to be merged, but yey races!
[13:19] <Trevinho> mhr3: is the dee change fixing the test you've disabled or is it somethnig else?
[13:19] <mhr3> yea, should fix it
[13:19] <Trevinho> mhr3: so, can you re-enable it safely or not yet?
[13:21] <mhr3> Trevinho, i'm more inclined to not enable anymore tests until we have a release to s
[13:21] <Trevinho> mhr3: ok
[13:25]  * Trevinho wore more pandas... or less pandas and more cross compilers
[13:25] <Trevinho> wants^*
[13:30] <Saviq> dednick, standup?
[13:31] <Trevinho> fginther: have you checked that ccache thing I told you about armhf? As it's still seems impossible to me that it takes so long
[13:32] <Saviq> MacSlow, start without me
[13:33] <dandrader> Saviq, turn it off, and then on. try again
[13:33] <dandrader> :)
[13:34] <fginther> Trevinho, no, we haven't had time to take a look yet
[13:35] <Trevinho> fginther: ok,
[13:36] <fginther> Trevinho, I did file a bug for it, trying to find it
[13:38] <fginther> Trevinho, well not a bug, but an item in a blueprint whiteboard- https://blueprints.launchpad.net/ubuntu/+spec/qa-s-ps-qa-ci
[13:40] <dandrader> dednick, Saviq any of you guys fancy reviewing this one? https://code.launchpad.net/~dandrader/unity8/lp1116207/+merge/175163  Jenkins is finally happy with it!
[13:40] <Trevinho> fginther: cool
[13:40] <greyback> MacSlow: before I played with cgroups to try to reproduce fails on Jenkins locally. Sometimes I suspect race conditions cause a fail on jenkins as it is slower than your machine. You can use cgroups to limit the cpu available to the tests, so they'll run slower, and maybe you can trigger the fail. Here are my notes: http://pastebin.ubuntu.com/5890797/
[13:40] <Trevinho> fginther: but doing crosso compiling + qemu for testing would be slower or somewhat possible?
[13:40] <greyback> MacSlow: not a guaranteed way to repro the fail, but might be worth a shot?
[13:40] <Wellark> Saviq: is the HUD working (not blocking unity8 at start-up) on the desktop now?
[13:41] <MacSlow> greyback, sure thing... thanks... looking at it now
[13:41] <Trevinho> or also real hw.. at that point
[13:41] <Saviq> Wellark, yeah, I didn't see it again
[13:41] <Saviq> dandrader, did you ↑↑?
[13:42] <fginther> Trevinho, the real answer is just get faster hardware, which we have now. It just needs a few weeks to be setup and finish some break-in testing
[13:42] <dednick> dandrader: sure. lunch first though :)
[13:42] <dandrader> dednick, ok, thanks!
[13:42] <Trevinho> fginther: ah, ok... That's better, also if I bet it wouldn't beat cross compiling anyway...
[13:42] <fginther> Trevinho, cross compiling is possible, but I know I've run into tests suites that segfault on qemu
[13:43] <MacSlow> greyback, the odd thing is... the assertion that's failing isn't printing any values from the checks at all... result-strings are must empty, which is making me guess jenkins might be using an older ui-toolkit package.
[13:43] <MacSlow> greyback, but I'll give that CGroups a try
[13:43] <fginther> Trevinho, if the hardware doesn't work as promised, we will definately revisit these tasks
[13:43] <greyback> MacSlow: I would expect jenkins to use the last release of uitk
[13:44] <Trevinho> fginther: mh, the segfaulting may have been possible also due to problematic tests actually... We recently found some memory issues and possible crashes.. in theory it should be safer now
[13:44] <Trevinho> or at least as soon as they merge :)
[13:45] <Saviq> MacSlow, fginthercan give you direct access to a jenkins machine - maybe that would be best?
[13:45] <dandrader> Saviq, Wellark I'm getting the blocking hud right now, actually. But I think it's related to hud libraries being udated (i just dist-upgrade). Last time I got it, a reboot solved it
[13:46] <MacSlow> Saviq, as long as I'll not be further tormenting panda-boards. I don't know how jenkins looks under the hood.
[13:47] <Saviq> MacSlow, yeah, that'd be on a multi-cpu VM
[13:47] <Saviq> MacSlow, and that's where it's failing, btw
[13:47] <Saviq> MacSlow, in the local VM I have it passed, so it's probably the only way
[13:47] <Saviq> fginther, could you unhook a VM for MacSlow to debug a test failure?
[13:48] <MacSlow> Saviq, ok... so if fginther can grant me accsss that would be welcomed
[13:54] <fginther> Saviq, MacSlow one moment please
[13:54] <MacSlow> fginther, sure np
[14:01] <MacSlow> Saviq, btw... just checked what a failure of the button-tint assertion looks like locally... it's normal that the result-strings are empty.
[14:03] <Saviq> MacSlow, ah? what are they?
[14:03] <Saviq> MacSlow, maybe one is null and the other an empty string or sth?
[14:03] <MacSlow> Saviq, gradients... I wonder if there's a better way than compare() to check them
[14:04] <Saviq> ah
[14:04] <Saviq> MacSlow, that's probably why
[14:04] <Saviq> MacSlow, are you comparing with Theme directly?
[14:04] <MacSlow> Saviq, I might be able to check every color-component individually
[14:05] <Saviq> MacSlow, yeah, we shouldn't do that
[14:05] <MacSlow> Saviq, compare(buttonAccept.gradient, data.buttonTinted ? UbuntuColors.orangeGradient : UbuntuColors.greyGradient, "button has the wrong color-tint")
[14:05] <Saviq> MacSlow, I think that we shouldn't even test that, really
[14:07] <MacSlow> Saviq, well I changed something, which can be tested... so I wrote a test for it... the tint is only meant for core/system snap-decisions
[14:07] <Saviq> MacSlow, and definitely not if we need to "drill into" the gradient, that'd be wrong
[14:08] <Saviq> MacSlow, try verify(buttonAccept.gradient [14:12] <MacSlow> Saviq, verify() make the test stall there
[14:16] <Saviq> MacSlow, interesting...
[14:24] <kenvandine> jibel, can you please add jenkins views for 2 new cu2d stacks?  click-package and thin-client
[14:33] <sil2100> greyback: ping!
[14:34] <greyback> sil2100: hey
[14:47] <Saviq> dednick, can you think of a workaround for the home vs. apps issue?
[14:47] <Saviq> dednick, other than a timer, that is ;)
[14:48] <Saviq> dednick, it's breaking autopilot tests, I'm afraid
[14:48] <dednick> Saviq: there must be a way to make it create at that size.
[14:48] <dednick> rather than resizing it
[14:49] <Saviq> dednick, where are we resizing?
[14:49] <dednick> main.cpp
[14:50] <dednick> Saviq: i'm guessing that's where it's going wrong. could be wrong i guess
[14:52] <olli_> Saviq, greyback where are we at with u8/mir
[14:52] <greyback> olli_: I'm starting to integrate my qml-demo-shell work into unity8 now
[14:52] <greyback> olli_: am hoping to have something to show for next week
[14:53] <olli_> greyback, so no early demo build today?
[14:53] <greyback> olli_: sorry, no
[15:03] <kgunn> MacSlow: hey....just heard a report of this
[15:03] <kgunn> https://bugs.launchpad.net/unity8/+bug/1203080
[15:03] <kgunn> so i filed a bug
[15:03] <kgunn> can you please prioritize a look into this ?
[15:03] <kgunn> would be good to know by eod Monday
[15:04] <kgunn> whether or not its valid
[15:04] <MacSlow> kgunn, ok
[15:04] <kgunn> just test it locally....with intent to eventually fold in a test into our ci process somehow
[15:04] <kgunn> thanks!....that's a potential "egg on face" bug :)
[15:08] <MacSlow> kgunn, *sigh* if only the interaction/callbacks would work already with the ap-tests
[15:09] <kgunn> MacSlow: yeah...but like i said, please test locally until your totally confident (we need to move on it...regardless of ap)
[15:10] <MacSlow> kgunn, already on it
[15:15] <Wellark> sil2100: hi! to answer your question from yesterday, the nohud branch of unity-action-api is only to support P Q and R as ui-toolkit supports them
[15:16] <Wellark> sil2100: the branch lands only to the ui-toolkit ppa for those ubuntu releases
[15:16] <sil2100> Wellark: ah, so there's no daily-releasing for S planned then?
[15:16] <sil2100> Wellark: ACK
[15:19] <fginther> MacSlow, i386 VM ok?
[15:19] <fginther> the amd64 and i386 VMs are setup the same
[15:19] <kgunn> MacSlow: thanks!
[15:22] <didrocks> sil2100: move it then!
[15:22] <nic-doffay> greyback, do you know where the flicking motion between the scopes is handled?
[15:22] <sil2100> didrocks: done!
[15:22] <didrocks> sil2100: I saw that, good job ;)
[15:23] <greyback> nic-doffay: DashContent.qml
[15:23] <nic-doffay> greyback, ta
[15:36] <MacSlow> fginther, well I guess so... but just now a critical bug was assigned to me, so I'll have to leave the test-debugging at the side for now
[15:37] <fginther> MacSlow, ok, ping me when you need it again. I'll leave it in the pool for now
[15:38] <MacSlow> fginther, sure... I'll email you once I can address debugging the test again
[15:40] <sil2100> mhr3: btw. since I think I fell out of the loop - did those fixes resolve the DBus issue we had in Unity?
[15:40] <mhr3> sil2100, yes
[15:40] <mhr3> mostly
[15:41] <sil2100> fginther: hi!
[15:43] <sil2100> fginther: there's a unity merge that's Approved for merging for 3 hours already and nothing
[15:43] <sil2100> fginther: https://code.launchpad.net/~3v1n0/unity/memory-fixes/+merge/175703
[15:43] <sil2100> fginther: we would need this merge in, as it's resolving the ABI break issue we had
[15:53] <dednick> Saviq: i think i've found a way though it, but it's a bit of a journey
[15:54] <dednick> although not too overly complicated.
[15:54] <Saviq> dednick, better than a timer? :)
[15:54] <dednick> Saviq: somewhat :)
[15:55] <dednick> Saviq: using a singleton to pass the command line geometry arguments to the qml so it can set the window with the correct geo.
[15:57] <Saviq> dednick, singleton, or context prop?
[15:57] <dednick> Saviq: guess we could use a context prop
[15:58] <Saviq> dednick, sounds simpler
[15:58] <dednick> i was just testing with singleton
[16:04] <Saviq> dednick, I wonder if we didn't set width/height in Shell.qml
[16:05] <dednick> Saviq: it's possible. setting them in Dash[Content].qml also screws it up.
[16:05] <dednick> it first goes to the one set in the file, then the one overridden in parent.
[16:05] <Saviq> well, atm if I don't set them, there is no dash at all...
[16:07] <Saviq> that's interesting, btw
[16:08] <dednick> Saviq: yeah. should follow the view. hm
[16:08] <Saviq> dednick, well, the shell itself does follow the view
[16:08] <Saviq> dednick, but dash doesn't...
[16:09] <Saviq> dednick, but it still goes 400x710 → 0x-32 (sic!) → 1280x768
[16:09] <dednick> Saviq: yeah, i just saw that. i forgot to use the explicit geo.
[16:09] <Saviq> dednick, ok, let's go with a context prop for now
[16:12] <Saviq> dednick, and we'll investigate later
[16:12] <dednick> Saviq: ok, let me just clean up and i'll put in an MP
[16:12] <Saviq> dednick, cheers
[16:24] <dednick> larsu: ping
[16:31] <larsu> dednick: hey
[16:34] <dednick> larsu: hey. question about indicator actions. why are they prefixed with indicator.* in the gmenumodel, but not in the actiongroup?
[16:34] <dednick> larsu: or rather some of them are.
[16:34] <Saviq> dednick, I thought you'd just pass shellWidth/shellHeight in context props
[16:35] <dednick> Saviq: still need to check if they exist.
[16:36] <Saviq> dednick, no, just drop the "tablet" prop
[16:36] <dednick> Saviq: we dont use it?
[16:36] <Saviq> dednick, no
[16:37] <Saviq> dednick, and pass the correct values from C++ already
[16:37] <Saviq> dednick, only thing is... gridunits...
[16:37] <dednick> Saviq: yeah.
[16:38] <Saviq> dednick, so just pass 0 if not set on command line
[16:38] <Saviq> dednick, but drop the tablet prop anyway - better to use the -geometry arg anyway
[16:39] <larsu> dednick: the prefix tells the you which action group to use
[16:39] <fginther> sil2100, that branch should start building shortly
[16:39] <sil2100> fginther: \o/
[16:40] <sil2100> Trevinho: can you make sure your branch with the nux dep-bump in unity is merged in?
[16:40] <larsu> dednick: in the case of the indicator, we only have one action group, but we thought it's better to include a prefix anyway in case we decide to add another one at some point
[16:40] <sil2100> Trevinho, fginther: thanks guys!
[16:40] <larsu> dednick: the unitymenumodel I've been working on a while ago handles this all for you, but I didn't get around to finishing and MRing that yet
[16:46] <Saviq> didrocks, idea: could daily release drop an empty, bumped entry in debian/changelog?
[16:47] <didrocks> Saviq: you mean rebuilding daily even if there is nothing to publish?
[16:47] <Saviq> didrocks, no no
[16:47] <dednick> Saviq: has to be a qobject
[16:47] <Saviq> dednick, right
[16:47] <Saviq> didrocks, just a "next" entry in debian/changelog so that when you build locally it's higher than released
[16:48] <Saviq> didrocks, but I'm probably overthinking it :)
[16:48] <didrocks> Saviq: hum, I think it's more a feature in fact to have the same version
[16:48] <didrocks> Saviq: it enables to rollback easily
[16:48] <bschaefer> dednick, ping
[16:48] <MacSlow> kgunn, with my manual testing sofar (filling the queue) I could always get a snap-decision displayed right away when I triggered one... I'll keep looking further into it
[16:48] <dednick> bschaefer: howdy
[16:48] <bschaefer> dednick, hey, hows it going?
[16:49] <dednick> pretty good thanks. you?
[16:49] <didrocks> Saviq: the issue with dropping a "next" version is if someone already started that between the snapshot and the duplication
[16:49] <kgunn> MacSlow: makes me feel much better...keep tinkering
[16:49] <didrocks> you will start having merge conflicts
[16:49] <bschaefer> doing well, except im looking at removing some code here: https://code.launchpad.net/~brandontschaefer/unity/lp.1201631-fix/+merge/175670
[16:49] <didrocks> and you don't know what good "next" version is (you are not sure to have a daily tomorrow :p)
[16:49] <bschaefer> dednick, and I want to make sure I don't cause any regressions, you mentioned that it was to get focus in the dash on start up
[16:49] <MacSlow> kgunn, I've sofar only used my (extended) python-examples to test-drive this...
[16:50] <Saviq> didrocks, well, the next daily would be higher always
[16:50] <MacSlow> kgunn, I'll try messing around with the phone-app directly
[16:50] <bschaefer> dednick, but its been working fine for me removed...but still wanted to double check with you :)
[16:50] <Saviq> didrocks, so a 20130720~ would be dropped the "next" for today
[16:50] <MacSlow> kgunn, who reported this anyway?
[16:50] <Saviq> didrocks, but I know, overthinking :)
[16:51] <didrocks> Saviq: I'm more worried about potential merge conflicts when merging back
[16:51] <didrocks> but yeah, will think about it
[16:51] <Saviq> didrocks, cheers
[16:51] <MacSlow> kgunn, fyi... I've been doing that directly on the phone with the latest image and pulled updates
[16:51] <Saviq> dednick, can you please push your branch under ~unity-team and resubmit just in case
[16:52] <Saviq> MacSlow, don't we have a test for that in lp:unity-notifications btw?
[16:52] <MacSlow> kgunn, I'll also update the bug-entry once I've more data collected
[16:52] <kgunn> MacSlow: thostr_ said it happens to him....but he seemed to have some debug data behind it as well
[16:52] <kgunn> so not sure if he had experienced directly
[16:52] <dednick> Saviq: sure
[16:52] <MacSlow> Saviq, afaik yes
[16:52] <kgunn> or if he was reporting something from phonedations/phone app team
[16:53] <Wellark> larsu: what is unitymenumodel?
[16:53] <dednick> bschaefer: i cant remember the conditions where we werent getting focus, but i remember putting it in.
[16:53] <bschaefer> dednick, the commit message on annotate mentioned on start up...but is causing the DashView/ScopeView/ScrollView to be SetVisible(true) when nothing is renderering
[16:54] <bschaefer> dednick, ill do some more testing to make sure im not doing anything crazy though... I would love to avoid a regression :)
[16:55] <MacSlow> kgunn, odd that thostr_ didn't mention this issue to me when I had a mumble-session with him this morning
[16:55] <bschaefer> cause you know nux can't tell if something is rendering or not, just if someone set the view to visible or not, which doesn't do much either...
[16:55] <larsu> Wellark: qmenumodel v2
[16:57] <MacSlow> kgunn, just called myself with the queue being full of notification... snap-decision showed right up and I could pick up.
[16:57] <dednick> bschaefer: i have a feeling that it's the first time you ever open the dash
[16:57] <MacSlow> kgunn, really curious how they managed to run into this issue.
[16:57] <bschaefer> dednick, yup, which I checked for, and its getting focus
[16:57] <bschaefer> but i just want to try a few more times...as it could be some sort of race condition
[16:58] <kgunn> MacSlow: maybe someones using or thinking of something old ?
[16:58] <dednick> bschaefer: after a reboot you mean?
[16:58] <bschaefer> dednick, just wanted to double check with you if there was more to it, thats all :)
[16:58] <bschaefer> dednick, yeah
[16:58] <bschaefer> and on a compiz --replace ccp
[16:58] <kgunn> MacSlow: so from above...we already have a test in place for full q & priority shuffling?
[16:58] <MacSlow> kgunn, at least for the moment my weekend seems not as grim as I envisioned it just an hour ago :)
[16:58] <kgunn> MacSlow: \o/
[16:59] <dednick> bschaefer: there are a few bugs logged against dash focus issues. may be worth sifting though them.
[16:59] <dednick> tagged with 100scopes most likely
[16:59] <bschaefer> dednick, o nice, yeah I can look for those, thanks!
[17:00] <MacSlow> kgunn, there's a test for full-queue... but nothing for checking if a snap-decision can still be inserted
[17:01] <kgunn> MacSlow: might be worth adding
[17:01] <MacSlow> kgunn, certainly... I'm always keeping my list with "tests to add" up to date with such findings
[17:03] <MacSlow> kgunn, so from my testing we're good... everything seems to be fine
[17:03] <kgunn> MacSlow: sure...just update the bug....and i'll circle back on strehl
[17:03] <kgunn> see where he was hearing that from
[17:03] <MacSlow> kgunn, I'm switching the bug from "In Progress" to "Incomplete" (needing more info)
[17:04] <MacSlow> kgunn, and will also comment with my findings sofar.
[17:04] <dednick> Saviq: done.
[17:06] <Saviq> dednick, yeah, thanks!
[17:06] <Saviq> dednick, have a good weekend peepl o/
[17:07] <dednick> Saviq: you as well
[17:07] <Wellark> larsu: ok, is it something I need to know about at this point?
[17:08] <Wellark> larsu: does it support two way communication though the menuitems or is it still publish only?
[17:09] <MacSlow> Have a cool weekend everybody!
[17:09] <larsu> Wellark: I don't know if you need to know about it :)
[17:09] <larsu> Wellark: what do you mean by two-way communication? Activating actions etc.?
[17:22] <larsu> Saviq: I've added you as a reviewer for the QGSettings API, hope that's okay with you :)
[17:48] <Trevinho> fginther: when a package is merged by autolander, isn't it available for other projects immediately? I.e. isnt't there a local repository to be used, or it rely only on the ppa?
[17:49] <Trevinho> fginther: see https://jenkins.qa.ubuntu.com/job/unity-saucy-amd64-ci/152/console libdee 1.2.6 has auto-landed but it's not on the ppa yet but unity depending on it isn't building yet
[17:49] <Trevinho> didrocks: dead lock? ^ :)
[17:50] <fginther> Trevinho, there is not a local repository that is shared by all projects. unity/compiz/nux share one, but dee is not in that group
[17:50] <Trevinho> fginther: ah i see...
[17:50] <Trevinho> fginther: so we only can wait...
[17:51] <fginther> Trevinho, if it's urgent we can put dee in the same in the same local archive and rebuild, but it's a little bit of work to do
[17:51] <fginther> Trevinho, and I'm swamped:p
[17:52] <Trevinho> fginther: eheh... no worries... let's avoid for now
[17:52] <fginther> Trevinho, thanks
[17:52] <Trevinho> fginther: in case that it doesn't reach the ppa I'll re-approve tomorrow..