[00:58] mhall119, Teester_, hey, sorry for earlier [01:00] davidcalle: no worries, will you have a few minutes tommorrow to chat? I just had a couple questions [01:01] mhall119, sure [01:01] great, I'll give you a ping in the morning (my time) [01:01] thanks [01:01] mhall119, perfect :) === bschaefer_ is now known as bschaefer [06:28] duflu is successfully burning my CPU via Thunderbird ;) [06:28] Mirv: Yeah I logged a bug against thunderbird yesterday, but only landed on an existing bug. Mostly ignored [06:29] That reminds me. I need to check out why one of my "small" folders is using 12GB [06:29] 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] Mirv: There are actually separate bugs for "100% CPU during filtering" vs "100% CPU when idle" :P [06:30] heh [06:30] 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] of course === BEC is now known as alpha_ === alpha_ is now known as BEC === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [09:48] 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] erm... my gnome-terminal for some reason maximizes when i click on other windows o_O - raring/unity... has somebody seen that? [11:01] rye: haven't seen that, running pure raring (not daily ppa) [11:02] and using gnome-terminal all the time [11:02] interesting anyway.. [11:02] Mirv: well, me too, (and kazam is broken to show how it behaves...) [11:07] Mirv: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1040885 :) [11:07] Launchpad bug 1040885 in gnome-terminal (Ubuntu) "gnome-terminal auto-restores its size" [Undecided,Confirmed] [11:12] rye: oh! so coming to raring soon, good [11:12] would be worth backporting as well to quantal, precise apparently not affected [11:13] 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] the size changing when changing font size / opening/closing tabs is another bug that doesn't have a fix I think [11:17] anyway, commented on the bug to help if someone wants to propose the SRU [11:18] I mean, do the SRU (until asking for sponsoring) [11:19] 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:19] Launchpad bug 1100970 in unity (Ubuntu) "Dash background flickers and blur is misplaced on intel graphics" [High,Confirmed] === dandrader is now known as dandrader|afk [11:35] ok, patch definitely works === _salem is now known as salem_ === dandrader|afk is now known as dandrader [12:34] hi fginther, can I ask you to review https://code.launchpad.net/~mitya57/jenkins-launchpad-plugin/no-empty-approved-by/+merge/143025 please? === MacSlow is now known as MacSlow|lunch === dandrader is now known as dandrader|afk === rsalveti_ is now known as rsalveti === dandrader|afk is now known as dandrader [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] 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 === MacSlow|lunch is now known as MacSlow [14:37] The UTAH config seems broken (daily tests aren't working) [14:52] mterry: yep, I opened 2 bugs for that [14:52] didrocks, cool [15:25] mitya57, yes, I'll take a look [15:25] thanks fginther! === dandrader is now known as dandrader-afk === dandrader-afk is now known as dandrader === salem_ is now known as _salem === _salem is now known as salem_ [16:30] What's the story with the libunity-0.7 branch? It's not the same as trunk, but why not? [16:31] mhr3, ^ [16:35] mterry, cause it's being developed [16:36] mhr3, fair enough. I'm just used to the brave new world of fresh bits hitting raring moments after landing [16:37] some components could break half the desktop though [17:52] 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] bschaefer: what do you call the daily PPA? [17:54] as for some people it's staging, the other is really daily :) [17:55] yeah, I have both staging and dailing [17:55] daily * [17:55] having both is clearly an issue :) [17:55] didrocks, well bregma was having the problem :) [17:55] * bschaefer updates to join in the fun [17:55] yeah, let's see what he's having :) [17:56] What is Pawel Stolowski's IRC nick? [17:56] mterry: pstolowski [17:56] didrocks, thanks [17:56] he's not online anymore apparently though [17:56] yw [17:56] yar [17:56] "daily" is ppa.launchpad.net/ubuntu-unity/daily-build/ubuntu [17:58] bregma: ah interesting, do you have the logs? [17:58] The following packages will be REMOVED: [17:58] unity [17:58] hmm strange [17:58] well, the reasons why :) [17:58] like apt-get install unity ;) [17:58] 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] well there was a recent ABI break in nux... [18:01] yep, but normally, unity build-dep against latest nux now [18:02] yeah, well ill have everything upgrade shortly [18:02] http://paste.ubuntu.com/1563762/ [18:03] hum [18:03] is the unity build-deps not high enough? [18:03] oh I know [18:03] it was high enough if we built both at the same time [18:04] but we had the cruft in the ppa already due to previous nux not bumping the abi [18:04] and so the versionning requirement was enough [18:04] and so unity started before nux built [18:04] right, http://paste.ubuntu.com/1563770/ [18:04] well, this will be fixed by itself in few hours, when next daily-build is fine [18:04] strange, so do you have to rebuild those again? [18:04] I hope that they will fix UTAH by then [18:05] unity needs rebuilding against the current nux, 'sall [18:05] yep [18:05] cool, well hopefully my trunk builds as well :) [18:05] heh, ideally, if we didn't get those UTAH issue, you don't need any daily/staging ppa [18:06] just have your latest ubuntu + the project you are working on [18:07] 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] bschaefer: well, you will get daily content without it (and validated) soon :) [18:07] I have ubuntu-unity-daily-build-raring.list and unity-team-staging-raring.list [18:08] hmm [18:08] so no ppa is even better [18:08] I wonder if I should remove one [18:08] didrocks, o awesome! [18:08] bschaefer: both!!! :) [18:08] didrocks, alright, Ill do that right now [18:08] :) [18:08] thanks! [18:08] 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] yw, thanks for mentionning the issue bschaefer, bregma. It's another argument to automatically bump the build-deps [18:09] mterry: I don't think we can do that yet [18:53] 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] fginther, yeah, Trevinho mentioned the second one as a problem with /dev/random ... [18:55] fginther, but Iam unable to reproduce that failing :( [18:56] looks to me more like two processes attempting to open the same socket [18:57] * bregma investigates [18:57] fginther, does the intel arch always run first? [18:57] bschaefer, bregma thanks! this are causing about 1/2 of the jobs to fail [18:58] bschaefer, they typically run simultaneously, but not gauranteed because they are just build jobs being sent to a queue [18:58] 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] dang... [18:58] they may not always run on the same builder either [18:59] fginther, is there a way to tell from looking at the logs? [18:59] tell that they ran at the same time? [19:00] fginther, hmm yeah, but they should be running in their own environment anyway... [19:00] fginther, as it always seems to be a problem with the amd64 only [19:01] 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] bschaefer, yes, all the failures are on amd64, perhaps it builds just a tick slower? [19:02] fginther, i just find it strange that all of them are failing on amd64 [19:03] fginther, hmm possibly, [19:04] as, the error "Could not open X display" should mean that something else already has the display open [19:04] 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] bschaefer, that would have to be specified in unity tests themselves [19:05] yeah [19:05] fginther, :), cool, well off to see what I can find out [19:05] jenkins isn't doing anything special to provide an X environment [19:06] bschaefer, do you know of a bug for the /dev/random issue? [19:06] fginther, Trevinho mentioned the /dev/random problem but I wasn't sure how he arrived at that [19:07] bschaefer, ok, thanks, maybe Trevinho is listening :-) [19:07] hopefully :) [19:08] 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] there you can see the timestamp for the build [19:08] fginther, awesome, thanks! [19:09] the 'test-unit' test used GDK to perform drawing and get input, it evidently connects to the X server [19:09] given it's the failing test, I think that's a rational explanation [19:09] yes it is, hmm interesting [19:10] hmm we should just be using the display from Nux though [19:10] display pointer [19:11] bregma, http://paste.ubuntu.com/1563908/ [19:11] theres also 4 test that open the the display server... [19:12] 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] soo hows the xorg test suite coming along? [19:12] as that should solve those problems... [19:13] the failing test uses GTK, [19:13] xorg-gtest will not solve that problem [19:14] hmm, are you talking about: unit/TestMain.cpp:64: gtk_init(&argc, &argv); [19:14] that where it all begins, yes [19:14] it's required because it's testing panel-service, which is a gtk app [19:15] hmm because we have another main loop going in compiz... [19:15] * bschaefer doesn't think that is related [19:19] wait a minute, when did we start running all the non-headless tests in jenkins? [19:19] hmm that would explain both the bugs... [19:20] should we only be running the xless test? [19:20] shouldn't* [19:29] bregma, the jenkins job is only executing the tests triggered by the packaging (debian/rules) [19:30] debian/rules runs check-headless, which does not include the failing tests [19:31] unless I'm reading the CMakefiles.txt wrong, it's not my area of expertise yet [19:31] hmm its running the gestures tests [19:31] the make check-headless is [19:34] yeah, gesture tests are OK AFACT, they don't actually use X [19:34] so thats a different issue, yeah, alright...so why would a test try to open X...hmm [19:35] bregma, how could you tell from the logs that 'unit-test' was causing the problem? [19:35] as I don't see where its failing on jenkins logs, besides it failed... [19:35] um, the error message [19:36] FAIL: ./test-unit [19:37] bschaefer, bregma I think I know what's happening [19:37] * bschaefer only sees the gesture test failing [19:37] there is a pbuilder hook to fall back to "make check" if "make check-headless" fails [19:38] oo there it is... [19:38] odd [19:38] the intermittent GesturalWindowSwitcherTest.NewDragAfterTapAndHoldSelectsNextWindow failures are causing "make check-headless" to fail [19:38] So, I can fix the X display issue [19:38] fginther, oo...so the real problem is still that test [19:39] bschaefer, I believe so. [19:39] GesturalWindowSwitcherTest.NewDragAfterTapAndHoldSelectsNextWindow is a separate problem (I think) [19:39] well a make check is happening because of that test failure [19:40] make check shouldn;t be happening [19:40] 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] bregma, right. I can fix the job to not attempt to run tests outside of what's defined in the package [19:41] 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] OK, we're already investigating the NewDragAfterTapAndHoldSelectsNextWindow problem [19:42] only fails on amd64, sounds like either an uninitialized variable, a rounding issue, or a timing ssue [19:42] givem I can;t repro it on my amd64 machine, it's unlikely a rounding issue [19:42] hmm ill did through the switcher controller for an unitit var [19:43] uninited [19:43] bregma, bschaefer thanks for your help on the X issue, sorry I didn't notice the actual root cause sooner [19:43] it could be in the gesture stack somewhere since the problem is that a particular gesture is not having an effect [19:43] so it could be in nux as well? [19:44] coud be anywhere [19:44] I can dig through that stack for an uninited issue as well...as for the timing issue...hm [19:44] 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] and get an amd64 to test it out [19:45] why it would start showing up after my changes to the switcher controller is unclear [19:45] I'm trying in my pbuilder, it's slower [19:45] it wasn't only your branch though, Trevinho had a branch that failed a couple times [19:45] but then it went through [19:45] on the gesture test? [19:45] yup [19:45] * bschaefer goes to dig that up [19:46] https://code.launchpad.net/~3v1n0/unity/shortcuts-modeller/+merge/144414 [19:46] he has some changes to the switcher as well though [19:47] nevermind shortcut not switcher [19:47] * bschaefer wonders when this started [19:50] 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] yup just saw that one [19:50] fginther, is the branch that run is for in the full log? [19:51] found it [19:51] its in params [19:51] https://code.launchpad.net/~3v1n0/unity/launchers-resize-new/+merge/135816 [19:51] yes, you can also find it in the "parameter" link on the left side of the jenkins page [19:54] though that branch might just be the first one that failed after the problem got in... [19:58] OK, so this switcher gesture failure predates my switcher changes [19:58] I don't feel so bad [20:00] :), I found 1 uninited var in launcher.cpp but i don't think it will cause the problem [20:00] which is something that branch touched but hmm... [20:07] found some uninit vars in GesturalWindowSwitcher... that would do it [20:08] o nice, I found just an enum that was uninit in the SwitcherController... [20:08] but it only gets used after being assigned [20:11] the umm index_icon_hit? [20:12] or accumulated_horizontal_drag, which doesn't get assigned until the state is of a gesture type but hmm [20:12] 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] bschaefer, https://code.launchpad.net/~bregma/unity/initialize_horizontal_drag/+merge/144579 won;t hurt, worth a try [20:13] bregma, very, lets see if it works :) [20:14] approved [20:15] jongleur, from what I know, there is very little documentation doing things like that :( [20:15] bschaefer: I guessed so, that's why I hoped to find some hints here ;) [20:15] jongleur, so what are you trying to do? Besides make transparent circular/flower shaped windows? [20:17] 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] 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] hmm so decors are only rendered on windows if it has this state: CompWindowTypeDesktopMask [20:19] so in general it would be possible to not set that state flag and that's it... [20:19] yes, but it is going to be a desktop window, but yes you can get around the compiz plugin [20:19] for the decor [20:20] okay... using the CompWindowTypeDesktopMask flag fr the windowstate and disabling the compiz plugin should do the trick. [20:20] Thanks - will put that into my notes and try it out in the next days [20:20] well if you disable it you wont need to set that flag :), its enabled by default [20:21] 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] 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] sure [20:22] but you should be able to unset it... :) [20:23] 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] well really, since you don't want to talk directly to compiz [20:24] is you'll have to look at which X atom is equal to CompWindowTypeDesktopMask [20:25] 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] okay, thanks for your help [20:26] np! [20:26] I'll come back if I have new questions ;) [20:27] alright === salem_ is now known as _salem [23:01] 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] 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] saw the merge, I re-approved one of the previously failing MPs to see