=== andyrock is now known as andyrock|zzz === jalcine- is now known as Jacky === Jacky is now known as Guest58047 === Guest58047 is now known as Jacky [03:56] bschaefer: pong from earlier... although it's a holiday for me :) [03:56] yeah I looked it up :) [03:57] thomi, no worries, I just got done with class. [03:57] I can talk to you tomorrow if you want a day off ;) [03:57] it's cool - I'm about to start hacking on some personal projects [03:57] cool! [03:58] So, Ctrl+Space isn't activating ibus in the VM huh? [03:58] that's odd [03:58] Im excited to start one up soon [03:58] yeah [03:58] if you look at the error messge [03:58] * bschaefer goes to get it... [03:58] bschaefer: heh, if you're looking for something to do I can suggest several projects for you :P [03:59] bschaefer: I wonder if we can get a test system that's closer to the one that jenkins runs on - maybe we can reproduce some of these intermittently failing tests as well. [03:59] thomi, well I might be writing a compiler this summer, or using nux to make a maze solver/generator [03:59] ahh, cool [03:59] thomi, AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1) [03:59] so [03:59] fails on this line AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1) [03:59] opps [03:59] didn't copy haha [04:00] self.assertThat(widget.im_active, Eventually(Equals(True))) [04:00] yeah, so either ibus isn't being activated, or we're not getting the signal [04:00] yeah [04:00] I wonder if there's anything we can do to narrow down the cause? [04:00] I was thinking maybe a key is getting held down but I couldn't find a key that you could hold downt o cause that [04:00] yeah I was wondering that too [04:00] you should be able to see the timings in the test log [04:01] so it fails on waiting for ibus to be true [04:01] it logs a line every time it presses and releases a key [04:01] hmm [04:01] maybe the delay is too long or something? [04:01] well I wanted to add some debuging messages in but I guess you need to merge it to trunk for that [04:01] thomi, but it works locally [04:01] well [04:01] let me try a super long wait [04:01] good idea [04:02] ooo thomi hold down ctrl+space [04:02] just hold it down and look at the indicator [04:02] I don't get an indicator... hang on [04:03] hmm well it toggles on/off [04:03] and I got a random crash doing that... [04:03] yeah, I see [04:03] very odd that it doesn't fail on the local build though [04:04] I tried it in my VM today also [04:04] can you do some subtraction from the trimestamps in the test log and see if the timings are unreasonable? [04:04] lowering the ram to like 300 mb [04:04] well it hold it for 0.2 [04:04] which I think is like 200 ms? [04:04] yeah [04:05] that seems fast to me [04:05] that doesn't seem unreasonable to me [04:05] yeah [04:05] I wonder [04:05] heh, I was going to say it's on the slow side :) [04:05] if the VM is just slow [04:05] though [04:05] that's 1/5 of a second. [04:05] yeah haha, but I/O is always slow haha [04:06] hmm [04:06] Ill see what happen is I just set it to 0.0 [04:06] or maybe 0.05 haha [04:07] thomi, we should have a dx-autopilot-test-jenkins [04:07] not being able to debug the VM is not very nice [04:08] bschaefer: if you want to set it up I'm sure we can make it happen [04:08] ... or even set it up on our own jenkins instance. [04:08] thomi, Ill have to look into that but that would be awesome [04:08] I also need to show you how I set up a VM for unity 3d [04:08] thomi, also do you know when the last time the VM was reset? [04:09] I have a jenkins instance for my own projects. I'll talk to people and see how hard it'll be to get running on the PA jenkins machine [04:09] like just rebooted [04:09] it gets reset each run [04:09] the dx-autopilot-build-nfsroot job reboots the machine and boots it with a clean image [04:09] ...but that's not the case if we just trigger the dx-autopilot-run job directly [04:10] hmm good [04:10] I just want to eliminate as many possible problems as possible [04:11] thomi, hmm it seems to work at 0.05 [04:11] ill push it 0.0 [04:12] ...assuming the issue is that it's too slow. Worth a shot though [04:13] yeah [04:13] and 0.0 works fine locally [04:13] thomi, there are also some debugging messages in nux I could uncomment.... [04:13] but I don't want to push just debugging messages to nux trunk [04:14] bschaefer: hmmmm. It'd be nice if there was a copy of the jenkins job we could customise... [04:14] yeah I know...all I want is to be able to reproduce this problem [04:14] ALL of the test are failing [04:14] but I cant get 1 to produce anything jenkins says... [04:14] and it is very constant [04:15] hmmm [04:15] im just trying to think of anything that could cause that [04:15] if you were feeling brave you could recreate the jenkins config on your local machine [04:15] sure, I can set up a VM haha [04:15] I actually have a VM I can toast [04:15] do you have access to the private jenkins instance? [04:15] no :( [04:16] I could walk you through how to setup a VM sometime soon [04:16] though I use windows for my VM [04:16] OK, I can grab the job details and paste them somewhere for you [04:16] ok cool [04:23] thomi, ugg my schools internet is crap [04:23] :( [04:24] just randomly kicked off, anyway did I miss anything? [04:24] nope [04:24] cool [04:24] I made fun of you, but that was it [04:24] Im happy I missed that then [04:25] hmm should I push these ibus test with the time press set to 0.0? [04:25] im also wondering if I could use nux to time the inbetween im_active gets active [04:25] and deactive [04:26] but that might not even be the problem :(, you would think it would work at lease once if it was a timing issue [04:27] bschaefer: I think ideally we'd be able to reproduce the issue before pushing random changes to trunk. [04:27] bschaefer: maybe push 0.1 or 0.05 instead? seems like a more sensible change [04:28] thomi, and guess what I did :) [04:28] I set the time to 1.0 [04:28] and it seem to mimic those that problem [04:28] oooh, that's interesting [04:28] let me run the Ignore test to see if that works [04:29] self.assertThat(widget.im_active, Eventually(Equals(True))) [04:29] AssertionError: After 10 seconds test on SearchBar.im_active failed: True != dbus.Boolean(False, variant_level=1) [04:29] :) [04:29] both failed [04:30] cool! [04:30] ok [04:30] would be interesting to see where the cutoff point is [04:30] so, why does 0.2 work for us but not jenkins? [04:30] yeah [04:30] Ill start going closer to 0.2 [04:30] bschaefer: probably because the jenkins instance is slow, so it's closer to 0.4 or somthing [04:32] thomi, ooo you were sooo close [04:32] it is 0.5 [04:32] that is start failing fo re [04:32] for me* [04:32] could be 0.4 on a different machine [04:33] thomi, but to be honest that seems like a bug in nux to me [04:33] I don't think it should toggle like that... [04:33] bschaefer: probably to do with the tap detection code [04:33] yeah, or lack of [04:33] im not sure if there is one [04:33] better not say that too loud, the compiz guys will ragequit [04:33] haha [04:33] bschaefer: ok, so maybe push a branch that sets it to 0.05 or so [04:34] alright, hopefully that helps! [04:34] ping me when you have a MP to review [04:34] ok [04:40] thomi, https://code.launchpad.net/~brandontschaefer/unity/ap-ibus-shorten-timer/+merge/103407 [04:41] also what were some other side projects were you doing? [04:41] bschaefer: approved [04:41] bschaefer: right now I'm working on http://launchpad.net/sloecodfe [04:41] cool, this should fix 32 failures!! [04:41] *sloecode [04:42] thomi, that looks awesome [04:42] I actually need to learn something about networking [04:43] bschaefer: we have a todo list that's insanely long :) [04:43] so uhh... "patches welcome" :) [04:43] thomi, I might take a look :) [04:43] we hang out in #sloecode [04:43] I also might have to wait until I graduate [04:44] I do to many things atm haha, being a TA/Tutor takes a lot of time along with classes and working here [04:45] yeha [04:45] *yeah [04:46] Ill stop by that irc room when I get a chance [04:47] it is getting a bit late here and I should go eat [04:47] thomi, do you know when the next jenkins test should run? [04:47] I suck at waiting.. [04:47] bschaefer: nope, shouldn't be too long though [04:48] if you're running indicator-jenkins you can get a helpful popup :) [04:48] cool, Ill check after dinner [04:48] oo [04:48] i should install that [04:49] well im off to relocate back home, have fun programming :) === Jacky is now known as [Jacky] === [Jacky] is now known as Jacky [07:12] didrocks: ping-y [07:20] tsdgeos: hey hey [07:21] didrocks: was wondering, might it be that the merger thingy gets confused when a branch name is a subset of another? [07:21] yesterday we merged https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons_2 [07:21] and https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons was incorrectly set to merged, Gerry had to put it back to needs review [07:21] tsdgeos: it's not the merger it's launchpad AFAIK [07:22] ah [07:22] if it sees commits that are in trunk, it triggered the status to "merged" [07:24] ok :-/ === Guest15469 is now known as Jens === Jens is now known as Guest28666 === Guest28666 is now known as _jens === _jens is now known as jbache === jalcine- is now known as Jacky === andyrock|zzz is now known as andyrock [09:07] hi, I am reading a bug report where a user's application and music daemons are not running [09:07] how do I ask him to start them? [09:07] so basically unity-applications-daemon and unity-music-daemon not running as background processes [09:17] mhr3, hey [09:17] davidcalle, hey, awesome you here, wanted to ask you something :) [09:18] mhr3, ok, you first :) [09:18] davidcalle, https://bugs.launchpad.net/bugs/953871 [09:18] Ubuntu bug 953871 in unity (Ubuntu) "[regression] Unity dash quicklist shows Utilities scope" [Low,New] [09:18] is the lens doing something it shouldn't? [09:18] or is that us? [09:18] or perhaps it's not doing something it should ;) [09:20] mhr3, should be invisible... I don't remember, is there an entry in the .lens for this? Because it's not set, so that may be the issue here. [09:20] davidcalle, yea, it should have Visible=false [09:21] mhr3, ok, fixed. People will have it in a few hours. [09:21] ultimately we should be clever there, but we ain't so lenses need to provide this info :) [09:22] mhr3, I feel like it's the third time I'm fixing this o_o Must be forgetting to push it each time. [09:22] heh :) [09:22] mhr3, is it possible to reload only one filter, without changing the state of the others? [09:23] it *should* [09:23] last time i was talking about it with ken, he said that unity doesn't react to the changes [09:23] mhr3, I see. [09:23] and i don't remember anyone fixing it on unity side [09:24] davidcalle, try removing the filter and then re-add it [09:24] mhr3, ok. [09:24] although that will change the order i guess :/ [09:26] davidcalle, still, i think it should be possible to even remove all the filters and re-add them (if you keep the original references the state wouldn't change iirc) [09:27] mhr3, yeah, that's what I was going to do. [09:43] mhr, can you please look at https://bugs.launchpad.net/bugs/987689 [09:43] Ubuntu bug 987689 in unity "dash: application tab disappeared" [Undecided,Incomplete] [09:43] its regarding the application and music lens daemon not running [09:45] nik90, if the icons are missing, the lens have probably been uninstalled for some reason. Do you have unity-lens-music installed? [09:45] davidcalle, apparently the user states that both are installed but the daemons are not running for some reason [09:46] davidcalle: he checked the existence of the package using apt-cache policy unity-lens-application [09:48] mhr3, what do you think ? ^ [09:49] maybe I should ask him to just try unity --reset and see if it solves his problem?? [09:50] starting the lens daemons manually will probably spit some error [09:51] would be nice to know what kind of [09:51] nik90, ^^ [09:52] mhr, how do you start the daemon manuall? [09:52] manually* [09:54] /usr/lib/unity-lens-applications/unity-applications-daemon [09:54] /usr/lib/unity-lens-music/unity-music-daemon [09:55] mhr, davidcalle..nice synchronisation :) [09:55] I'll inform the user [09:55] thnx === MacSlow is now known as MacSlow|lunch === greyback is now known as greyback|lunch === greyback|lunch is now known as greyback === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === salem_ is now known as _salem [13:55] more Hello Unity updates: http://mhall119.com/2012/04/hello-unity-episode-3-4/ [14:10] * mfisch just gave a presentation on Singlet [14:10] it was well received [14:10] mfisch: awesome@ [14:10] ! [14:10] mhall119: they wanted to know if singlet was here for the long haul, and I said yes, but of course have no proof [14:11] mhall119: the best part is that I presented it as "Singlet" and "The Old Way" [14:13] mfisch: it's here at least as long as I am, which I certainly hope is long haul :) [14:13] "The Old Way" isn't quite accurate [14:14] mhall119: true [14:14] mhall119: the "traditional way" [14:15] it's also the only way for non-Python lenses and scopes, or anything more complex [14:44] mhr3, hey, do you know if bug #915203 is a lens side issue? a design decision? [14:44] Launchpad bug 915203 in unity-lens-music (Ubuntu) "Unity 5.0: Not all music shows up in Music lens" [Undecided,Confirmed] https://launchpad.net/bugs/915203 [14:44] mhr3, i.e having limited number of songs and albums listed [14:45] seb128, i'm sure would like to put 20 thousand items in the lens, people who implemented the lens didn't [14:45] ..design would like... [14:46] mhr3, ok, so unity-lens-music is the right component? i.e it's coming from the backend side? [14:46] yes, its implemented to list only up to 100 items [14:47] mhr3, thanks === _salem is now known as salem_ === yofel_ is now known as yofel [15:15] any lightdm devs around? [15:15] how does lightdm find out what wallpaper the user is using? [15:17] hyperair: it asks accountsservice IIRC [15:17] mdeslaur: i see. is it possible to get lightdm to pull the entire wallpaper image through this as well? [15:18] mdeslaur: if you use a custom wallpaper in your $HOME (i don't see where else you would put it) and chmod o-r $HOME, lightdm refuses to log in. [15:18] not getting the wallpaper is one thing, but not being able to log in is ridiculous [15:18] https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/987614 [15:18] Ubuntu bug 987614 in lightdm (Ubuntu) "Stuck at login screen with status "Logging in..."" [Undecided,New] [15:18] we have this bug here [15:18] hyperair: well, that's a bug. It should be able to obtain the wallpaper so it doesn't bypass permissions, but shouldn't fail either [15:18] s/should/shouldn't/ [15:19] it looks like background.vala:138 loads it directly in the unity greeter process [15:19] hyperair: I'm not a lightdm developer, can't help you any further [15:20] ah, okay thanks anyway === salem_ is now known as _salem [15:51] mhall119: do you have a simple example of something too complex for singlet? [15:58] mfisch: the video lens would be one [15:58] mhall119: whats the reason? [16:02] mhall119: trying to think of an example to tell people and explain why [16:04] mfisch: mostly just because Singlet only covers simple cases [16:04] you can do more complex stuff using Singlet, but you don't get any real benefit from using Singlet at that point [16:05] it's like Quickly, good for small fast development, but once you reach a certain size it doesn't do you much good anymore [16:21] got it === elopio_ is now known as elopio === _salem is now known as salem_ === Guest85884 is now known as Jacky === Jacky is now known as Guest70035 === Guest70035 is now known as Jacky === Jacky is now known as Guest53736 === Guest53736 is now known as Jacky [18:19] lamalex, hey, so thomi and I might have figured out why the ibus test don't work [18:20] nice! [18:20] I pushed some changes last night, but it didn't seem to fix it [18:20] it seems when you hold ctrl+space down, ibus toggles on/off [18:20] ok [18:21] are we turning it off? [18:21] I think it is how fast we detect tabing [18:21] for the hud [18:21] so events come through faster, so holding it down [18:21] will push that event through nux multiple times [18:23] I have a different solution but Im not sure how much I like it :( [18:24] lamalex, o yeah to reproduce the problem on a local machine. Go into test_ibus.py and under def activate_ibus change the press/release time to 0.5 [18:25] so it's purely timing issue? [18:26] yarrr [18:26] that is what it looks like... [18:26] but that is the only way I can reproduce it on a local machine... [18:27] I changed the time to 0.05 last night, but it still fails so I think a fix is to iterate from 0.2 to 0.9 and try and press/release ctrl+space [18:28] if it activates its the go, else it will drop out and fail on an assert [18:28] bschaefer, after doing that- now it fails without setting the time for me [18:28] hmm really? [18:29] what test are you running? [18:29] autopilot.tests.test_ibus.IBusTestsPinyin.test_simple_input_dash [18:29] ok, ill see if I can get the same [18:33] lamalex, hmm mine works after setting it back to default [18:33] odd [18:33] yeah... [18:34] I have a branch that should find the correct time for presssing ctrl+space... [18:34] which should find a correct time, if the timing is the issue [18:37] odd that this is the only place where key press timing is an issue [18:37] so you think you understand the root cause of this? [18:37] I think it has to do with ctrl+space getting pushing into ibus multiple times in nux [18:38] yeah, the problem is Ctrl+Space can change to anything... [18:39] also gnome seems to toggle it [18:39] but just not as much [18:40] well not on pinyin...it really is up to ibus engine then [18:42] lamalex, this is one possible fix...https://code.launchpad.net/~brandontschaefer/unity/ibus-ap-test-range-time/+merge/103544 [19:09] bschaefer, this is such a hack :\ [19:10] lamalex, I know....Ill spend today looking into fixing this in nux [19:58] thomi, review my branch when you're back! https://code.launchpad.net/~alexlauni/unity/unity.ap-switcher-emu/+merge/103338 [19:59] hey , wondering if unity is supposed to show the launcher bar and the top bar on all of my screens (3 of them) [20:00] and also if the mouse is supposed to get stuck when moving from one to the next (which I find rather annoying) [20:00] gema, yes and yes, and both can be changed in the system settings [20:00] seb128: you are a lifesaver [20:01] gema, well the top bar can't, but the display configuration dialog has a combo to select if the launcher should on one screen, which one in that case, or on all screens [20:01] gema, it has a config to turn off the stickyness between screens as well (which is there so you can easily get to a scrollbar against the border) [20:02] seb128: already much more usable for me [20:02] seb128: thanks [20:06] gema, yw! [20:10] thomi, ping [20:13] bschaefer: pong [20:13] lamalex: ok [20:13] hey [20:14] soo that fix didn't work :I( [20:14] :( [20:14] wah [20:15] thomi, ill see if this is a possible fix in nux. The problem is there are multiple keys to activate/deactivate ibus and you can add/subtract from that list [20:15] bschaefer: I saw - odd huh? [20:15] yeaah [20:15] lamalex: is there any way to run an identical environment to the one the jenkins instance uses locally? [20:15] so it must have a min slow time, ie it is always 0.5 or higher [20:15] if it is a timing issue [20:16] thomi, hey [20:16] thomi, i mean it should be possible to run the nfsbuild root script stuff locally [20:16] but im not sure how you'd boot the overlayfs image. you'd need a second machine to pxe boot [20:16] lamalex: hmmm [20:16] thomi, lamalex, bschaefer: is there any chance one of you help writing a test for https://code.launchpad.net/~mvo/unity/usc-launcher-fix-982921/+merge/102257 [20:16] i guess really you need a jenkins master and slave set up in your apt [20:17] VirtualBox has pxe [20:17] it will not make into the first SRU otherwise [20:17] i.e mvo is maintaining software-center but is not familiar with the unity test framework and he's busy with the precise release (he's looking at i.e upgrade bugs as well) [20:18] lamalex: ok, another idea - do you think we could duplicate the autopilot-run job into another jenkins job that we fire off manualkly? We could point it at a custom unity branch, so we can try things out and run the tests in an identical environment without having to merge with trunk. [20:18] thomi, yah for sure [20:18] just make a new job and copy from dx-autopilot run and change the branch ha [20:18] lamalex: we can just go ahead and do that, or do we need to ask someone? [20:18] thomi, on it [20:18] lamalex: thanks! [20:19] bschaefer: now we can try some wacky fixes and not have to merge with trunk :) [20:19] sweet! [20:19] seb128: looking into it... [20:19] thomi, thanks ;-) [20:19] I have a bad hack to check if it is a timing issue [20:20] thomi, https://code.launchpad.net/~brandontschaefer/unity/ibus-ap-test-range-time/+merge/103544 [20:20] we should be able to use that to check if/what is the timing problem [20:21] bschaefer: you want to at least sleep before that if statement. It will take a while for unity to update [20:21] you could use wait_for, but then you'd be sleeping 10 seconds each time it didn't work [20:21] also, the more I think about this, the less I think it's a timing issue [20:21] hmm yeah, [20:21] The times seem similar to what works for me locally [20:21] and we're seeing 100% failure rate [20:22] so I suspect it's something a bit more basic. [20:22] yeah [20:22] bschaefer: a vlue might be to look at what changed when they all started failing? [20:22] im hoping... [20:22] Ill look through the logs [20:23] thomi, where do we want this branch [20:23] lp:~unity-team/unity/ibus-tests [20:23] sound good? [20:23] yup [20:23] lamalex: we can always tweak the jenkins job config to point it elsewhere, right? [20:23] yah [20:24] also going to change the ap run command to just run ibus tests [20:24] save time [20:24] lamalex, awesome, thanks! [20:24] (will do a test run to make sure we're still seeing same fails this way) [20:25] thomi, man, im looking at these test and it has been failing to activate ibus for a while... [20:25] bschaefer: yeah [20:28] ok should be set to build on every commit [20:35] thomi, the first build to not activate ibus correctly [20:35] though that is for pinyin only [20:35] https://jenkins.qa.ubuntu.com/job/dx-autopilot-run/695/#showFailuresLink [20:36] bschaefer: ok, so what changed in that build? can you see the bzr revno? [20:36] look in the console output for the default configuration [20:36] yeah, I started looking for where they ALL started failing [20:36] goes to do that [20:37] thomi Now on revision 2206. [20:37] * bschaefer goes to look at that rev [20:37] uh oh - dx-autopilot-run build just failed. [20:37] i might have cancelled it [20:38] i forgot to change the downstream job to the ibus job [20:38] s/might have// [20:39] thomi, http://bazaar.launchpad.net/~unity-team/unity/trunk/changes/2206 [20:40] im just going to dig until if find anything useful haha [20:44] thomi, ugg so a problem, a problem happen between rev 2120 - 2206...since the jenkins test fail for a while [20:44] unity rev 2120-2206 [20:45] hmmmm [20:45] bschaefer: it could also be a change in the autopilot infrastructure branch that caused it [20:45] Ill see if I can find where ALL start failing as that doesn't help at all [20:45] ...or a change oin nux. [20:45] yeah [20:48] lamalex: I take it you didn't want to go the extra step and use the Eventually() matcher in your switcher refactor branch? [20:48] I guess it makes sense to do that in a separate branch [20:49] thomi, where? i thought i did [20:49] oh, ok, there are some, I didn't get to them yet [20:49] I'll add a note in my review [20:49] there are some places where I couldn't use it- for instance the mode property isn't from introspection [20:50] i added a card to extend wait_for so that you can use it on properties not added by introspection [20:51] thomi, wow even more odd things. What happen to jenkins dx ap builds 723-763? [20:51]