| smspillaz | 1 | 00:15 |
|---|---|---|
| smspillaz | oops | 00:16 |
| smspillaz | luv: A shortcut would be ./build/tests/test-gtest --gtest_filter=*YourTestName* | 00:17 |
| === rsalveti_ is now known as rsalveti | ||
| Mirv | ritz: hi. what kind of assistance you'd need? | 05:05 |
| ritz | Mirv unity-2d seems to be rendering as all black with twinview/nvidia | 05:22 |
| ritz | bugs.launchpad.net/bugs/1096954 | 05:22 |
| ritz | disabling composite manually by commenting out helps | 05:23 |
| ritz | I have to write a reproducer to test this out | 05:23 |
| ritz | Had spoken to didirocks about this | 05:23 |
| Mirv | right | 05:23 |
| ritz | coming from a important customer | 05:24 |
| Mirv | we've one unity-2d update in the pipeline, but it may be that it does not address that issue so if a fix is found we'll need another update | 05:24 |
| Mirv | the bugs fixed in the upcoming update are listed here http://launchpadlibrarian.net/129102713/unity-2d_5.14.0-0ubuntu1_source.changes | 05:25 |
| ritz | unfortunately , been busy with other issues and will be on vacation from 8th until 20th | 05:25 |
| ritz | Mirv, sweet, will check with this | 05:25 |
| ritz | hmm, update was from 2012-09-27 | 05:27 |
| ritz | weird | 05:28 |
| ritz | https://launchpad.net/ubuntu/+source/unity-2d | 05:28 |
| ritz | Mirv I dont this in sru queue or uploaded | 05:29 |
| ritz | where is the source for this ? | 05:29 |
| Mirv | ritz: it's still in the queue so it needs still to be checked by the SRU team in order to get to -proposed. you can test the same package by adding this PPA https://launchpad.net/~unity-team/+archive/sru | 05:59 |
| ritz | sweet, thanks you | 05:59 |
| Mirv | it has higher version number in there but in practice it's the same | 05:59 |
| ritz | Mirv thanks | 06:03 |
| ritz | Mirv will post updates about this issue. fortunately, not very critical . | 06:06 |
| Mirv | ritz: ok, thanks | 06:11 |
| === zniavre__ is now known as zniavre | ||
| sil2100 | didrocks: hi! Still some more failures, this time something got broken on nvidia with keynav tests, I see that it didn't get cleaned up properly after one of the tests :| | 08:53 |
| sil2100 | didrocks: and it broke the quicklist/keynav tests, bleh | 08:53 |
| didrocks | sil2100: no worry, just ping me back once you get something merged, I can relaunch the tests | 08:54 |
| didrocks | with a build :) | 08:54 |
| sil2100 | didrocks: most likely it would just work if you relaunch the tests ;p Since it's something I indeed noticed happened once before, where he couldn't properly clean up quicklists - but it happens rarely | 08:56 |
| sil2100 | Will track it down | 08:56 |
| sil2100 | Since at least we have the preview tests fixed (more or less) now | 08:56 |
| didrocks | sil2100: do you want me to relaunch them right now? | 08:56 |
| sil2100 | didrocks: maybe let me check some things first, maybe it'll be some easy fix | 08:59 |
| sil2100 | I wonder what's wrong with that .quicklist_open property, sometimes it doesn't get updated properly, hm hm | 09:01 |
| didrocks | sil2100: ok | 09:02 |
| jibel | sil2100, didrocks I'd need the intel box until I retraced the compiz crash, could you please wait before launching anything on this machine | 09:04 |
| didrocks | jibel: yep, not touching anything \o/ | 09:04 |
| didrocks | (in a hangout anyway ;)) | 09:04 |
| sil2100 | jibel: ok, no problem then - just give us a sign once it'll be free | 09:04 |
| sil2100 | jibel: no hurry right now | 09:04 |
| jibel | thanks | 09:04 |
| === mmrazik is now known as mmrazik|otp | ||
| luv | smspillaz: thanks | 09:41 |
| jibel | didrocks, that's the best I could get from the crash file: https://launchpadlibrarian.net/130613892/ThreadStacktrace.txt | 09:41 |
| jibel | https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1118178 | 09:42 |
| ubot5 | Launchpad bug 1118178 in compiz (Ubuntu) "compiz crashed with SIGSEGV" [Undecided,New] | 09:42 |
| didrocks | thanks jibel! | 09:49 |
| didrocks | jibel: compiz-core version 1:0.9.9~daily13.02.07-0ubuntu1 required, but 1:0.9.9~daily13.02.04-0ubuntu1 is available | 09:50 |
| didrocks | this is weird | 09:50 |
| didrocks | oh, it's because you use the "with whole ppa version" for the coredump | 09:50 |
| didrocks | not the previous run with the distro version | 09:50 |
| jibel | didrocks, there was no 'Package' record in the crash file and I had to rebuild this info from what is installed on the machine | 09:55 |
| didrocks | interesting, no Package record means something is then broken? | 09:56 |
| didrocks | jibel: I guess as we had unity installed after this run, that's why we had the crash | 09:56 |
| didrocks | I mean, the crash mismatch | 09:56 |
| === mmrazik|otp is now known as mmrazik | ||
| luv | Trevinho: morning, one part about writing the tests I'm not sure about is adding the asserts - when I iterate over GetMenus() ... can I just add a bool to confirm my window is (not) in and then assert the bool is true/false | 09:59 |
| luv | also, yesterday you advised me to use mock_app->windows_ = { win }; ... is that really windows_ or is it window_list_ ? (I dont have ctags running on my server now, so I cant investigate base classes easily.) thanks! | 10:02 |
| didrocks | sil2100: btw, the machine is free now, did you get anything or should I relaunch unity? | 10:57 |
| Trevinho | luv: that's a list | 11:15 |
| Trevinho | luv: so you should add {win} for the test that should verify we don't have extra items | 11:16 |
| Trevinho | luv: while {win1, win2} for the other one | 11:16 |
| Trevinho | luv: if you have something feel free to paste it I can adjust it | 11:16 |
| luv | right, I just wanted to confirm because I will have to work on it tonight and cant get much help on irc then | 11:16 |
| luv | i dont have access to raring now, so now tests yet | 11:16 |
| Trevinho | luv: yeah. sorry... | 11:17 |
| Trevinho | luv: raring is not needed | 11:17 |
| luv | can I do it as one TEST_F ? | 11:17 |
| Trevinho | luv: you can make all in quantal, you only need the staging ppa | 11:17 |
| luv | well i dont have quantal either ;-) | 11:17 |
| Trevinho | luv: yup, follow the other tests | 11:17 |
| luv | there is bunch of things i dont like about quantal+ so i use only latest LTS | 11:18 |
| Trevinho | luv: then just "make test-gtest" and you can run it using tests/test-gtest --gtest_filter=*AnyFilter* | 11:18 |
| Trevinho | luv: ah ok | 11:18 |
| luv | thats why i have a dedicated raring box at home .. | 11:18 |
| luv | thanks a million. and regarding the asserts ? | 11:18 |
| luv | can i just iterate over GetMenus() and set a bool if my dbusmenuitem is (/not) in and then execute assert on the bool? | 11:19 |
| luv | the funny thing is that i could just bring my personal dev laptop with raring to work but i cant because the screen on it broke so i can use it only with an external screen :-) | 11:24 |
| sil2100 | didrocks: I think you can try relaunching, I'm still looking - at least if it gets reproduced we'll know that something changed that makes the bug more reproducible | 11:40 |
| didrocks | sil2100: yep, I launched it 10 minutes ago :) | 11:40 |
| === _salem is now known as salem_ | ||
| === MacSlow is now known as MacSlow|lunch | ||
| didrocks | mmrazik: hey, can you look if libcolumbus has the ci and autolanding setup? | 12:17 |
| mmrazik | didrocks: it has | 12:17 |
| didrocks | sweet, thanks :) | 12:17 |
| didrocks | mmrazik: so, if we install in autopilot-libcolombus with a similar path than the one for autopilot-unity | 12:19 |
| didrocks | mmrazik: then, we just need to add unity.tests.test_search for instance? | 12:19 |
| didrocks | to the list of what is executed during the indicator tests run? | 12:19 |
| mmrazik | didrocks: I don't understand what you talk about :-/ | 12:20 |
| didrocks | mmrazik: libcolumbus has autopilot tests | 12:20 |
| didrocks | if we install them in /usr/share/pyshared/unity/tests/ | 12:21 |
| didrocks | we just need to run autopilot run unity.tests.test_search | 12:21 |
| didrocks | to launch the tests? | 12:21 |
| didrocks | sil2100: I don't find those tests on libcolumbus trunk btw | 12:22 |
| mmrazik | didrocks: libcolumbus has autopilot tests? | 12:22 |
| mmrazik | doesn't make much sense to me | 12:22 |
| didrocks | mmrazik: it does have integration tests | 12:22 |
| didrocks | mmrazik: and yeah, they are launched by autopilot | 12:22 |
| sil2100 | Yes, I created those | 12:23 |
| sil2100 | But didn't merge them into lp:unity yet | 12:23 |
| sil2100 | They're in my branch for now | 12:23 |
| sil2100 | https://code.launchpad.net/~sil2100/unity/autopilot_search_test_suite <- | 12:23 |
| mmrazik | didrocks: okay.. start to understand now. | 12:23 |
| didrocks | sil2100: ok, Satoris told in the email it was already there, hence my surprise :) | 12:23 |
| mmrazik | didrocks: in that case yes, we should be ready for that | 12:23 |
| mmrazik | the same thing we are doing for indicators, etc | 12:23 |
| sil2100 | I didn't want to merge them in until he said it's ok, but I think we can try merging them | 12:23 |
| didrocks | mmrazik: I think everyone will use autopilot for integration tests as we only support that in jenkins jobs | 12:23 |
| didrocks | sil2100: are they installed on make install? | 12:24 |
| sil2100 | The problem I have with this branch is... I made fuzzy searching test for the application lens too, but without libcolumbus there's no fuzzy search support | 12:24 |
| mmrazik | didrocks: well, the issue here is IMHO more that we are putting everything into lp:unity | 12:24 |
| didrocks | mmrazik: it's not | 12:24 |
| didrocks | mmrazik: it will be in lp:libcolumbus | 12:25 |
| mmrazik | there is no inherent reason why we couldn't support non-autopilot | 12:25 |
| mmrazik | you are confusing me guys | 12:25 |
| didrocks | I think they should be intstalled in /usr/share/pyshared/libcolumbus/tests/ I guess | 12:25 |
| mmrazik | didrocks: <sil2100> But didn't merge them into lp:unity yet | 12:25 |
| didrocks | oupsss | 12:25 |
| sil2100 | We need to decide eventually where the test_search tests should be located | 12:25 |
| didrocks | lp:libcolumbus, I meant | 12:25 |
| didrocks | autotyping :) | 12:25 |
| sil2100 | I put them in lp:unity for now, since that's where my emulators were ; | 12:25 |
| didrocks | sil2100: I guess the above path is better ^ | 12:26 |
| didrocks | sil2100: ah no | 12:26 |
| didrocks | please do it in libcolumbus | 12:26 |
| sil2100 | didrocks: ok, I'll move it to libcolumbus then | 12:26 |
| mmrazik | +1 for libcolumbus, btw | 12:26 |
| didrocks | hum | 12:26 |
| didrocks | emulators? | 12:26 |
| sil2100 | I didn't put it in libcolumbus because: | 12:26 |
| didrocks | so you need unity-autopilot to be installed as well? | 12:26 |
| sil2100 | It's testing integration of search functionalities of the HUD and application lens | 12:26 |
| sil2100 | So, theoretically the tests could be executed even for non-libcolumbus needs, just to check if searching in the HUD and the lens works correctly | 12:27 |
| mmrazik | sil2100: and the lenses live in lp:unity? | 12:28 |
| sil2100 | mmrazik: well, we have all the lens autopilot tests in lp:unity | 12:28 |
| sil2100 | Same for HUD tests | 12:28 |
| didrocks | hum, tricky | 12:28 |
| sil2100 | Since both lenses and HUD are essentially part of Unity, and integration tests from autopilot test integration of all components with the shell | 12:28 |
| mmrazik | I see...ideally I would try to move those to the respective trunks. And it indeed makes more sense to have them with lenses than columbus | 12:28 |
| sil2100 | So it's always a tricky thing of where to put the tests ;/ | 12:29 |
| mmrazik | with unity we are also testing Xorg and the autopilot tests are still in lp:unity | 12:29 |
| didrocks | mmrazik: sil2100: what do you think that for now, we move then in lp:unity? | 12:29 |
| mmrazik | yup | 12:29 |
| didrocks | then add the tests the same way in the indicator stack | 12:29 |
| didrocks | like launching those | 12:29 |
| didrocks | to check the HUD and libcolumbus | 12:29 |
| mmrazik | sounds good to me | 12:30 |
| didrocks | good :) | 12:30 |
| sil2100 | didrocks: one problem I have right now that I didn't yet resolve is how to detect if fuzzy searching is available for a given component | 12:30 |
| didrocks | sil2100: don't merge until we add libcolumbus though | 12:30 |
| didrocks | sil2100: we'll land everything in a coherent way at the same time | 12:31 |
| didrocks | so the indicator first tests will fail | 12:31 |
| didrocks | then unity will build with everything (and pass) | 12:31 |
| sil2100 | didrocks: since for instance the current vanilla HUD uses some internal things for fuzzy searching, but the lens don't, so hm | 12:31 |
| didrocks | and we relaunch indicators with whole ppa | 12:31 |
| sil2100 | Ok | 12:31 |
| sil2100 | That makes sense | 12:31 |
| didrocks | and the tests should pass :) | 12:31 |
| sil2100 | So both HUD and application lens will use libcolumbus by default once it's released? | 12:31 |
| didrocks | sil2100: yep, we'll land everything at the same time | 12:32 |
| sil2100 | Excellent | 12:32 |
| didrocks | sil2100: not really fan right now as we're in this test-unknown state | 12:32 |
| didrocks | sil2100: so like, next tuesday? | 12:32 |
| sil2100 | Since I was actually doing hacky stuff now like ldd'ing the lens executables to check if libcolumbus is used, and if not - skipping the tests ;p | 12:32 |
| sil2100 | But it's uh, baad | 12:32 |
| sil2100 | didrocks: ok - you can anyway try running those tests, since they should all pass besides 4 tests (which are fuzzy-search tests for the app lens, which won't pass without libcolumbus) | 12:33 |
| didrocks | sil2100: I don't have the setup ready, let's see first what's the actual results on nvidia if we are back in shape :) | 12:34 |
| didrocks | sil2100: that's more important right now | 12:34 |
| sil2100 | Ok, I'm still debugging unity for the quicklist_open failure test, but it's not reproducible on my system it seems | 12:35 |
| sil2100 | Maybe it happens REALLY rarely | 12:35 |
| didrocks | sil2100: yeah, autopilot have behaved a little bit better this time | 13:07 |
| didrocks | sil2100: but the number of failures is still quite high, mind taking a look? | 13:08 |
| === MacSlow|lunch is now known as MacSlow | ||
| didrocks | retrying once again the indicator ones | 13:09 |
| didrocks | hoping we won't have a crash on intel this time | 13:09 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| didrocks | mterry: hey, how are you? | 14:31 |
| mterry | didrocks, hi! | 14:31 |
| * sil2100 mumbles | 14:32 | |
| didrocks | mterry: so, I guess you did see that I had to relaunch unity because of random failures in tests | 14:32 |
| didrocks | mterry: sil2100 is looking at why it happened, meanwhile, now it passed | 14:32 |
| didrocks | mterry: we still have a weird crash on intel for the indicator tests, happening everytime we launch it | 14:32 |
| didrocks | mterry: jibel is retracing that manually on the machine | 14:33 |
| mterry | didrocks, oh ok | 14:33 |
| didrocks | stealing the ddebs from http://ddebs.ubuntu.com/pool/main/c/compiz/ | 14:33 |
| mterry | didrocks, so why do the ddebs from our PPA end up there? | 14:33 |
| didrocks | mterry: because the mecanism doesn't know what's the origin of a deb | 14:33 |
| didrocks | so it copies everything | 14:33 |
| jibel | yup, please don't reboot the intel box :) | 14:34 |
| didrocks | and only index what's in the archive | 14:34 |
| didrocks | cyphermox: from the MR I saw, we can go with manual publishing for unity, right? | 14:34 |
| mterry | didrocks, but... we didn't publish that compiz yet right? | 14:34 |
| didrocks | like, there is nothing preventing mterry to publish unity? | 14:34 |
| GameDev | Hi, i am making a plugin for Unity, is there a way that Unity pack resources from Jar file, or to generate resources R.java but to not use R.java from Jar... | 14:34 |
| didrocks | mterry: no, but everything with the flag of making ddebs ends up here | 14:34 |
| cyphermox | can I haz more context please? | 14:35 |
| mterry | didrocks, and our PPA has this special flag. Seems wonky that it would end up in the archive... People use those ddebs | 14:35 |
| didrocks | mterry: yep, but it's not indexed | 14:35 |
| didrocks | so apt normally don't see them | 14:35 |
| didrocks | and from what I know, we have a cleanswap cron job | 14:35 |
| didrocks | for old ddebs | 14:36 |
| didrocks | mterry: at least, this is good for us, debugging :) | 14:36 |
| GameDev | yes i forgot to tell, i exporting jar from eclipse... | 14:36 |
| didrocks | mterry: can you share the context to cyphermox, please? I need to jump on a meeting | 14:36 |
| didrocks | mterry: if you publish unity, please please, don't rebuild or launch tests to not disconnect jibel, just publish :) | 14:36 |
| cyphermox | what MR are we talking about | 14:36 |
| mterry | didrocks, yeah. But, for example, I often point to ddebs.ubuntu.com for my own debugging. I just don't like screwing the rest of the Ubuntu peeps for PS landing's sake | 14:37 |
| mterry | didrocks, ACK | 14:37 |
| mterry | cyphermox, you need more context for what? I may have missed didrocks's first question to you | 14:37 |
| cyphermox | <didrocks> cyphermox: from the MR I saw, we can go with manual publishing for unity, right? | 14:38 |
| mterry | cyphermox, Oh I see it | 14:38 |
| cyphermox | trying to figure out what MR that was | 14:38 |
| didrocks | mterry: it's not especially done for us, it's the whole mecanism which is like that :/ | 14:39 |
| mterry | didrocks, but only our PPA has ddeb flag on, eh? | 14:39 |
| didrocks | mterry: nop, the kernel ppa as well | 14:39 |
| mterry | cyphermox, was there perhaps an MR for http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/unity.tests.test_hud/HudBehaviorTests/test_closes_mouse_down_outside/ | 14:40 |
| jibel | didrocks, not very useful http://paste.ubuntu.com/1620939/ | 14:43 |
| cyphermox | ugh | 14:43 |
| cyphermox | so it's probably another thing deep in X then | 14:43 |
| jibel | postmortem analysis is going to be difficult | 14:44 |
| jibel | we'll need to find what make it crash and attach gdb | 14:44 |
| cyphermox | mterry: tbh I don't remember any merge for hud that was related to this particular issue | 14:45 |
| mterry | jibel, that's as far as I was ever able to get | 14:46 |
| mterry | jibel, I wasn't even sure my debugging symbols were being applied or not | 14:47 |
| mterry | (gdb says it saw them, but...) | 14:47 |
| mterry | cyphermox, ah right, that test failure isn't the reason intel stopped, it's because it saw a crash. OK, /me has woken up | 14:50 |
| cyphermox | well, it could be both ;) | 14:50 |
| mterry | cyphermox, well I'm not sure what MR then ;) | 14:50 |
| cyphermox | heh | 14:50 |
| mterry | these compiz crashes are getting frustrating | 14:51 |
| === jono is now known as Guest81910 | ||
| smspillaz | mterry: bug # ? | 15:01 |
| mterry | smspillaz, we can't get a trace to make a bug | 15:01 |
| smspillaz | mterry: you can't ?! O.o | 15:01 |
| smspillaz | surely you can .... | 15:01 |
| mterry | smspillaz, inconsistent crashes, with stacks like http://paste.ubuntu.com/1620939/ | 15:01 |
| smspillaz | that looks nice | 15:02 |
| smspillaz | mterry: my first guess would be ABI mismatch | 15:02 |
| smspillaz | mterry: is it happening on a local machine or a VM somewhere ? | 15:02 |
| mterry | smspillaz, I don't believe that's the case... that would be a more reliable crash right? | 15:03 |
| jibel | didrocks, not sure yet, but it looks like compiz crashes right after boot | 15:03 |
| mterry | smspillaz, this is on jenkins | 15:03 |
| smspillaz | mterry: what hardware is the jenkins job running on ? | 15:03 |
| sil2100 | smspillaz: those crashes happen not every time, so is it possible that an ABI mismatch could cause something like this? | 15:03 |
| jibel | didrocks, compiz crash in syslog happens at 116s and X starts at 156s :/ | 15:03 |
| mterry | smspillaz, this one is intel. But I believe we've also got them on nvidia | 15:04 |
| jibel | smspillaz, Intel 2nd Gen IGC | 15:04 |
| smspillaz | I've seen stuff like this happen on nvidia before, but it would have to be after you've got an opengl context created to know if its the same thing | 15:04 |
| smspillaz | probably looking in the wrong place in any case | 15:05 |
| smspillaz | mterry: jibel: can you run a wrapper script to run it through valgrind to check for any weirdness before it dies ? | 15:05 |
| mterry | smspillaz, that would be tough. We couldn't run our tests that way, and that's how we usually reproduce this. It's not reliable enough to know we're going to hit it in a given day | 15:06 |
| smspillaz | so its random, great | 15:07 |
| mterry | smspillaz, "unreliable" :) | 15:07 |
| smspillaz | oh, I forgot to remove that line | 15:08 |
| smspillaz | if (rand () % 7 == 1) { int *f = NULL; *f = 8; } | 15:08 |
| smspillaz | ;-) | 15:09 |
| smspillaz | but seriously - I find this whole thing quite curious. If compiz were starting up before the x server had, then it would exit (1) | 15:10 |
| mterry | jibel, does syslog give any clue to why it started compiz? | 15:13 |
| mterry | jibel, where did you get the syslog? | 15:14 |
| jibel | mterry, no clue why it started compiz | 15:17 |
| jibel | $ grep compiz /var/log/syslog | 15:17 |
| jibel | Feb 7 13:28:44 ubuntu kernel: [ 116.613293] compiz[5116]: segfault at 9641560 ip 09641560 sp bfc81f9c error 15 | 15:17 |
| mterry | jibel, ah. You're just on the machine. :) Right. I was looking through the artifacts and couldn't see the syslog | 15:18 |
| mterry | jibel, well. If that's before we start the tests... I'm inclined to not worry about that crash at all (wrt autolanding) | 15:19 |
| sil2100 | andyrock: ping! | 15:20 |
| jibel | mterry, indeed, compiz is restarted and autopilot tests seem to run fine | 15:21 |
| andyrock | sil2100, popong | 15:21 |
| sil2100 | andyrock: ;) | 15:21 |
| andyrock | sil2100, what's up? | 15:21 |
| sil2100 | andyrock: did you by any chance encounter before a case where the launcher hide or hover machine had invalid quircks set? Like for instance in the case of QUICKLIST_OPEN quirk | 15:21 |
| mterry | jibel, OK. On that basis, I'll manually publish unity stack | 15:22 |
| andyrock | sil2100, nope because my launcher nevers hides | 15:22 |
| andyrock | but i can try now to reproduce the probleem | 15:23 |
| sil2100 | andyrock: here I have the same, but sometimes it happens on jenkins strangely... | 15:23 |
| sil2100 | andyrock: btw. what is the _hide_machine object for anyway? | 15:24 |
| andyrock | sil2100, well hide_machine contains the logic to show/hide the launcher | 15:25 |
| andyrock | the launcher just needs to connect to hide_machine signals | 15:25 |
| didrocks | mterry: so my question was: can you check with cyphermox that as we tested with the indicator stack, that anything that was merged in the indicator stack since last release didn't break API/ABI? | 15:25 |
| didrocks | or had an impact on the result we had | 15:25 |
| didrocks | like, we can release unity without the indicators | 15:25 |
| andyrock | sil2100, can i have a video of the failure? | 15:25 |
| andyrock | sil2100, i have some ideas ;) | 15:25 |
| sil2100 | andyrock: hm, so why is the state of whether a quicklist is open is kept in the hover/hide_machine objects? | 15:25 |
| andyrock | sil2100, because the launcher should never hide when a quicklist is open? | 15:26 |
| mterry | didrocks, you were thinking in terms of causing the intel compiz crash? | 15:26 |
| didrocks | mterry: no, just on the publication: as you publish some unity components which was tested and built against a newer indicator stack, that we don't have mismatch in publishing just that unity stack | 15:28 |
| didrocks | so cyphermox should knows as he's watching for the indicator merges that we are not in a transition period or so on | 15:28 |
| mterry | didrocks, ah makes sense. But indicators can't break ABI by themselves, right? Like that would involve a change on unity side too | 15:29 |
| didrocks | mterry: well, they can break the ABI in bamf or any library | 15:29 |
| didrocks | mterry: and so you only publish unity relying on the new bamf ABI | 15:29 |
| mterry | didrocks, guh, right. why is bamf in indicator stack? :) | 15:29 |
| didrocks | mterry: because the hud is dep on bamf | 15:30 |
| didrocks | but even without that, you can have indicator protocol change :) | 15:31 |
| didrocks | that landed in both the indicator stack and unity | 15:31 |
| didrocks | and so, the tests are working as both are in the ppa | 15:31 |
| didrocks | hence the xml message telling before a manual publication if an upstream stack failed to check that you can safely publish | 15:31 |
| didrocks | and hence the ping to cyphermox for checking that :) | 15:32 |
| didrocks | cyphermox: ? ^ | 15:32 |
| mterry | didrocks, yeah I understand that protocol changes can happen, but my point was that I'd see them on my side too. But it's true that the indicator stack also has libraries that affect the unity stack | 15:32 |
| mterry | Though most of those would also involve a change on unity's packaging | 15:33 |
| mterry | The one that usually would actually surprise us is a compiz ABI change | 15:33 |
| cyphermox | didrocks: mterry: not that I know of | 15:33 |
| didrocks | mterry: yeah, not some ABI breakage lib | 15:33 |
| cyphermox | but seriously, I hope you don't expect me to be able to just know that off the top of my head, of course I needed to check | 15:34 |
| didrocks | cyphermox: yeah, I think it's safe as well from what I saw, but ensure that both mterry and you are checking that before going on manual publication in the future pleae :) | 15:34 |
| cyphermox | there's a gazillion merge requests coming every day | 15:34 |
| * mterry makes a red button with a glass cover | 15:34 | |
| didrocks | cyphermox: well, some can go unnoticed, but most of case involve packaging changes so you would know :) | 15:34 |
| cyphermox | molly guard? | 15:34 |
| cyphermox | I also fail to understand how a compiz crash would be caused by such a packaging change atm | 15:35 |
| didrocks | cyphermox: sorry, this has nothing related to the current crash discussion | 15:36 |
| cyphermox | then ETOOLITTLECONTEXT again | 15:36 |
| didrocks | cyphermox: this is related to "only publish part of the stack with the upstream stack failing" | 15:36 |
| didrocks | cyphermox: like, as you saw, the indicator stack can't be published because of that crash | 15:37 |
| cyphermox | right | 15:37 |
| didrocks | and mterry wanted to publish manually the unity stack | 15:37 |
| didrocks | which was built against the indicator stack which can't be published | 15:37 |
| cyphermox | but if compiz is crashing here, isn't it really likely to crash just as much on other intel systems, even if we just publish unity>? | 15:37 |
| cyphermox | I mean, any of this stuff, independently or together requires compiz to be rock solid | 15:38 |
| didrocks | mterry: maybe you would be able to explain it better than I? ^ | 15:38 |
| mterry | cyphermox, crashes be crazy | 15:38 |
| cyphermox | if it didn't crash for the unity tests, assuming it's as we've been finding it right now -- random and unreliable, | 15:38 |
| cyphermox | nothing says it's not going to explode just as much once unity is released | 15:38 |
| cyphermox | *published | 15:39 |
| mterry | cyphermox, right, but it's been like that. It's not a new behavior | 15:39 |
| cyphermox | heh | 15:39 |
| cyphermox | that would be the one thing that needs to be corrected with extreme prejudice | 15:39 |
| mterry | didrocks, now that you're back, how do you feel about just renaming testapp to... wm-tester? | 15:49 |
| mterry | I can file the paperwork | 15:49 |
| mterry | But didn't want to be the only one to pick the name | 15:49 |
| smspillaz | mterry: hmm, I didn't know that such a thing existed | 15:50 |
| smspillaz | interesting | 15:50 |
| sil2100 | I actually like the testapp name even | 15:50 |
| mterry | smspillaz, it's new | 15:50 |
| mterry | ish | 15:50 |
| smspillaz | mterry: where is it ? | 15:51 |
| sil2100 | smspillaz: we use testapp extensively in autopilot | 15:51 |
| mterry | smspillaz, https://launchpad.net/testapp | 15:51 |
| mterry | But I filed https://bugs.launchpad.net/testapp/+bug/1089561 a while ago | 15:51 |
| ubot5 | Launchpad bug 1089561 in testapp "testapp is a bad name" [Undecided,New] | 15:51 |
| smspillaz | oh, heh | 15:51 |
| smspillaz | I wrote something a lot like that a while ago | 15:51 |
| sil2100 | mterry: wouldn't it be a bit bothersome to change the name now? | 15:51 |
| smspillaz | libxwmqa | 15:52 |
| mterry | sil2100, it's not packaged yet. So I was trying to change it before we went through that hassle | 15:52 |
| smspillaz | its C++ and uses inheritance in a "clever" way though | 15:52 |
| mterry | sil2100, it's one thing to take the testapp namespace internally in autopilot, but to take it in the ubuntu archive... | 15:52 |
| mterry | smspillaz, xwmqa :) better than testapp | 15:53 |
| sil2100 | mterry: ok, hm, probably wm-tester is not so bad, but wm-tester sound more like a tool to test window managers | 15:53 |
| smspillaz | mterry: lp:sdihgrseuiotyewghedoaighwsofhewhgsdsigbswe!! | 15:53 |
| mterry | sil2100, it sort of is? | 15:53 |
| smspillaz | a legit project!! | 15:53 |
| sil2100 | mterry: well, it doesn't test anything really... | 15:54 |
| smspillaz | sil2100: maybe "mockapp" | 15:54 |
| sil2100 | mterry: it's like, a tool for creating temporary windows | 15:54 |
| mterry | sil2100, it provides fodder to test your wm I guess | 15:54 |
| mterry | sil2100, window-mocker | 15:54 |
| sil2100 | Oh | 15:54 |
| sil2100 | Sounds, hm, nice! | 15:54 |
| mterry | sort of a play on WindowMaker | 15:54 |
| smspillaz | XD | 15:54 |
| mterry | doesn't exist in first page of google | 15:55 |
| tvw | Is there an option to bring the menubar back to the application window? | 15:55 |
| mterry | didrocks, my new favorite name, thanks to smspillaz and sil2100, is window-mocker | 15:55 |
| sil2100 | tvw: currently no, you would have to get rid of unity-panel-service | 15:55 |
| smspillaz | mterry: maybe you can help me think of a better name that "gobject-gmock-generator" | 15:56 |
| mterry | smspillaz, mock-mocker...? :) | 15:57 |
| smspillaz | nah, it doesn't mock mocks | 15:57 |
| mterry | just makes them | 15:57 |
| smspillaz | though maybe it could | 15:57 |
| mterry | make-a-mock | 15:57 |
| * mterry is a bit punchy | 15:58 | |
| smspillaz | mock a mac | 15:58 |
| smspillaz | Mock you | 15:58 |
| mterry | heh | 15:58 |
| didrocks | mterry: sorry, was in yet again a hangout, scrolling back | 16:09 |
| tvw | Thanks, removing the panel-service worked, but it removes more than just the app-menu from the panel :-( | 16:10 |
| didrocks | mterry: I like window-mocker better :) | 16:10 |
| didrocks | mterry: or app-mock ? | 16:10 |
| didrocks | it's a mock application after all? | 16:10 |
| mterry | didrocks, it makes mock windows though | 16:11 |
| didrocks | ok, windows-mock then, I like it :) | 16:11 |
| didrocks | sil2100: if we rename, will the change be easy for you? | 16:11 |
| mterry | sil2100, you said a rename would cause problems? | 16:11 |
| mterry | heh | 16:11 |
| didrocks | \o/ | 16:11 |
| * didrocks hugs mterry | 16:11 | |
| tvw | Another question: Where is the unity-system-tray? | 16:11 |
| sil2100 | It shouldn't be that much of a problem though | 16:13 |
| sil2100 | Regex to the rescue | 16:14 |
| didrocks | mterry: sil2100: ready for the change? | 16:18 |
| didrocks | mterry: thanks for the review on libcolumbus, is the boostrap done btw? | 16:19 |
| didrocks | bootstrap | 16:19 |
| * didrocks always forgets the ""tea"" | 16:19 | |
| sil2100 | didrocks: the name change of testapp? | 16:19 |
| sil2100 | Or for the change to libcolumbus? | 16:19 |
| mterry | didrocks, I believe so. You did the bootstrap for it | 16:19 |
| didrocks | sil2100: testapp | 16:20 |
| didrocks | mterry: waow, ok, I believe you I did :-) | 16:20 |
| sil2100 | didrocks: ready! I'll just prepare a merge for lp:unity for the change then | 16:20 |
| didrocks | mterry: next wednesday, we already have new components that we are going to land and seeing the current situation of daily in indicators… | 16:20 |
| didrocks | sil2100: sweet! | 16:21 |
| didrocks | mterry: you need mmrazik to change the autolanding setup for the testapp to window-mock name | 16:21 |
| didrocks | mterry: and czajkowski for the launchpad project rename | 16:21 |
| mterry | didrocks, I just filed https://answers.launchpad.net/launchpad/+question/221306 | 16:21 |
| didrocks | I'll handle installation the new package in jenkins then | 16:21 |
| sil2100 | didrocks: the branch name also needs to get changed - won't that be a problem? | 16:21 |
| didrocks | mterry: can you ping her with that? it will be shorter :) | 16:22 |
| didrocks | sil2100: no, we're going to change everything with the launchpad rename | 16:22 |
| didrocks | sil2100: and I'm changing the name of the package installed for the indicator tests | 16:22 |
| didrocks | and unity ones | 16:22 |
| mmrazik | mterry: once the launchpad part is done ping me (or fginther depending on the time of the day) and I'll do the jenkins part | 16:22 |
| didrocks | mmrazik: are you going to change the apt-get install in utah-jenkins? | 16:23 |
| didrocks | in addition to autolanding/ci changes? | 16:23 |
| mterry | didrocks, I'll propose a MR for the renaming inside testapp itself | 16:23 |
| didrocks | mterry: thanks, ping me, I'll review | 16:23 |
| mterry | didrocks, sil2100: do we like windowmocker or WindowMocker for the python module name? | 16:24 |
| didrocks | mmrazik: or rather, remove it, unity-autopilot should dep on the testapp/window-mock rather | 16:24 |
| didrocks | window-mocker* | 16:24 |
| didrocks | hum | 16:24 |
| mmrazik | didrocks: I wonder if the apt-get install should not be removed at all and handled via dep | 16:24 |
| mmrazik | didrocks: :) | 16:24 |
| sil2100 | mterry: I would like personally windowmocker | 16:24 |
| mmrazik | too late | 16:24 |
| didrocks | mmrazik: we are in agreement it seems! :-) | 16:24 |
| mterry | sil2100, k | 16:24 |
| mmrazik | didrocks: so once its done just ping me and I'll remove | 16:24 |
| didrocks | mterry: I don't really care, I like CamelCase, but I think sil2100 will touch it more than I :) | 16:24 |
| didrocks | mmrazik: okidoki | 16:24 |
| mterry | jibel, package is renamed | 16:25 |
| mterry | jibel, in launchpad | 16:25 |
| didrocks | sil2100: in you MP, please add a window-mocker dep to unity-autopilot package | 16:25 |
| didrocks | mmrazik: ^ | 16:25 |
| didrocks | mmrazik: so you can remove the apt-get install and change the jobs now | 16:25 |
| sil2100 | Ok | 16:25 |
| mmrazik | didrocks: do I need to change the jobs too? | 16:26 |
| didrocks | https://launchpad.net/window-mocker | 16:26 |
| didrocks | mmrazik: the autolanding and ci I guess | 16:26 |
| mterry | didrocks, we need a team maintainer for that project. I can't rename the strings in the description on LP | 16:26 |
| mmrazik | oh... for the testapp itself? | 16:26 |
| didrocks | mmrazik: right | 16:26 |
| mmrazik | only after the launchpad stuff is done | 16:26 |
| didrocks | hum, thomi is the maintainer | 16:26 |
| mterry | mmrazik, oh whoops, pinged jibel instead of you. LP stuff is done | 16:26 |
| didrocks | mmrazik: it is done | 16:26 |
| didrocks | https://launchpad.net/window-mocker | 16:26 |
| didrocks | mterry: I think it's something to ask to thomi, to set pspmteam as the maintainer | 16:27 |
| didrocks | mterry: please add the boostrap in the MP with the rename as well | 16:27 |
| mmrazik | didrocks: did we only change the launchpad name? I'm just doing some greps and see stuff like "import testapp" | 16:27 |
| mmrazik | I don't need to change any source code, right? | 16:27 |
| didrocks | mmrazik: in the tests, you mean? | 16:28 |
| didrocks | mmrazik: that's what sil2100 is up to right now :) | 16:28 |
| mmrazik | didrocks: yes | 16:28 |
| mmrazik | uh oh | 16:28 |
| mmrazik | starts to be complicated :) | 16:28 |
| didrocks | mmrazik: ahah, indeed, but we are on top of it! :) | 16:28 |
| sil2100 | mmrazik: yes, I'm changing it in lp:unity | 16:28 |
| === dandrader is now known as dandrader|lunch | ||
| sil2100 | mterry: so I should import now windowmocker instead of testapp in Python, right? That's the name? | 16:29 |
| mterry | sil2100, yup | 16:29 |
| mterry | sil2100, if you use the binary name, it will be window-mocker | 16:29 |
| mmrazik | so the utah-jenkins stuff is done | 16:30 |
| mmrazik | going to change jenkins | 16:30 |
| mmrazik | jenkins should be done too | 16:33 |
| mmrazik | sil2100: can you please check the lp:~autopilot/unity/utah jenkins branch? there is a patch in resources but I think its already in | 16:33 |
| mmrazik | lp:unity anyway | 16:33 |
| mmrazik | and its importing testapp | 16:34 |
| mmrazik | if its already in trunk feel free to remove it and push back | 16:34 |
| sil2100 | mmrazik: let me check | 16:36 |
| mmrazik | thanks | 16:37 |
| mterry | lhttps://code.launchpad.net/~mterry/window-mocker/rename/+merge/147165 | 16:42 |
| mterry | https://code.launchpad.net/~mterry/window-mocker/rename/+merge/147165 even | 16:42 |
| sil2100 | https://code.launchpad.net/~sil2100/unity/autopilot_rename_testapp/+merge/147168 | 16:49 |
| davmor2 | mterry: that's no challenge mocking windows | 16:50 |
| mterry | davmor2, :) | 16:51 |
| sil2100 | didrocks: andyrock helped me out and found the possible problem for the quicklist-open breakage we encountered during build 78 \o/ | 17:01 |
| sil2100 | didrocks: he's preparing a fix | 17:01 |
| didrocks | excellent! :-) | 17:01 |
| didrocks | sil2100: https://code.launchpad.net/~sil2100/unity/autopilot_rename_testapp/+merge/147168 small fix needed, the dep! :) | 17:05 |
| sil2100 | didrocks: ah! Sorry! Shit, yes, doing a few things at once is bad | 17:07 |
| didrocks | sil2100: "a few things", so, just do more at once! :p | 17:07 |
| didrocks | ;) | 17:07 |
| sil2100 | ;) | 17:08 |
| sil2100 | didrocks: done! | 17:14 |
| didrocks | sil2100: hum, you did add it to unity-common, right? | 17:14 |
| didrocks | not unity-autopilot? | 17:14 |
| didrocks | which would mean, everyone will gain the new awesome window-mocker | 17:15 |
| sil2100 | Wait wait wait | 17:15 |
| sil2100 | Shit | 17:15 |
| didrocks | I'm sure mterry is really proud of this name, but not that much :p | 17:15 |
| sil2100 | It was supposed to be in -autopilot, it was even in the commit message! I think I'm tired now already ;p | 17:15 |
| didrocks | he already has deja-dup by default, one name, that's enough! ;) | 17:15 |
| didrocks | heh | 17:15 |
| mterry | didrocks, :) | 17:16 |
| didrocks | (also, see the degredation, he started with french names, and now, back to english) | 17:16 |
| sil2100 | ;) | 17:16 |
| sil2100 | Anyway, I hope it's good now | 17:16 |
| mterry | didrocks, you could have chimed in with deja-mocker | 17:16 |
| sil2100 | Damn, I should double check things today | 17:16 |
| didrocks | mterry: yeah, let's rename \o/ | 17:17 |
| didrocks | :) | 17:17 |
| didrocks | sil2100: TBH, it's unlucky that the general diff just doesn't show up the package name, I had to look at trunk to look for the line because the description looked suspicious :) | 17:17 |
| sil2100 | hehe | 17:18 |
| didrocks | sil2100: approved! | 17:18 |
| sil2100 | Thanks! | 17:18 |
| didrocks | thank *you* | 17:21 |
| * mterry has to be careful to not type window-maker instead of window-mocker | 17:22 | |
| * sil2100 had to correct himself since he was writing window-mock all the time | 17:22 | |
| sil2100 | The er was missing | 17:22 |
| mterry | didrocks, doesn't mocker sound a bit German? Like macher? See, I'm still near France | 17:24 |
| andyrock | sil2100, i just got a failure using this test http://paste.ubuntu.com/1621517/ | 17:24 |
| didrocks | mterry: you wanted to please seb128 over me it seems… :p | 17:24 |
| sil2100 | andyrock: excellent! I mean, ugh, excellent that it's reproducible in a specific environment ;) | 17:24 |
| andyrock | sil2100, and you know what i cannot reproduce it all the time | 17:25 |
| sil2100 | didrocks, mterry: ... ;P | 17:25 |
| andyrock | i think i need to use new placement to do it | 17:25 |
| sil2100 | andyrock: so even here it's not 100% reproducible? | 17:25 |
| andyrock | yeah becaue there is not guarantee that if you do: | 17:26 |
| andyrock | auto a = new int; | 17:26 |
| andyrock | auto t = a; | 17:26 |
| andyrock | delete a; | 17:26 |
| andyrock | auto b = new int; | 17:26 |
| andyrock | b == t | 17:27 |
| sil2100 | Right | 17:27 |
| andyrock | it can happens but there is not guarantee (but we can force it ;) | 17:27 |
| andyrock | *happen | 17:27 |
| didrocks | andyrock: interesting, dart is able to have unique references for those kinds of matching object | 17:27 |
| andyrock | didrocks, never used dart ;) | 17:29 |
| === dandrader|lunch is now known as dandrader | ||
| didrocks | it's awesome, loving it, even if they are breaking the language still regularly :-) | 17:29 |
| didrocks | fginther: hey, around by any chance? | 17:42 |
| xylon | Hey guys | 17:43 |
| didrocks | mterry: I'm wondering if https://code.launchpad.net/~mterry/window-mocker/rename/+merge/147165 is merging, it should already be done as it's small to merge | 17:43 |
| didrocks | mterry: can you check with fginther once he's back? | 17:44 |
| didrocks | mterry: we can add the new component right now to the stack meanwhile | 17:44 |
| xylon | I'm wondering how one would go about creating a panel with the ayatana indicators in it | 17:44 |
| xylon | Are there some docs? | 17:45 |
| didrocks | xylon: hey, do you want to implement a renderer or an indicator itself? | 17:46 |
| xylon | I want to do something similar to what Wingpanel in Elementary OS | 17:47 |
| xylon | oops typo | 17:47 |
| didrocks | xylon: there is no doc for that, but looking at unity-panel-service code, or any other that implemented something compatible like the kde panel may be of help | 17:48 |
| xylon | Is that part of the unity code or is there a separate launchpad page for that? | 17:50 |
| xylon | Never mind, I think I found it in "services" :D | 17:51 |
| didrocks | xylon: yep, a subdirectory :) | 17:51 |
| xylon | Thanks for the help | 17:52 |
| andyrock | sil2100, http://pastebin.ubuntu.com/1621627/ 100% now ;) | 17:54 |
| andyrock | we can fix it now ;) | 17:54 |
| sil2100 | andyrock: awesome! | 17:59 |
| sil2100 | :) | 17:59 |
| sil2100 | andyrock: waiting for the merge request then - I'll test it as soon as possible | 18:00 |
| sil2100 | But for now, I go make dinner | 18:00 |
| sil2100 | See you later and thanks! | 18:00 |
| didrocks | fginther: hey, back? | 18:21 |
| didrocks | fginther: mterry: ok, I really need to go, so I've merged manually https://code.launchpad.net/~mterry/window-mocker/rename/+merge/147165 to not have everything exploding tomorrow | 18:25 |
| mterry | didrocks, tsk :) | 18:25 |
| didrocks | fginther: can you please check with the job is not working? | 18:26 |
| mterry | didrocks, OK see ya tomorrow! | 18:26 |
| didrocks | mterry: I'm deploying window-mocker now FYI | 18:26 |
| didrocks | in the misc task | 18:26 |
| mterry | didrocks, OK, cool | 18:26 |
| didrocks | mterry: can you check that https://code.launchpad.net/~sil2100/unity/autopilot_rename_testapp/+merge/147168 is merging? (there is still time for that one) | 18:26 |
| mterry | didrocks, sure | 18:26 |
| didrocks | mterry: if not in let's say, 5 hours (so once you are leaving), please do the same ;) | 18:27 |
| fginther | didrocks, looking | 18:27 |
| didrocks | mterry: https://code.launchpad.net/~ps-jenkins/compiz/latestsnapshot/+merge/147146 also, I'm keeping that one somewhere | 18:27 |
| didrocks | fginther: shouldn't that one be fastracked? ^ | 18:27 |
| didrocks | fginther: it seems the fastrack didn't work for all latestsnapshot | 18:27 |
| fginther | didrocks, jenkins has not been behaving well lately and has been unreliable at triggering new jobs. | 18:29 |
| didrocks | fginther: waow, do we know why? jenkins on the daily release is working really well, even for new jobs | 18:29 |
| fginther | didrocks, the autolanding server just looks to be overwhelmed with jobs and is not keeping up, we're working on a solution to improve efficiently by reducing locking which should help. | 18:31 |
| didrocks | fginther: ok great, does this has something to do with latestsnapshot and fast track? | 18:31 |
| fginther | didrocks, new or updated jobs sometimes don't get triggered :-( | 18:31 |
| didrocks | urgh, sucks :/ | 18:32 |
| fginther | yep | 18:32 |
| didrocks | fginther: so please, check as well the unity/compiz ones I told above ^ | 18:32 |
| fginther | will watch them, sorry for the inconvenience | 18:32 |
| didrocks | fginther: we need in particular the unity ones before 04 UTC to not break everything :) | 18:32 |
| didrocks | fginther: no worry, thanks! | 18:33 |
| didrocks | mterry: FYI, I deployed the new misc stack | 18:33 |
| mterry | didrocks, thanks | 18:35 |
| didrocks | yw! | 18:35 |
| * didrocks waves good evening | 18:35 | |
| luv | trying to write the tests here but ... mock_app has no member windows_ ... only MockLauncherIcon does but mock_icon in test_application_launcher_icon.cpp is not MockLauncherIcon but launcher::ApplicationLauncherIcon(mock_app); | 20:14 |
| luv | also, calling GetMenus() on mock_icon says GetMenus() is protected and wont compile either | 20:15 |
| luv | i kinda think you guys would be better off writing the tests yourselves - would have been done two days ago and took you less time than explaining me what to do anyway | 20:16 |
| luv | and chaning mock_icon to MockLauncherIcon in test_application_launcher_icon.cpp is not indeed easy because it's used throughout ... well I can create an extra mock_icon for my test but i have _no_ idea how your tests work so it's just shotgun programming .... and not even that | 20:18 |
| luv | haha, actually windows_ is not defined even in MockLauncherIcon it is defined only in MockMockLauncherIcon in test_switcher_view.cpp | 20:21 |
| === larsu_ is now known as larsu | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!