| davidcalle | mhall119, Teester_, hey, sorry for earlier | 00:58 |
|---|---|---|
| mhall119 | davidcalle: no worries, will you have a few minutes tommorrow to chat? I just had a couple questions | 01:00 |
| 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 :) | 01:01 |
| === bschaefer_ is now known as bschaefer | ||
| 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:28 |
| 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:29 |
| 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:30 |
| Mirv | of course | 06:32 |
| === 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 | ||
| rye | join #archlinux | 09:48 |
| * rye tries to register on arch bbs to give the link to u1 bugreport. But can't. Please disregard that join msg :) | 09:49 | |
| rye | erm... my gnome-terminal for some reason maximizes when i click on other windows o_O - raring/unity... has somebody seen that? | 10:55 |
| Mirv | rye: haven't seen that, running pure raring (not daily ppa) | 11:01 |
| 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:02 |
| rye | Mirv: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1040885 :) | 11:07 |
| ubot5 | Launchpad bug 1040885 in gnome-terminal (Ubuntu) "gnome-terminal auto-restores its size" [Undecided,Confirmed] | 11:07 |
| 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:12 |
| 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:13 |
| Mirv | the size changing when changing font size / opening/closing tabs is another bug that doesn't have a fix I think | 11:16 |
| Mirv | anyway, commented on the bug to help if someone wants to propose the SRU | 11:17 |
| Mirv | I mean, do the SRU (until asking for sponsoring) | 11:18 |
| 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:19 |
| ubot5 | Launchpad bug 1100970 in unity (Ubuntu) "Dash background flickers and blur is misplaced on intel graphics" [High,Confirmed] | 11:19 |
| === dandrader is now known as dandrader|afk | ||
| rye | ok, patch definitely works | 11:35 |
| === _salem is now known as salem_ | ||
| === dandrader|afk is now known as dandrader | ||
| mitya57 | hi fginther, can I ask you to review https://code.launchpad.net/~mitya57/jenkins-launchpad-plugin/no-empty-approved-by/+merge/143025 please? | 12:34 |
| === 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 | ||
| * 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:56 | |
| 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 | 13:57 |
| === MacSlow|lunch is now known as MacSlow | ||
| mterry | The UTAH config seems broken (daily tests aren't working) | 14:37 |
| didrocks | mterry: yep, I opened 2 bugs for that | 14:52 |
| mterry | didrocks, cool | 14:52 |
| fginther | mitya57, yes, I'll take a look | 15:25 |
| mitya57 | thanks fginther! | 15:25 |
| === 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_ | ||
| mterry | What's the story with the libunity-0.7 branch? It's not the same as trunk, but why not? | 16:30 |
| mterry | mhr3, ^ | 16:31 |
| mhr3 | mterry, cause it's being developed | 16:35 |
| mterry | mhr3, fair enough. I'm just used to the brave new world of fresh bits hitting raring moments after landing | 16:36 |
| mhr3 | some components could break half the desktop though | 16:37 |
| 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:52 |
| * bschaefer was about to upgrade | 17:53 | |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| * bschaefer updates to see as well | 17:59 | |
| bschaefer | well there was a recent ABI break in nux... | 18:00 |
| didrocks | yep, but normally, unity build-dep against latest nux now | 18:01 |
| bschaefer | yeah, well ill have everything upgrade shortly | 18:02 |
| bregma | http://paste.ubuntu.com/1563762/ | 18:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| didrocks | just have your latest ubuntu + the project you are working on | 18:06 |
| 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:07 |
| 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:08 |
| didrocks | mterry: I don't think we can do that yet | 18:09 |
| 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:53 |
| 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:55 |
| bregma | looks to me more like two processes attempting to open the same socket | 18:56 |
| * 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:57 |
| 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:58 |
| bschaefer | fginther, is there a way to tell from looking at the logs? | 18:59 |
| fginther | tell that they ran at the same time? | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| bschaefer | fginther, hmm possibly, | 19:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| fginther | bschaefer, ok, thanks, maybe Trevinho is listening :-) | 19:07 |
| bschaefer | hopefully :) | 19:07 |
| 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:08 |
| 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:09 |
| bschaefer | hmm we should just be using the display from Nux though | 19:10 |
| bschaefer | display pointer | 19:10 |
| bschaefer | bregma, http://paste.ubuntu.com/1563908/ | 19:11 |
| bschaefer | theres also 4 test that open the the display server... | 19:11 |
| 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:12 |
| bregma | the failing test uses GTK, | 19:13 |
| bregma | xorg-gtest will not solve that problem | 19:13 |
| 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:14 |
| bschaefer | hmm because we have another main loop going in compiz... | 19:15 |
| * bschaefer doesn't think that is related | 19:15 | |
| 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:19 |
| bschaefer | should we only be running the xless test? | 19:20 |
| bschaefer | shouldn't* | 19:20 |
| fginther | bregma, the jenkins job is only executing the tests triggered by the packaging (debian/rules) | 19:29 |
| bregma | debian/rules runs check-headless, which does not include the failing tests | 19:30 |
| 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:31 |
| 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:34 |
| 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:35 |
| bregma | FAIL: ./test-unit | 19:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 | |
| 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:46 |
| bschaefer | nevermind shortcut not switcher | 19:47 |
| * bschaefer wonders when this started | 19:47 | |
| 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:50 |
| 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:51 |
| bschaefer | though that branch might just be the first one that failed after the problem got in... | 19:54 |
| bregma | OK, so this switcher gesture failure predates my switcher changes | 19:58 |
| bregma | I don't feel so bad | 19:58 |
| 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:00 |
| bregma | found some uninit vars in GesturalWindowSwitcher... that would do it | 20:07 |
| 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:08 |
| bschaefer | the umm index_icon_hit? | 20:11 |
| 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:12 |
| 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:13 |
| bschaefer | approved | 20:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| jongleur | okay, thanks for your help | 20:26 |
| bschaefer | np! | 20:26 |
| jongleur | I'll come back if I have new questions ;) | 20:26 |
| bschaefer | alright | 20:27 |
| === salem_ is now known as _salem | ||
| 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 | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!