[01:27] <veebers> mterry: forgot to mention, from initial tests it appears that adding the -C makes it work. Well spotted
[01:45] <mterry> veebers, nice!
[10:42] <MCR1> Mirv, sil2100: Hi :) I am trying to patch lp:~compiz-team/compiz/ubuntu to fix an issue, but the new keyboard shortcut merged yesterday seems to not have reached this branch yet. Can you update this for me ?
[10:43] <MCR1> http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/revision/3591
[10:44] <MCR1> ^^ this is what it is about. But the new keyboard shortcut unmaximize_or_minimize_window_key is not yet in lp:~compiz-team/compiz/ubuntu...
[10:46] <sil2100> MCR1: hi!
[10:46] <sil2100> MCR1: hm, you want to back-port this fix to quantal?
[10:47] <sil2100> MCR1: since lp:~compiz-team/compiz/ubuntu is not used in raring anymore, as we have packaging inside the source trunk now
[10:47] <MCR1> sil2100: Hi. Do you understand my problem ?
[10:48] <MCR1> sil2100: ah, that explains a bit :)
[10:48] <sil2100> MCR1: yes, I think I do, but I need to first understand why you want to use lp:~compiz-team/compiz/ubuntu - since this branch is not used anymore at all I think, since even packaging for quantal is in a different branch now I think
[10:48] <sil2100> And packaging for compiz is inline, as we're doing daily releases now, so it's not necessary to do it seperately
[10:49] <MCR1> sil2100: So I just need to fix it in lp:compiz, yes ?
[10:49] <MCR1> sil2100: Great
[10:49] <sil2100> MCR1: yes, if you want it fixed in raring ;)
[10:49] <MCR1> Thanx a lot 4 your information.
[10:49] <sil2100> np!
[10:50] <MCR1> (3 branches for one shortcut ;))
[10:51] <MCR1> At least I have learned now how these patching voodoo magic worx :)
[10:56] <MCR1> JohnLea: I am proud to announce that bug 966099 will be fully fixed today. You should be able to use it tomorrow on Raring :)
[11:34] <Mirv> MCR1: yeah the upstream branch changelog now gets somewhat messier but otherwise it's much easier that packaging is included
[11:35] <Mirv> so that change was now done for compiz and the whole unity stack in raring
[11:38] <JohnLea> MCR1; super cool ;-)  BTW, have you seen bug #878820 ?   The fix you have done for this bug should also make it possible to implement the "Ctrl-Alt-Numpad 5" shortcut defined in bug #878820
[11:55] <MCR1> JohnLea: Toggle Maximized is already implemented - I do not have original shortcuts here - does it not work at the moment ?
[11:56] <JohnLea> MCR1; but I don't think the "if maximised, pressing 'Ctrl-Alt-Numpad 5' again restores the window" is implemented
[11:57] <MCR1> JohnLea: Please try again - it should be
[11:57] <JohnLea> MCR1; give me 2 minutes...
[11:57] <MCR1> JohnLea: The key is named toggle_window_maximized_key and is in CCSM->General->Key bindings
[11:58] <MCR1> JohnLea: The default for it is Ctrl+Alt+KP5, so it *should* work already...
[11:58] <MCR1> JohnLea: Toggling stuff is less complicated than the other one ;)
[11:59]  * MCR1 finally won the quilt battle :)
[12:00] <JohnLea> MCR1; you are correct 'Ctrl-Alt-Numpad 5' both maximises and then restores the window.  The only shortcuts from this bug that don't work atm are "Ctrl-Alt-Numpad 4" and "Ctrl-Alt-Numpad 6"
[12:00] <MCR1> JohnLea: Should those also toggle ?
[12:01] <JohnLea> MCR1; no, only 'Ctrl-Alt-Numpad 5' should toggle.  All the other shortcuts listed in the bug should do nothing if pressed for a second time
[12:01] <MCR1> then it is okay now
[12:02] <JohnLea> MCR1; cool, many thanks for fixing bug 966099  ;-)
[12:02] <MCR1> JohnLea: I wanted to look at bug 878820 anyway and make behavior configurable there - as many old-time Compiz users miss the old behaviour
[12:03] <MCR1> JohnLea: So everyone could be satisfied
[12:03] <MCR1> JohnLea: First I will make everything behave according to your wish, but with the option to use the old grid behaviour
[12:03] <MCR1> JohnLea: How does that sound ?
[12:16] <MCR1> Mirv, sil2100: Hope this is correct: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix966099-refresh-quilt-patch/+merge/146103 ?
[12:16] <sil2100> MCR1: let me take a look
[12:16] <rye> uhm
[12:16] <rye> was blur reverted?
[12:17] <MCR1> sil2100: Thanks :)
[12:17] <MCR1> rye: Which blur ?
[12:18] <Mirv> looks correct at first sight
[12:18] <rye> MCR1: there was a change in blur tech for dash background, in http://bazaar.launchpad.net/~unity-team/nux/trunk/revision/751 which made it really fast to fade in, but at some point dash started fading in slow again
[12:18] <sil2100> MCR1: hm, I'm not sure if that's correct
[12:20] <rye> hm, http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3083
[12:21] <MCR1> sil2100: I am also not sure ;)
[12:22] <sil2100> MCR1: I commented on the merge request
[12:22] <popey> Mirv: sil2100 I'm getting bug 1103475 in raring in virtualbox (my vbox was broken and I just fixed it only to find compiz barfs in the way we found it did on quantal)
[12:22] <popey> confirmed by someone else too
[12:22] <sil2100> popey: huh? But it didn't bail out before, right?
[12:23] <popey> i haven't had it running in raring for a while
[12:23] <popey> vbox was broken
[12:23] <sil2100> Ah
[12:23] <popey> still is, had to manually patch their driver
[12:23] <popey> https://forums.virtualbox.org/viewtopic.php?f=3&t=53708
[12:23] <sil2100> Ok, so it's indeed a compiz problem
[12:23] <popey> ya
[12:23] <sil2100> popey: it's probably the fix that Francis bisected... I think we need to poke Daniel about that, let me write an e-mail maybe
[12:23] <popey> can you look at what duflu backed out for quantal and see if we can back that out of raring? or "fix"
[12:23] <popey> thanks
[12:24] <sil2100> popey: Daniel didn't back it out yet for quantal - I prepared a merge request with the back-out but it still didn't get accepted
[12:24] <popey> bah
[12:24] <sil2100> popey: so quantal trunk is still broken - just no one knows since it's not released yet ;)
[12:25] <Mirv> and if it wasn't broken we'd do a release since that was already planned sans this bug
[12:26] <sil2100> Oh!
[12:26] <MCR1> sil2100: I do not know why quilt did it that way... I did what http://wiki.debian.org/UsingQuilt describes... :(
[12:26] <sil2100> I also noticed that Sam commented on my revert MRQ
[12:26] <sil2100> As always, a big but detailed comment, solid info
[12:26]  * sil2100 reads up
[12:27] <sil2100> Maybe smspillaz came up with a solution, since I see he proposed a workaround
[12:27] <MCR1> rye: AFAIK first the nux branch introduced the new blur, but quality was not perfect, then the unity branch was merged fixing this
[12:28] <MCR1> rye: Here the blur is still super-fast
[12:28] <rye> MCR1: yes, quality was not perfect, but it did not took 5 second to open dash preview
[12:28] <rye> in fullscreen
[12:29] <rye> also fading in is again slow and makes CPU usage spkie :(
[12:29] <rye> spike
[12:29]  * rye needs to mention that's 1920x1080
[12:29] <MCR1> rye: Which gfx are you using ? I cannot reproduce the problem here... (fglrx)
[12:30] <rye> MCR1: intel HD 3000 @ 1920x1080, which was the reason why I filed bug #1099787
[12:30] <rye> then there was a brief time of happiness
[12:30] <sil2100> MCR1: did you use quilt push ?
[12:31] <sil2100> MCR1: if I remember correctly, you can then define exactly which patch to use, i.e. quilt push debian/patches/ubuntu-config.patch
[12:31] <sil2100> And then just refresh and pop
[12:32] <MCR1> sil2100: ok, I'll try it again - but in the evening as I am running out of time...
[12:32] <MCR1> sil2100: Thanks 4 your help :)
[12:33] <sil2100> MCR1: no problem - we'll wait for the merge for later :) See you around then!
[12:35] <MCR1> sil2100: yep, that will the best way. c ya
[12:41] <rye> Added my comment regarding the blur - https://bugs.launchpad.net/unity/+bug/1102410/comments/1
[12:42] <rperier> Hi, what bug could you assign me once my merge request will be accepted ? I should pick a bug from bugs.l.n/unity directly ?
[12:44] <sil2100> rperier: hi! Let's see in a moment
[12:49] <rperier> sil2100: sure
[12:54] <smspillaz> sil2100: popey: I commented on the MRQ about the correct way to work around the virtualbox driver bug without breaking LLVMpipe
[12:54] <smspillaz> that was like 4 days ago
[12:54] <popey> thanks smspillaz
[12:55] <smspillaz> sil2100: popey: for future reference, touching the pixmap bind code to remove server grabs is not a good idea. We need that in order to get around a race condition in software rendering
[12:56] <smspillaz> though I hope we can eventually remove the server grab for the bind case on internally managed pixmaps by integrating the app<->compositor frame synchronization code that's being worked on in gnome
[13:00] <sil2100> rperier: commented on your merge request again ;)
[13:00] <smspillaz> popey: FWIW, I'm running compiz in virtualbox on R just fine
[13:01] <sil2100> smspillaz: hm, good to know that
[13:01] <smspillaz> kinda sucks that in order to fix one driver we had to break another
[13:01] <smspillaz> and that happened twice both ways -.-
[13:02] <popey> smspillaz: with 3d passthrough or llvm?
[13:02] <smspillaz> popey: 3d passthrough
[13:03] <rperier> sil2100: thanks , looking
[13:03] <smspillaz> popey: actually, it might have been P
[13:03] <smspillaz> >.>
[13:03] <smspillaz> popey: ignore me, I think it was P
[13:03] <sil2100> smspillaz: ;)
[13:04] <popey>  /ignore smspillaz
[13:05] <sil2100> ;p
[13:05] <smspillaz> I'm doing rails stuff for this internship, VMs seemed to be the most sane way of handling the nightmare that is deploying servers
[14:21] <xkernel>  is Unity an independent desktop environment or it's based on the Gnome?
[14:28] <bregma> xkernel, Unity is a desktop shell, not a desktop environment -- it runs on Gnome
[15:45] <rye> sil2100: may I draw attention to this - http://www.youtube.com/watch?v=DARe2EfwMSY - this is actual speed with the latest blur update in https://bugs.launchpad.net/unity/+bug/1102410
[15:47]  * sil2100 is looking
[15:47] <sil2100> Damn that's slow
[15:58] <mhr3> fullscreen previews on intel are super slow in 12.10 too
[15:58] <mhr3> especially on those high resolutions
[15:59] <mhr3> so https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1055126
[16:03] <rye> mhr3: they _were_ fast 2 days ago before the fix to get nicer blur went in
[16:04] <rye> mhr3: i mean the fix in raring
[16:05] <rye> the fix to make radeon working with new intel module has recently entered... somewhere... but I am sure it is should not be required to have a fully-fledged 3d card to render the shell interface
[16:07] <mhr3> as far as the bug goes, it wasn't fixed yet
[16:08] <mhr3> if you saw it behave well because your computer was using radeon instead of intel is a different thing
[16:09] <rye> mhr3: no, there was a nux change to use a faster implementation, it went into nux and suddenly my intel card is capable of driving unity this display at this resolution. Then it was deemed to be not pretty enough and now we are at the original speed. The fix is set to fix committed in unity which is why I am panicking
[16:09] <rye> mhr3: i was not able to get my radeon card to run on this machine yet
[17:36] <fginther> mterry, today's release testing results look better. Hit a compiz crash on the nvidia unity test and still get 1 test failure on the intel indicators test
[17:37] <mterry> fginther, yeah, I'm looking into the webapps build failure now, but also downloaded the compiz crash file for investigation
[17:39] <fginther> mterry, ok, please let me know if that compiz crash is useful this time
[17:42] <bschaefer> fginther, hmm what seems to happen in the failing intel test is the switcher fails to focus the window, and bringing up the hud saves that unfocused window
[17:42] <bschaefer> and exiting the hud causes it to restore the unfocused window...
[17:48] <sil2100> bschaefer: you mean the latest one test_hud_does_not_focus_... ?
[17:48] <bschaefer> sil2100, yeeah, if you look at the video, just as the alt+tab switchers
[17:48] <bschaefer> the panel seems to lose focus
[17:48] <bschaefer> (right before the hud opens)
[17:50] <sil2100> Indeed, makes sense, although it's really strange to see that it fails switching to a window, and focuses nothing
[17:51] <bschaefer> yes very strange, possibly this branch fixes that: https://code.launchpad.net/~3v1n0/unity/switcher-noinputwin/+merge/146031
[17:52] <bschaefer> it makes the switcher no longer focus a window, though Im not sure if that branch was in the latest run
[17:52] <fginther> sil2100, bschaefer looking back through the logs, that test fails about 25% of the time
[17:53] <fginther> bschaefer, that merge would not have been in the latest ps-indicator test
[17:54] <fginther> brb, lunch time
[17:54] <bschaefer> alright, cool
[17:55] <bschaefer> sil2100, hmm could we get the daily-build bumped up?
[17:55] <bschaefer> or will we have to wait until didrocks?
[17:58] <sil2100> bschaefer: not sure if we'll be able to do that, hm, Didier will be back next week anyway, let's wait maybe till then
[17:58] <sil2100> bschaefer: by bumped-up you mean, new packages published?
[18:00] <mterry> fginther, hrm.  can't make sense of this compiz crash report either
[18:01] <bschaefer> sil2100, yup
[18:01] <bschaefer> sil2100, but cool
[18:32] <mterry> fginther, so, still can't get useful stacktrace from this compiz crash report.  Do we know if this crash existed for a while, or is a relatively new thing this past week?
[18:33] <mterry> fginther, trying to get a sense for whether we should go ahead or not
[18:33] <mterry> bschaefer, you want a new daily build of unity?
[18:34] <bschaefer> mterry, yeah, just to check if this branch fixes that intel failing AP test in ps-inicators
[18:34] <bschaefer> https://code.launchpad.net/~3v1n0/unity/switcher-noinputwin/+merge/146031
[18:34] <bschaefer> but it can wait until next week
[18:35] <bschaefer> as I can confirm its working on my machine, and I can reproduce that bug
[18:35] <bschaefer> cant*
[18:35] <mterry> bschaefer, started
[18:35] <bschaefer> mterry, cool, thanks
[18:37] <bschaefer> mterry, I can look at the stacktrace but umm shoot...there could have been a break in ABI in compiz recently which could cause compiz to crash
[18:38] <bschaefer> with out the abi number being bumped
[18:39] <mterry> bschaefer, only on nvidia?
[18:40] <bschaefer> o nm then!
[18:40] <sil2100> bschaefer: again? There was an ABI break recently, so we bumped the ABI version number
[18:41] <bschaefer> sil2100, if its only on nvidia soo i was just thinking
[18:41] <bschaefer> i mean if its only on nvidia then no its not
[18:43]  * mterry would love to figure out if this nvidia crash is a real problem or not, so we can get unity autopublishing again
[18:46] <fginther> mterry, there has been a compiz crash in ps-unity builds 64 and 66.  Builds 60-63 & 65 were crash free.
[18:46] <mterry> sil2100, awesome about ibus tests!
[18:47] <mterry> fginther, I can't quite tell from the logs which test caused the crash
[18:47] <mterry> fginther, it would be interesting to know if it was always the same one
[18:48] <fginther> hmm, I'll see if I can find it
[18:50] <fginther> mterry, looks like "unity.tests.test_shopping_lens.ShoppingLensTests.test_music_lens_has_shopping_results" is the test
[18:50] <fginther> the times in ap_test_debug_log.txt match the timestamp of the crash
[18:51] <mterry> fginther, huh
[18:51] <fginther> plus it looks like it was waiting for unity to start
[18:51] <fginther> ahh. there is maybe a video, checking
[18:51] <mterry> fginther, you look at that, I'll try to see if that's the same on older builds
[18:51] <fginther> ok
[18:52] <bschaefer> silyou fixed more ibus tests? yay
[18:52] <bschaefer> aww he left
[18:52] <mterry> bschaefer, he said he made some progress yeah
[18:52] <mterry> bschaefer, not committed yet
[18:52] <bschaefer> mterry, awesome, yeah I saw those as well...its strange that it would start error like that all of a sudden
[18:54]  * MCR1 is taking on those quilt patch magic now
[18:56] <mterry> fginther, looks like build 64 was unity.tests.test_dash.DashLensResultsTests.test_no_results_message
[19:00] <fginther> mterry, checkout the ogv for that test: http://10.97.0.1:8080/view/autopilot/job/ps-unity-autopilot-release-testing/64/label=autopilot-nvidia/artifact/results/artifacts/unity.tests.test_dash.DashLensResultsTests.test_no_results_message.ogv
[19:00] <fginther> mterry, lots of artifacts on the desktop
[19:01] <mterry> fginther, hrm
[19:02] <mterry> fginther, indicating that X/compiz was off the rails before that test
[19:03] <fginther> mterry, yep
[19:04] <mterry> fginther, well...  I'm inclined to think this is a random nvidia driver bug?  It doesn't seem to affect the builds uniformly
[19:04] <mterry> i.e. this might not stop us from publishing.  Though I don't think it's a great idea to force-publish on a Friday  :)
[19:05] <fginther> mterry, this looks similar to other nvidia bugs I've witnessed in the past
[19:11] <fginther> mterry, are we still missing -dbg packages needed for the compiz crash?
[19:11] <mterry> fginther, I'm not sure what the deal is.  gdb gave several errors about the compiz stack
[19:12] <mterry> fginther, and the PPA doesn't build -dbgsym packages
[19:12] <mterry> fginther, so I tried to rebuild the PPA version of compiz with debug symbols enabled.  But it still complained
[19:12] <fginther> oh
[19:14] <mterry> fginther, I'm not sure how to make it give us symbols
[19:14] <fginther> :-(
[19:34] <MCR1> Mirv: Hi :) Time 4 a short question ?
[19:36] <mterry> fginther, maybe we shouldn't fail the build for nvidia crash files in X/compiz?
[19:36] <mterry> fginther, if we're resigning ourselves to not fixing this in the short term
[19:36] <fginther> mterry, hmmm
[19:38] <fginther> mterry, that should work. If there is an unrelated issue causing compiz to crash, the other tests should hit a compiz crash and fail the build
[19:38] <mterry> fginther, yeah, if it's reliable enough, it should crash a bunch of the tests
[19:39] <mterry> fginther, and we can allow crashes for just the nvidia build, eh?
[19:39] <fginther> mterry, we should be able to key of the driver in lsmod
[19:40] <fginther> mterry, want to try this out and rebuild ps-unity?
[19:40] <mterry> fginther, sure.  Is it ready?
[19:40] <fginther> mterry, I can work on it now :-)
[19:40] <fginther> I'm not that fast
[19:41] <mterry> fginther, yikes....
[19:41] <mterry> fginther, http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/67/
[19:41] <mterry> fginther, I built that earlier for bschaefer
[19:41] <mterry> fginther, why are 460 failures showing as yellow?
[19:42] <bschaefer> eek! that doesn't look good....though it looks like unity just failed to do anything
[19:42] <mterry> bschaefer, bregma ^ see the failure: http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/67/label=autopilot-ati/testReport/junit/unity.tests.launcher.test_icon_behavior/LauncherIconsTests/test_launcher_activate_last_focused_window_Single_Monitor_/
[19:42] <mterry> Is this xpathselect issues?
[19:42] <mterry> I saw some merges related to that go by
[19:43] <bschaefer> yeah, I think that could explain that...
[19:43] <fginther> mterry, jenkins only fails a build if something causes a non-zero error return. Test failures are always considered 'unstable'
[19:43] <bschaefer> because if: self.assertThat(len(controllers), Equals(1) is != 1 then either there is no launcher controller or the path is messed up
[19:43] <mterry> fginther, ah...  and cu2d-unity-head-2.2check decides if its' unstable enough to be red or yellow at that level
[19:45] <bschaefer> soo that xpath change is rather huge...I suppose we should wait for thomi to get on?
[19:47] <fginther> mterry, yes, that looks to be how it works
[19:47] <mterry> fginther, cool.  Still trying to piece this all together  :)
[19:47] <fginther> bschaefer, it's saturday in thomi land :-(
[19:47] <bschaefer> dam, forgot about those time travellers...
[19:49] <MCR1> any quilt patch expert here, who could check plausibility of this: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix966099-refresh-quilt-patch.0/+merge/146203
[19:49] <MCR1> ?
[19:51] <mterry> MCR1, I can a bit
[19:51] <MCR1> \o/
[19:51] <mterry> MCR1, so you are adding a key that replaces the unmaximize one
[19:51] <MCR1> yep
[19:52]  * mterry shrugs.  your diff itself seems fine.  I'll approve
[19:52] <MCR1> \o/
[19:52] <mterry> MCR1, does anything use this yet
[19:52] <MCR1> yes
[19:53] <MCR1> it was the unmaximize_window_key before
[19:53] <bschaefer> mterry, compiz uses it, but its set to disabled, and the unity branch is on hold until that patch get in
[19:53] <bschaefer> (which would be the only thing that depends on that key)
[19:53] <MCR1> exactly
[19:54] <mterry> bschaefer, so we don't have a xpathselect expert until Monday?
[19:54] <bschaefer> mterry, nope :( all of them are from NZ
[19:54] <mterry> eggs in a basket.  OK, no worries.  We can sort on Monday
[19:54]  * bschaefer doesn't like leaving that many failing tests over the weekend
[19:55] <bschaefer> yeah
[19:55] <mterry> bschaefer, well, they aren't getting through to distro, which is all I worry about.  :)  But I'd really like to have a unity stack release.  We didn't all this week for various reasons
[19:55] <fginther> bschaefer, should the libxpath mp be backed out?
[19:56] <bschaefer> fginther, hmm well first we should confirm its the problem, Im rebuilding unity atm to test that out and asked andyrock to run a test
[19:56] <bschaefer> to see if it fails
[19:56] <fginther> bschaefer, ok
[19:56] <MCR1> mterry: I promised JohnLea he could start using this key tomorrow, so thanks a lot ;)
[19:56] <andyrock> bschaefer, what test?
[19:56] <bschaefer> mterry, yeah, its nice to  release, but its not the end of the world :)
[19:56] <bschaefer> andyrock, any, they all seem to be failing umm let me pull one though
[19:56] <mterry> MCR1, heh
[19:57] <bschaefer> unity.tests.launcher.test_keynav.LauncherKeyNavTests.test_launcher_keynav_cycling_forward(Single Monitor)
[19:57] <bschaefer> andyrock, ^
[19:57] <bschaefer> self.assertThat(len(controllers), Equals(1)) -- MismatchError: 1 != 0
[19:57] <bschaefer> is how it fails atm
[19:58] <bschaefer> hmm I can't even build trunk....
[19:58] <bschaefer> /home/bschaefer/src/unity/unity-shared/DebugDBusInterface.cpp:31:30: fatal error: xpathselect/node.h: No such file or directory
[19:58] <bschaefer> andyrock, did you grab trunk in last ~5 min?
[20:00] <andyrock> bschaefer, http://paste.ubuntu.com/1598394/
[20:00] <bschaefer> andyrock, what rev are you on trunk?
[20:00] <andyrock> not the last one let me pull
[20:00] <andyrock> ... trunk
[20:01] <bschaefer> cool, nice to know it passes before trunk...
[20:01] <bschaefer> and you could have just said it passed haha
[20:01]  * bschaefer can't build trunk...
[20:01] <andyrock> bschaefer, you just need libxpathselect
[20:01] <bschaefer> hmm I seem to be missing libxpathselect...which should be in cmake...
[20:02] <bschaefer> yeah, but it should be in cmake...
[20:10] <bschaefer> fginther, mterry hmm well the AP tests pass here as well sooo im not 100% what the problem is :(
[20:10] <mterry> bschaefer, huh
[20:10] <bschaefer> fginther, hmm lets re run the tests to confirm its still broken?
[20:11] <bschaefer> mterry, ^\
[20:11] <mterry> bschaefer, you had to install xpathselect?
[20:11] <mterry> bschaefer, maybe that's not listed as a build-depend in the packaging?
[20:11] <bschaefer> mterry, yup, otherwise unity wont compile
[20:11] <mterry> oh
[20:11] <bschaefer> yeah, so it should be there
[20:11] <bschaefer> I had to install libxpathselect-dev, it could never hurt to double check that though...
[20:12]  * bschaefer started a new test
[20:12] <mterry> bschaefer, OK
[20:12] <fginther> libxpathselect1.1 was installed
[20:12] <bschaefer> hmm maybe all I needed was 1.1
[20:12] <bschaefer> I just went straight to dev
[20:19] <andyrock> bschaefer, i get that error too
[20:19] <andyrock> try to revert thomi's branch
[20:20] <bschaefer> andyrock, really? My AP test is passing, are you running them all?
[20:21] <andyrock> bschaefer, not just that
[20:21] <bschaefer> strange
[20:22] <bschaefer> mterry, fginther soo yeaah, we should revert that branch it seems
[20:25] <fginther> bschaefer, can you do that ?
[20:25] <bschaefer> fginther, yup, let me cherry pick it out
[20:26] <fginther> bschaefer, thanks
[20:32] <bschaefer> fginther, alright, im pretty sure I did that correctly :)
[20:32] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/remove-rev-3098/+merge/146221
[20:32] <bschaefer> andyrock, ^ https://code.launchpad.net/~brandontschaefer/unity/remove-rev-3098/+merge/146221
[20:32] <bschaefer> opps...
[20:34] <andyrock> approved
[20:34] <bschaefer> cool thanks
[20:34] <bschaefer> fginther, when that merges, we'll have to re-package daily-build ppa to test the AP test on jenkins though
[20:34] <bschaefer> unless we point it at the staging ppa
[20:36] <fginther> bschaefer, thanks for the MP. Lets just kick off a new test and re-package the daily-build as soon as it lands
[20:37] <bschaefer> fginther, cool sounds good, though I've no clue how to re-package the daily-build :)
[20:37]  * bschaefer looks at mterry 
[20:37] <fginther> bschaefer, I can do it if mterry is not around
[20:38] <bschaefer> fginther, o cool, alright. It would nice to get those test to pass :)
[20:38] <fginther> agreed
[21:05] <fginther> mterry, compiz and X crashes should be ignored on nvidia starting with the next run
[21:16] <MCR1> bschaefer: I was thinking about how to best solve the Fullscreen-HUD-or-Dash-invoke problem and think I've found the best solution for it :)
[21:17] <MCR1> bschaefer: I wanted to forbid invoking Dash or HUD first completely for FS windows, but JohnLea and Trevinho told me that they are supposed to come up...
[21:18] <MCR1> bschaefer: There would be a ton of problems if we would try to make them come up over the FS windows...
[21:19] <MCR1> bschaefer: But we could simply check if a Fullscreen window is active and toggle fullscreen in the case Dash or HUD are invoked !
[21:19] <MCR1> bschaefer: Or is my logic somehow incorrect ?
[21:20] <Trevinho> MCR1: well, it would be not so good looking an app to switch its state if it is what you mean...
[21:21] <MCR1> Trevinho: well, how would you want to deal with it ?
[21:21] <Trevinho> MCR1: I guess that just hacking unityshell to make FS windows to draw below and making the events to be handled by unity could be an acceptable approach, but I didn't look too much on it
[21:21] <MCR1> Trevinho: Current solution is very suboptimal - if a fullscreen window is running and you invoke the HUD it comes up behind it
[21:22] <Trevinho> MCR1: yes, I know, and that's bad
[21:22] <MCR1> Trevinho: and what is much worse: BLOCKS the toggle-fullscreen shortcut
[21:22] <MCR1> So for someone not knowing that he has to hit Alt again it is an effective hangup
[21:23] <MCR1> very bad...
[21:23] <Trevinho> yep, sure
[21:25] <MCR1> if your solution would work without problems it would be nice ofc, but I see many troubles:
[21:26] <MCR1> For example: Someone watches a fullscreen movie on a decent laptop and invokes the Dash -> the Dash comes up in front of the video -> computer slows down to a crawl
[21:26] <MCR1> I have a fast machine, but try to watch a fullscreen video behind a fullscreened Dash ;)
[21:27] <MCR1> Trevinho: Do you know what I mean ?
[21:27] <MCR1> while simply toggling fullscreen automatically would solve all of those troubles
[21:29] <fginther> mterry, bschaefer, new ps-unity build and test on the way
[21:29]  * bschaefer reads what has been said
[21:29] <bschaefer> fginther, awesome
[21:30] <bschaefer> MCR1, the biggest problem, is theres not win-win solution ...
[21:30] <mterry> fginther, cool
[21:30] <bschaefer> MCR1, the dash should always come up when super is pressed
[21:30] <bschaefer> (same with the hud)
[21:31] <MCR1> yes
[21:31] <bschaefer> imagine if you are fullscreen with a text editor and you want to use the hud to do menu stuff? It should come up
[21:31] <MCR1> sure
[21:34] <bschaefer> fginther, when nvidia crashes, what does the Xorg log say about it?
[21:34] <bschaefer> or any logs in /var/log/
[21:36] <fginther> bschaefer, I don't think those are collected
[21:37] <fginther> will check
[21:37] <bschaefer> fginther, possibly it could help track down problem, though im not expert at look at those logs :)
[21:37] <bschaefer> s/not/no
[21:41] <MCR1> Trevinho: Question: Are all of those textures supposed to be commented out ? : http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3047
[21:42] <MCR1> Trevinho: See  unity-shared/IconRenderer.cpp
[21:43] <MCR1> Trevinho: Seems this causes bug 1103742
[21:59] <mterry> fginther, those logs would be collected by ubuntu-bug.  Any progress on that front?
[22:03] <fginther> mterry, looking
[22:07] <fginther> mterry, sorry, I don't see it, adding it now
[22:23] <fginther> mterry, is there a way to run ubuntu-bug non-interactively? or does it just detect that it's not running in a shell?
[22:24] <mterry> fginther, ah yes, that's the problem we ran into
[22:24] <fginther> grrrr
[22:24] <mterry> fginther, I think veebers was trying earlier
[22:25] <mterry> fginther, I said I didn't know much about trying it that way.  If we can't, it might be worth a patch to ubuntu-bug to add a mode
[22:25] <fginther> hmmm, will consider this some more. yeah a patch might work
[23:07] <Trevinho> MCR1: these were commented in a branch still in WIP that was pushed... You can fix them, until I don't change that again
[23:10] <MCR1> Trevinho: If you do not mind I would fix them, because they break my Launcher visuals ;)
[23:11] <Trevinho> MCR1: sure, do a MP ;)
[23:11] <MCR1> Trevinho: ok, thx
[23:11] <Trevinho> MCR1: I'm leving now, I'll check that later
[23:11] <Trevinho> thank you
[23:11] <MCR1> ok c ya