[00:58] <davidcalle> mhall119, Teester_, hey, sorry for earlier
[01:00] <mhall119> davidcalle: no worries, will you have a few minutes tommorrow to chat?  I just had a couple questions
[01:01] <davidcalle> mhall119, sure
[01:01] <mhall119> great, I'll give you a ping in the morning (my time)
[01:01] <mhall119> thanks
[01:01] <davidcalle> mhall119, perfect :)
[06:28] <Mirv> duflu is successfully burning my CPU via Thunderbird ;)
[06:28] <duflu> Mirv: Yeah I logged a bug against thunderbird yesterday, but only landed on an existing bug. Mostly ignored
[06:29] <duflu> That reminds me. I need to check out why one of my "small" folders is using 12GB
[06:29] <Mirv> I don't know why TB filtering is so slow, but for example if I get 100 bug e-mails it takes a while of 100% CPU burn before they are in the folders
[06:29] <duflu> Mirv: There are actually separate bugs for "100% CPU during filtering" vs "100% CPU when idle" :P
[06:30] <Mirv> heh
[06:30] <duflu> Mirv: And of course if thunderbird is spinning and constantly redrawing part of itself, that forces compiz to comply and update the screen. Constantly.
[06:32] <Mirv> of course
[09:48] <rye> join #archlinux
[09:49]  * rye tries to register on arch bbs to give the link to u1 bugreport. But can't. Please disregard that join msg :)
[10:55] <rye> erm... my gnome-terminal for some reason maximizes when i click on other windows o_O - raring/unity... has somebody seen that?
[11:01] <Mirv> rye: haven't seen that, running pure raring (not daily ppa)
[11:02] <Mirv> and using gnome-terminal all the time
[11:02] <Mirv> interesting anyway..
[11:02] <rye> Mirv: well, me too, (and kazam is broken to show how it behaves...)
[11:07] <rye> Mirv: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1040885 :)
[11:12] <Mirv> rye: oh! so coming to raring soon, good
[11:12] <Mirv> would be worth backporting as well to quantal, precise apparently not affected
[11:13] <rye> Mirv: i think everything is affected, I remember I was given a video a year ago (i guess on precise) where gnome terminal was auto shrinking but this will need to be checked
[11:16] <Mirv> the size changing when changing font size / opening/closing tabs is another bug that doesn't have a fix I think
[11:17] <Mirv> anyway, commented on the bug to help if someone wants to propose the SRU
[11:18] <Mirv> I mean, do the SRU (until asking for sponsoring)
[11:19] <rye> duflu: if you guys need a device to test https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1100970 on - feel free to ping me (https://launchpad.net/~rye)
[11:35] <rye> ok, patch definitely works
[12:34] <mitya57> hi fginther, can I ask you to review https://code.launchpad.net/~mitya57/jenkins-launchpad-plugin/no-empty-approved-by/+merge/143025 please?
[13:56]  * luv started working on the patch to show list of windows when right-clinking an BamfIconLauncher - so far so good!, would say 30% done in one night
[13:57] <luv> much easier than I expected - most of the work was to backport GetWindowName and few other functions from HEAD to Unity in 12.04 LTS
[14:37] <mterry> The UTAH config seems broken (daily tests aren't working)
[14:52] <didrocks> mterry: yep, I opened 2 bugs for that
[14:52] <mterry> didrocks, cool
[15:25] <fginther> mitya57, yes, I'll take a look
[15:25] <mitya57> thanks fginther!
[16:30] <mterry> What's the story with the libunity-0.7 branch?  It's not the same as trunk, but why not?
[16:31] <mterry> mhr3, ^
[16:35] <mhr3> mterry, cause it's being developed
[16:36] <mterry> mhr3, fair enough.  I'm just used to the brave new world of fresh bits hitting raring moments after landing
[16:37] <mhr3> some components could break half the desktop though
[17:52] <bregma> just a warning: I did an apt-get upgrade from the daily PPA and it removed unity and refuses to install it, beware
[17:53]  * bschaefer was about to upgrade
[17:54] <didrocks> bschaefer: what do you call the daily PPA?
[17:54] <didrocks> as for some people it's staging, the other is really daily :)
[17:55] <bschaefer> yeah, I have both staging and dailing
[17:55] <bschaefer> daily *
[17:55] <didrocks> having both is clearly an issue :)
[17:55] <bschaefer> didrocks, well bregma was having the problem :)
[17:55]  * bschaefer updates to join in the fun
[17:55] <didrocks> yeah, let's see what he's having :)
[17:56] <mterry> What is Pawel Stolowski's IRC nick?
[17:56] <didrocks> mterry: pstolowski
[17:56] <mterry> didrocks, thanks
[17:56] <didrocks> he's not online anymore apparently though
[17:56] <didrocks> yw
[17:56] <mterry> yar
[17:56] <bregma> "daily" is ppa.launchpad.net/ubuntu-unity/daily-build/ubuntu
[17:58] <didrocks> bregma: ah interesting, do you have the logs?
[17:58] <bschaefer> The following packages will be REMOVED:
[17:58] <bschaefer>   unity
[17:58] <bschaefer> hmm strange
[17:58] <didrocks> well, the reasons why :)
[17:58] <didrocks> like apt-get install unity ;)
[17:58] <didrocks> bregma: because of UTAH failing, I have no idea of the state of the ppa
[17:59]  * bschaefer updates to see as well
[18:00] <bschaefer> well there was a recent ABI break in nux...
[18:01] <didrocks> yep, but normally, unity build-dep against latest nux now
[18:02] <bschaefer> yeah, well ill have everything upgrade shortly
[18:02] <bregma> http://paste.ubuntu.com/1563762/
[18:03] <didrocks> hum
[18:03] <didrocks> is the unity build-deps not high enough?
[18:03] <didrocks> oh I know
[18:03] <didrocks> it was high enough if we built both at the same time
[18:04] <didrocks> but we had the cruft in the ppa already due to previous nux not bumping the abi
[18:04] <didrocks> and so the versionning requirement was enough
[18:04] <didrocks> and so unity started before nux built
[18:04] <bregma> right, http://paste.ubuntu.com/1563770/
[18:04] <didrocks> well, this will be fixed by itself in few hours, when next daily-build is fine
[18:04] <bschaefer> strange, so do you have to rebuild those again?
[18:04] <didrocks> I hope that they will fix UTAH by then
[18:05] <bregma> unity needs rebuilding against the current nux, 'sall
[18:05] <didrocks> yep
[18:05] <bschaefer> cool, well hopefully my trunk builds as well :)
[18:05] <didrocks> heh, ideally, if we didn't get those UTAH issue, you don't need any daily/staging ppa
[18:06] <didrocks> just have your latest ubuntu + the project you are working on
[18:07] <bschaefer> i usually try to stay up to date with staging/daily, though I should make sure I only have 1 of those ppas...
[18:07] <didrocks> bschaefer: well, you will get daily content without it (and validated) soon :)
[18:07] <bschaefer> I have ubuntu-unity-daily-build-raring.list and unity-team-staging-raring.list
[18:08] <bschaefer> hmm
[18:08] <didrocks> so no ppa is even better
[18:08] <bschaefer> I wonder if I should remove one
[18:08] <bschaefer> didrocks, o awesome!
[18:08] <didrocks> bschaefer: both!!! :)
[18:08] <bschaefer> didrocks, alright, Ill do that right now
[18:08] <didrocks> :)
[18:08] <bschaefer> thanks!
[18:08] <mterry> didrocks, btw, debian/ added to home-scope, but needs unpackages libunity-0.7, so not sure you can do anything interesting like daily-builds yet
[18:08] <didrocks> yw, thanks for mentionning the issue bschaefer, bregma. It's another argument to automatically bump the build-deps
[18:09] <didrocks> mterry: I don't think we can do that yet
[18:53] <fginther> bregma, bschaefer, I've noticed 2 recurring failures in the unity autolanding job that are failing multiple merges. Can either of you take a look? lp:1103487 & lp:1103632
[18:55] <bschaefer> fginther, yeah, Trevinho mentioned the second one as a problem with /dev/random ...
[18:55] <bschaefer> fginther, but Iam unable to reproduce that failing :(
[18:56] <bregma> looks to me more like two processes attempting to open the same socket
[18:57]  * bregma investigates 
[18:57] <bschaefer> fginther, does the intel arch always run first?
[18:57] <fginther> bschaefer, bregma thanks! this are causing about 1/2 of the jobs to fail
[18:58] <fginther> bschaefer, they typically run simultaneously, but not gauranteed because they are just build jobs being sent to a queue
[18:58] <bschaefer> fginther, as it could be the intel one isn't getting shut down completely and the amd arc is attempting to open the display when something already owns it...
[18:58] <bschaefer> dang...
[18:58] <fginther> they may not always run on the same builder either
[18:59] <bschaefer> fginther, is there a way to tell from looking at the logs?
[18:59] <fginther> tell that they ran at the same time?
[19:00] <bschaefer> fginther, hmm yeah, but they should be running in their own environment anyway...
[19:00] <bschaefer> fginther, as it always seems to be a problem with the amd64 only
[19:01] <fginther> bschaefer, the build jobs are just pbuilders running on possibly the same host. I believe sockets are provided by the host, so two jobs could hit a race condition
[19:02] <fginther> bschaefer, yes, all the failures are on amd64, perhaps it builds just a tick slower?
[19:02] <bschaefer> fginther, i just find it strange that all of them are failing on amd64
[19:03] <bschaefer> fginther, hmm possibly,
[19:04] <bschaefer> as, the error "Could not open X display"  should mean that something else already has the display open
[19:04] <bschaefer> fginther, is there a hard coding to open display :0 ?
[19:04]  * bschaefer ins't 100% sure how all the jenkins magic works
[19:04] <fginther> bschaefer, that would have to be specified in unity tests themselves
[19:05] <bschaefer> yeah
[19:05] <bschaefer> fginther, :), cool, well off to see what I can find out
[19:05] <fginther> jenkins isn't doing anything special to provide an X environment
[19:06] <fginther> bschaefer, do you know of a bug for the /dev/random issue?
[19:06] <bschaefer> fginther, Trevinho mentioned the /dev/random problem but I wasn't sure how he arrived at that
[19:07] <fginther> bschaefer, ok, thanks, maybe Trevinho is listening :-)
[19:07] <bschaefer> hopefully :)
[19:08] <fginther> bschaefer, by the way, if you want to get more details from jenkins, you can add "/api/xml" to any url. For example: https://jenkins.qa.ubuntu.com/job/unity-mbs-autolanding/335/build=pbuilder,distribution=raring,flavor=amd64/api/xml
[19:08] <fginther> there you can see the timestamp for the build
[19:08] <bschaefer> fginther, awesome, thanks!
[19:09] <bregma> the 'test-unit' test used GDK to perform drawing and get input, it evidently connects to the X server
[19:09] <bregma> given it's the failing test, I think that's a rational explanation
[19:09] <bschaefer> yes it is, hmm interesting
[19:10] <bschaefer> hmm we should just be using the display from Nux though
[19:10] <bschaefer> display pointer
[19:11] <bschaefer> bregma, http://paste.ubuntu.com/1563908/
[19:11] <bschaefer> theres also 4 test that open the the display server...
[19:12] <bregma> a lot of tests that require X don't get run in the builders, because they break (and they don;t get run by developers, either, evidently)
[19:12] <bschaefer> soo hows the xorg test suite coming along?
[19:12] <bschaefer> as that should solve those problems...
[19:13] <bregma> the failing test uses GTK,
[19:13] <bregma> xorg-gtest will not solve that problem
[19:14] <bschaefer> hmm, are you talking about: unit/TestMain.cpp:64:  gtk_init(&argc, &argv);
[19:14] <bregma> that where it all begins, yes
[19:14] <bregma> it's required because it's testing panel-service, which is a gtk app
[19:15] <bschaefer> hmm because we have another main loop going in compiz...
[19:15]  * bschaefer doesn't think that is related
[19:19] <bregma> wait a minute, when did we start running all the non-headless tests in jenkins?
[19:19] <bschaefer> hmm that would explain both the bugs...
[19:20] <bschaefer> should we only be running the xless test?
[19:20] <bschaefer> shouldn't*
[19:29] <fginther> bregma, the jenkins job is only executing the tests triggered by the packaging (debian/rules)
[19:30] <bregma> debian/rules runs check-headless, which does not include the failing tests
[19:31] <bregma> unless I'm reading the CMakefiles.txt wrong, it's not my area of expertise yet
[19:31] <bschaefer> hmm its running the gestures tests
[19:31] <bschaefer> the make check-headless is
[19:34] <bregma> yeah, gesture tests are OK AFACT, they don't actually use X
[19:34] <bschaefer> so thats a different issue, yeah, alright...so why would a test try to open X...hmm
[19:35] <bschaefer> bregma, how could you tell from the logs that 'unit-test' was causing the problem?
[19:35] <bschaefer> as I don't see where its failing on jenkins logs, besides it failed...
[19:35] <bregma> um, the error message
[19:36] <bregma> FAIL: ./test-unit
[19:37] <fginther> bschaefer, bregma I think I know what's happening
[19:37]  * bschaefer only sees the gesture test failing
[19:37] <fginther> there is a pbuilder hook to fall back to "make check" if "make check-headless" fails
[19:38] <bschaefer> oo there it is...
[19:38] <bschaefer> odd
[19:38] <fginther> the intermittent  GesturalWindowSwitcherTest.NewDragAfterTapAndHoldSelectsNextWindow failures are causing "make check-headless" to fail
[19:38] <fginther> So, I can fix the  X display issue
[19:38] <bschaefer> fginther, oo...so the real problem is still that test
[19:39] <fginther> bschaefer, I believe so.
[19:39] <bregma> GesturalWindowSwitcherTest.NewDragAfterTapAndHoldSelectsNextWindow is a separate problem (I think)
[19:39] <bschaefer> well a make check is happening because of that test failure
[19:40] <bregma> make check shouldn;t be happening
[19:40] <fginther> The pbuilder hook was a holdover from the time when building the tests were not baked into the packaging. It just never got cleanup
[19:40] <fginther> bregma, right. I can fix the job to not attempt to run tests outside of what's defined in the package
[19:41] <bschaefer> yeah, but we still need to fix that gesture test...which I don't see how that is the only gesture test that fails as all the other test use the same logic...
[19:41] <bregma> OK, we're already investigating the NewDragAfterTapAndHoldSelectsNextWindow problem
[19:42] <bregma> only fails on amd64, sounds like either an uninitialized variable, a rounding issue, or a timing ssue
[19:42] <bregma> givem I can;t repro it on my amd64 machine, it's unlikely a rounding issue
[19:42] <bschaefer> hmm ill did through the switcher controller for an unitit var
[19:43] <bschaefer> uninited
[19:43] <fginther> bregma, bschaefer thanks for your help on the X issue, sorry I didn't notice the actual root cause sooner
[19:43] <bregma> it could be in the gesture stack somewhere since the problem is that a particular gesture is not having an effect
[19:43] <bschaefer> so it could be in nux as well?
[19:44] <bregma> coud be anywhere
[19:44] <bschaefer> I can dig through that stack for an uninited issue as well...as for the timing issue...hm
[19:44] <bschaefer> it should randomly happen on one of our machines ... and Trevinho can't repro it either
[19:44]  * bschaefer needs to remove a few CPUs
[19:44] <bschaefer> and get an amd64 to test it out
[19:45] <bregma> why it would start showing up after my changes to the switcher controller is unclear
[19:45] <bregma> I'm trying in my pbuilder, it's slower
[19:45] <bschaefer> it wasn't only your branch though, Trevinho had a branch that failed a couple times
[19:45] <bschaefer> but then it went through
[19:45] <bregma> on the gesture test?
[19:45] <bschaefer> yup
[19:45]  * bschaefer goes to dig that up
[19:46] <bschaefer> https://code.launchpad.net/~3v1n0/unity/shortcuts-modeller/+merge/144414
[19:46] <bschaefer> he has some changes to the switcher as well though
[19:47] <bschaefer> nevermind shortcut not switcher
[19:47]  * bschaefer wonders when this started
[19:50] <fginther> bschaefer, it has not gone on for long. the first occurrance I can find is https://jenkins.qa.ubuntu.com/job/unity-mbs-autolanding/317/ from Jan 18
[19:50] <bschaefer> yup just saw that one
[19:50] <bschaefer> fginther, is the branch that run is for in the full log?
[19:51] <bschaefer> found it
[19:51] <bschaefer> its in params
[19:51] <bschaefer> https://code.launchpad.net/~3v1n0/unity/launchers-resize-new/+merge/135816
[19:51] <fginther> yes, you can also find it in the "parameter" link on the left side of the jenkins page
[19:54] <bschaefer> though that branch might just be the first one that failed after the problem got in...
[19:58] <bregma> OK, so this switcher gesture failure predates my switcher changes
[19:58] <bregma> I don't feel so bad
[20:00] <bschaefer> :), I found 1 uninited var in launcher.cpp but i don't think it will cause the problem
[20:00] <bschaefer> which is something that branch touched but hmm...
[20:07] <bregma> found some uninit vars in GesturalWindowSwitcher...  that would do it
[20:08] <bschaefer> o nice, I found just an enum that was uninit in the SwitcherController...
[20:08] <bschaefer> but it only gets used after being assigned
[20:11] <bschaefer> the umm index_icon_hit?
[20:12] <bschaefer> or accumulated_horizontal_drag, which doesn't get assigned until the state is of a gesture type but hmm
[20:12] <jongleur> Hi. Is there any documentation about (or the possibility to) implementing applications with undecorated, transparent or partly transparent (= freely shaped) windows in Unity? Like a circular window, a flower-shaped one and so on? I search for documentation about that, but wasn't successful up to now
[20:13] <bregma> bschaefer, https://code.launchpad.net/~bregma/unity/initialize_horizontal_drag/+merge/144579 won;t hurt, worth a try
[20:13] <bschaefer> bregma, very, lets see if it works :)
[20:14] <bschaefer> approved
[20:15] <bschaefer> jongleur, from what I know, there is very little documentation doing things like that :(
[20:15] <jongleur> bschaefer: I guessed so, that's why I hoped to find some hints here ;)
[20:15] <bschaefer> jongleur, so what are you trying to do? Besides make transparent circular/flower shaped windows?
[20:17] <jongleur> I would like to develop a framework for multitouch/tangible applications (multitouch should be clear, I think, Tangibles are these physical objects you use as a kind of direct manipulation tool in multitouch environments like the M$ surface or similar devices)
[20:18] <jongleur> I think about implementing something like that as a master thesis and try to figure out what may be possible and what's not
[20:18] <bschaefer> hmm so decors are only rendered on windows if it has this state: CompWindowTypeDesktopMask
[20:19] <jongleur> so in general it would be possible to not set that state flag and that's it...
[20:19] <bschaefer> yes, but it is going to be a desktop window, but yes you can get around the compiz plugin
[20:19] <bschaefer> for the decor
[20:20] <jongleur> okay... using the CompWindowTypeDesktopMask flag fr the windowstate and disabling the compiz plugin should do the trick.
[20:20] <jongleur> Thanks - will put that into my notes and try it out in the next days
[20:20] <bschaefer> well if you disable it you wont need to set that flag :), its enabled by default
[20:21] <bschaefer> jongleur, the glDraw function for the decor: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/view/head:/plugins/decor/src/decor.cpp#L155
[20:22] <bschaefer> so it only paints the decor on windows that are set to CompWindowTypeDesktopMask, but you'll also have to look at when that is getting set for each window
[20:22] <jongleur> sure
[20:22] <bschaefer> but you should be able to unset it... :)
[20:23] <jongleur> but if I disable that flag, there's simply n decoration? then I only have a logical window without anything visible as long as I don't draw anything?
[20:24] <bschaefer> well really, since you don't want to talk directly to compiz
[20:24] <bschaefer> is you'll have to look at which X atom is equal to CompWindowTypeDesktopMask
[20:25] <bschaefer> and make sure that isn't getting set for you application, or worst case you can always set this X atom: _NET_WM_WINDOW_TYPE_DOCK
[20:26] <jongleur> okay, thanks for your help
[20:26] <bschaefer> np!
[20:26] <jongleur> I'll come back if I have new questions ;)
[20:27] <bschaefer> alright
[23:01] <fginther> bregma, bschaefer, https://code.launchpad.net/~bregma/unity/initialize_horizontal_drag/+merge/144579 merged. I'll monitor the builds to see if that resolves the issue
[23:01] <bschaefer> fginther, thanks! Looks like the test passed as well, so hopefully that was the correct fix and not one of the random times it doesn't fail :)
[23:01] <bregma> saw the merge, I re-approved one of the previously failing MPs to see