| RAOF | I'll fire up the ati system again. | 00:00 |
|---|---|---|
| bschaefer | RAOF, thanks, kgunn just wanted another working xmir data point, so for 1 is failing and 2 are working | 00:01 |
| bschaefer | s/for/far ... geez | 00:02 |
| RAOF | Heh | 00:05 |
| * robert_ancell -> lunch | 00:08 | |
| kdub | my 1tb harddrive is 80% full of compiled mir code... bzr -_- | 00:23 |
| kgunn | RAOF: can you please ping didrocks when he comes online & try to help resolve his ati issue...its our last blocker | 00:24 |
| RAOF | kgunn: Sure. | 00:24 |
| RAOF | kdub: cd ~/.bazaar/plugins; bzr branch lp:bzr-removable ; cd ~/Devel/Mir ; for I in $(bzr removable trunk ) ; do rm -r $I ; done ☺ | 00:25 |
| kdub | RAOF, hmm, might give it a try! | 00:26 |
| RAOF | kdub: bzr-removable adds the "removable" command; in a repository, you give it a branch and it'll tell you all the branches in the repository which have been merged into that branch. | 00:27 |
| kdub | ah, that would be useful | 00:27 |
| RAOF | It also adds the "unremovable" command, which does the reverse, and tells you why it's not removable | 00:28 |
| * RAOF might get around to adding a "-d" option to it, so that ‘bzr removable -d trunk’ would delete all the branches that have been merged into trunk | 00:29 | |
| * RAOF books travel to Boston | 00:30 | |
| RAOF | bschaefer: Yup; My ati box still works with unity-system-compositor | 00:31 |
| bschaefer | RAOF, thanks | 00:32 |
| RAOF | Now; does this XMir populate xrandr data? | 00:38 |
| bschaefer | RAOF, where would one check for this data? | 00:42 |
| bschaefer | i see this in my syslog: Aug 7 16:30:51 bschaefer-GA-870A-UD3 colord: Device added: xrandr-XMIR-1 | 00:42 |
| RAOF | bschaefer: Oh, your XMir definitely doesn't. I'm just hooking up the new Mir multi-head API. | 00:45 |
| bschaefer | oo cool, though im not sure what that is :) | 00:45 |
| RAOF | xrandr will report the full set of modes your outputs can do, rather than just the single mode Mir set on startup :) | 00:48 |
| bschaefer | RAOF, oo nice, yeah, i've just been stealing mir_connection_get_display_info ... and using the width/height for what I think mir can display | 00:49 |
| RAOF | Yeah. You'll need to switch to mir_connection_create_display_config() at some point ☺ | 00:50 |
| bschaefer | sweet, yeah I saw that in the egl examples yesterday, now that makes much more sense :) | 00:50 |
| RAOF | Yeah. Make sure you check the most recent egl examples; I fixed a thinko in them yesterday :) | 00:51 |
| TheDrums | Sorry for the question, but are there any major changes since the last PPA build in this one? Drivers, Mir, Xorg u-s-c? And lastly, I'd guess 0.0.9 is still out several weeks? | 00:52 |
| bschaefer | cool, yeah I need to go back and update some of my branches... I think the ABI might have changed as well | 00:52 |
| RAOF | bschaefer: The client ABI shouldn't have changed. If it did, please hit us with a stick. | 00:53 |
| RAOF | The server ABI is... not yet ☺ | 00:53 |
| bschaefer | RAOF, haha, will do | 00:53 |
| bschaefer | I think the last time was ... the swap buffers call | 00:53 |
| bschaefer | it use to be mir_connection_next_buffer or something? | 00:54 |
| bschaefer | but that was a while ago... | 00:54 |
| RAOF | Ah, yes. We did change that. | 00:55 |
| RAOF | That was a while ago. | 00:55 |
| RAOF | Woot! We have xrandr info. | 00:55 |
| bschaefer | yes it was, I just haven't re-compiled my branch in sometime :) | 00:55 |
| bschaefer | :) | 00:55 |
| RAOF | Although I should probably try it on something that isn't this laptop, as it only supports 1920x1080, which makes the mode list somewhat short! | 00:55 |
| bschaefer | that could help haha | 00:57 |
| robert_ancell | duflu, RAOF etc, can you review https://code.launchpad.net/~robert-ancell/mir/vt-switch-keys/+merge/179067? | 01:10 |
| robert_ancell | would like to knock out the VT issues today | 01:10 |
| RAOF | robert_ancell: Looks like you've still got some debug printfs in there? | 01:13 |
| robert_ancell | RAOF, ah, missed one | 01:13 |
| RAOF | Quite a few, it seems? | 01:13 |
| RAOF | 51, 87, 126... | 01:14 |
| robert_ancell | RAOF, ah, no I just didn't push the last commit | 01:14 |
| robert_ancell | the "clean this up for merging" commit | 01:14 |
| RAOF | :) | 01:15 |
| RAOF | Also, what is KEY_L? | 01:15 |
| duflu | robert_ancell, yep | 01:15 |
| robert_ancell | RAOF, also debug and also removed | 01:15 |
| RAOF | Good, good. | 01:15 |
| robert_ancell | RAOF, I needed to check I wasn't hitting the existing alt+ctrl+Fn keys | 01:15 |
| RAOF | Yeah, fair suck of the saz. | 01:15 |
| RAOF | sav | 01:15 |
| RAOF | robert_ancell: Hm. Why are you explicitly initialising a std::initialiser_list? | 01:32 |
| robert_ancell | RAOF, because std::make_shared seems to get confused | 01:33 |
| RAOF | Ah, if you just do ...({vt_filter})? | 01:33 |
| robert_ancell | RAOF, because the it treats it as a std::initializer_list<std::shared_ptr<VTFilter>> not, std::initializer_list<std::shared_ptr<mi::EventFilter>> | 01:34 |
| RAOF | Urgh. | 01:34 |
| robert_ancell | yes | 01:35 |
| robert_ancell | spent a lot of time trying to understand the error message | 01:35 |
| RAOF | export CC=clang; export CXX=clang++ in ~/.bashrc makes that much easier :) | 01:38 |
| === jono is now known as Guest576 | ||
| duflu | Hey, Ctrl+Alt+Backspace is a much cleaner shutdown than Ctrl+C was. I wonder how much we should still worry about our signal handling... | 01:59 |
| RAOF | robert_ancell: Hm. That doesn't VT switch correctly for me - or, at least, it does vt switch but then immediately switches back. | 02:02 |
| RAOF | robert_ancell: Does it require https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 ? | 02:02 |
| robert_ancell | RAOF, yeah, I saw something similar. It goes away with setsid | 02:02 |
| duflu | robert_ancell: I knew I would have to test with setsid. Does a prereq somewhere make sense? | 02:04 |
| RAOF | Yes. | 02:04 |
| robert_ancell | duflu, I don't think it's strictly required, though I would land it next | 02:04 |
| duflu | robert_ancell: I'm finding similar issues with three of my branches right now... Behaviourally they are quite dependent, but diff-ly they are separate :/ | 02:05 |
| RAOF | As long as we land both at approximately the same time it's ok. | 02:07 |
| RAOF | Ideally we'd land setsid and vt-switch-keys atomically, though. | 02:07 |
| duflu | RAOF: Atomicity can only be guaranteed by telling people not to pull from trunk for a while, I guess | 02:10 |
| RAOF | No, it can also be guaranteed by merging the two branches and landing them as one? | 02:11 |
| duflu | RAOF: Other than that, which clearly we're trying to avoid | 02:11 |
| duflu | That said, I'm already building/testing them together | 02:11 |
| RAOF | It's not clear to me that we're trying to avoid that? | 02:11 |
| RAOF | Anyway, +1 on vt-switch-keys and +1 on setsid. | 02:12 |
| duflu | robert_ancell, hangout? | 02:56 |
| robert_ancell | duflu, syre | 02:57 |
| robert_ancell | thomi, weird thing - https://launchpadlibrarian.net/147042471/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130807.3bzr943saucy0_FAILEDTOBUILD.txt.gz | 03:55 |
| robert_ancell | Fails to build (I saw it locally too). But doesn't occur when the CI builds occur | 03:56 |
| robert_ancell | And the error seems quite straight forward - just missing #import <iostream> | 03:56 |
| thomi | hmmmm | 03:57 |
| thomi | that is odd | 03:57 |
| thomi | you'd expect them both to fail | 03:57 |
| robert_ancell | yeah. When I build locally with ./native-compile.sh it works, but not when using debuild | 03:58 |
| robert_ancell | Maybe debuild sets some cflags and normally it's just a warning, but for debuild it's an error | 03:59 |
| robert_ancell | -Wbe-pedantic-about-std-cerr | 03:59 |
| thomi | robert_ancell: perhaps locally one of the other header files #include's iostream, but the version in the package build env is older, and doesn't? | 03:59 |
| robert_ancell | hah, looks like I broke it in a previous merge. The CI just didn't pick it up | 04:00 |
| robert_ancell | actually it was alf, when he finished off my alt+ctrl+backspace branch | 04:00 |
| thomi | robert_ancell: should we add that flag to the builds? | 04:03 |
| robert_ancell | thomi, We probably should if you can work it out. | 04:03 |
| thomi | robert_ancell: or rather, can you add it to the standard compile flags? | 04:03 |
| robert_ancell | thomi, don't the builds run debuild anyway? | 04:03 |
| thomi | robert_ancell: yeah, I'm not sure what's going on | 04:03 |
| thomi | hmmm.. perhaps the pkg builds override CXXFLAGS? | 04:03 |
| robert_ancell | thomi, can you review https://code.launchpad.net/~robert-ancell/mir/missing-import/+merge/179092 | 04:04 |
| * robert_ancell shrugs | 04:04 | |
| thomi | sure | 04:04 |
| robert_ancell | guess we wait until it happens a second time before spending too much time fixing it | 04:04 |
| thomi | robert_ancell: BTW, did you want a copy of my travel plans for Boston -> AKL so you have a travelling companion on the way home?> | 04:05 |
| thomi | or are you so sick of me now that you'd like my flight details so you can deliberately plan a different route? :P | 04:05 |
| robert_ancell | heading out - be back in an hour | 04:06 |
| robert_ancell | thomi, sure, forward them | 04:06 |
| robert_ancell | ta | 04:06 |
| thomi | robert_ancell: OK, jobs are all kicked off again for the next test run | 04:10 |
| tvoss_ | good morning :) | 04:28 |
| thomi | hi tvoss_, how's life? | 04:29 |
| tvoss_ | thomi, pretty good :) how is life on your side? | 04:29 |
| thomi | tvoss_: still getting over the jetlag, but otherwise good | 04:29 |
| thomi | thinking about investing in a pottery wheel... ;) | 04:29 |
| tvoss_ | thomi, having a pottery wheel around is always a good idea | 04:31 |
| tvoss_ | ;) | 04:31 |
| thomi | gotta get some practise in, before the international competition | 04:31 |
| thomi | I gotta head out, will be back later for late calls. | 04:33 |
| RAOF | Hm. There is no problem that can't be fixed with another layer of indirection! | 04:34 |
| tvoss_ | RAOF, for sure :) | 04:34 |
| Mirv | hmm, I wonder if this https://launchpadlibrarian.net/147032204/buildlog_ubuntu-saucy-armhf.mir_0.0.8%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz is something already taken care of? | 04:41 |
| Mirv | demo_inprocess_surface_client.cpp:58:27: error: 'cerr' is not a member of 'std' | 04:41 |
| RAOF | Mirv: robert_ancell was just talking about that | 04:44 |
| Mirv | ah, I see | 04:45 |
| Mirv | and approved, nice, I'll rerun the stack when it has been merged | 04:46 |
| Mirv | ok, rerunning | 05:00 |
| Mirv | well, unity got there first, might take some time.. | 05:02 |
| RAOF | thomi: Could you kindly turn off the autolanding for mesa into the staging ppa. | 05:21 |
| RAOF | didrocks: Yo! | 05:33 |
| didrocks | RAOF: hey! | 05:33 |
| RAOF | didrocks: I understand you've got a kernel backtrace for the ati system of death? | 05:34 |
| didrocks | RAOF: I don't have a kernel backtrace AFAIK. All the traces were pasted on IRC. | 05:36 |
| tvoss_ | didrocks, jibel pasted the original kernel tr | 05:37 |
| tvoss_ | bt | 05:37 |
| tvoss_ | didrocks, RAOF browser-history ftw: http://paste.ubuntu.com/5959277/ | 05:38 |
| RAOF | Hm. That's interesting. | 05:43 |
| RAOF | didrocks, tvoss_: So, that backtrace has Xorg as the controlling process of the CPU that wedged; it's calling drm_mode_setcrtc, which means that it's not running under unity-system-compositor. | 05:44 |
| tvoss_ | RAOF, hah | 05:45 |
| didrocks | RAOF: right, so we had one run with u-s-c | 05:45 |
| didrocks | which starts, but compiz never finished its init | 05:45 |
| didrocks | (blocked on opengl plugin) | 05:45 |
| didrocks | then, we restart without u-s-c/Mir, under raw Xorg | 05:45 |
| didrocks | and this is what happens ^ | 05:45 |
| tvoss_ | didrocks, this is a very wild guess, but could we update the machine's bios? | 05:46 |
| didrocks | tvoss_: that doesn't change that the previous run failed | 05:46 |
| didrocks | the machine blocking is a consequence | 05:46 |
| robert_ancell | could we accidentally drop that machine out the window? | 05:46 |
| RAOF | didrocks: How do you restart without u-s-c? Is a reboot involved, or a tweak of lightdm.conf.d + a lightdm restart? | 05:47 |
| * didrocks wants to accidentally drop doko out the window | 05:47 | |
| didrocks | RAOF: new install, other stack to tests | 05:47 |
| RAOF | didrocks: So, a reboot? | 05:48 |
| didrocks | RAOF: without any reboot | 05:48 |
| didrocks | it's a lxc container | 05:48 |
| RAOF | Ah, ok. Right. | 05:48 |
| didrocks | so the previous run (with u-s-c failing) was ended | 05:49 |
| didrocks | then, another one for another stack with regular Xorg | 05:49 |
| RAOF | So that would mean the blocking problem is likely to be a failure to clean up u-s-c properly on lightdm shutdown. | 05:49 |
| RAOF | And then there's the problem of u-s-c failing in the first place. | 05:49 |
| didrocks | right | 05:49 |
| didrocks | (only on ati) | 05:50 |
| tvoss_ | robert_ancell, +1 | 05:50 |
| didrocks | intel with the same packages works perfectly | 05:50 |
| robert_ancell | RAOF, could I ask you a favour? I need to do family things before coming back tonight - can you watch https://launchpad.net/~mir-team/+archive/staging/+build/4859513 and when that completes copy (without rebuild) mir 0.0.8+13.10.20130807.3bzr944saucy0 from the staging PPA to the system-compositor-testing PPA? | 05:50 |
| RAOF | robert_ancell: Ok. | 05:50 |
| robert_ancell | Then follow up with u-s-c rev 40 when that autolands (with rebuild) | 05:50 |
| RAOF | Sure. | 05:51 |
| robert_ancell | I'm in fear that by the time I come back and new revision will have landed and wipe out the build :/ | 05:51 |
| RAOF | :) | 05:51 |
| RAOF | didrocks: I don't suppose it's possible to log into that box while it's running the test? | 05:57 |
| didrocks | RAOF: we can, just not now | 05:57 |
| didrocks | doko broke Qt5… | 05:57 |
| RAOF | K | 05:57 |
| didrocks | need to fix that first | 05:57 |
| * RAOF goes back to xrandr hotplug | 05:59 | |
| duflu | RAOF: I suspect I had the Xdamage/Compiz argument backwards. Some Compiz plugins actually expect and require that they be able to spuriously render outside the damage region, and that it only looks *right* if you show the damage region (hide overdraw). | 06:08 |
| duflu | So that was mostly fixed when we enabled page flipping. And would be more fixed by using regional logic again | 06:09 |
| RAOF | duflu: You mean they render *incorrectly* outside the damage region, and expect any rendering outside the damage region to be invisible? | 06:16 |
| duflu | RAOF: Yes | 06:17 |
| RAOF | That's messed up. | 06:17 |
| duflu | RAOF: Most of the obvious occurrences were fixed last year, but not all | 06:17 |
| duflu | RAOF: unityshell too :P | 06:17 |
| RAOF | Also, XMir will display any rendering they do. | 06:17 |
| RAOF | Because XMir sees the damage that *compiz* does. | 06:18 |
| RAOF | Oh. I guess unless compiz does partial frontbuffer updates. | 06:18 |
| duflu | RAOF: Yes, that's just a CCSM tickbox away | 06:18 |
| RAOF | In which case XMir will just see the bits of the frontbuffer you updated. | 06:18 |
| duflu | RAOF: Just untick everything except sync_to_vblank in CCSM>OpenGL | 06:20 |
| RAOF | Frankly I'd prefer to just show the broken rendering and fix it. | 06:20 |
| duflu | RAOF: I don't think you will see any bugs outside of obscure plugins | 06:21 |
| dholbach | good morning | 06:57 |
| RAOF | Wow, Mir takes a while to build on arm. | 07:04 |
| ogra_ | RAOF, locally ? or on the buildd | 07:05 |
| RAOF | On the builld. | 07:05 |
| ogra_ | (we got new buildds yesterday ... ) | 07:05 |
| RAOF | I'm pretty sure I could have had this finished in a qemu schroot in the hour it's taken on the buildd, including the time taken to set up the armhf chroot :) | 07:05 |
| ogra_ | is that a distro buildd or PPA ? | 07:06 |
| RAOF | PPA. | 07:06 |
| ogra_ | would be worrying if its distro | 07:06 |
| ogra_ | ah | 07:06 |
| RAOF | I understand we have shiny new caldexa nodes for our distro buildds. | 07:06 |
| RAOF | That do things like build Mir in less than an hour :) | 07:06 |
| ogra_ | on the distro buildera firefox build takes ~5h now ... was between 20 and 30 before | 07:07 |
| mlankhorst | RAOF: ping | 07:11 |
| mlankhorst | https://launchpadlibrarian.net/146986827/buildlog_ubuntu-saucy-powerpc.xserver-xorg-video-ati_1:7.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz | 07:11 |
| RAOF | mlankhorst: Pong. | 07:11 |
| RAOF | Gah. Did I fail to push the fixed patch for that | 07:11 |
| RAOF | + | 07:11 |
| RAOF | ? | 07:11 |
| mlankhorst | it has come to this | 07:12 |
| RAOF | mlankhorst: I fixed that in one of the pre-7.2.0 uploads, but I may not have pushed all of those to alioth :( | 07:12 |
| mlankhorst | hm reverse debdiff it? :P | 07:13 |
| mlankhorst | seems you're right | 07:14 |
| RAOF | git merge to the rescue. | 07:14 |
| RAOF | robert_ancell: Whoops. Sorry - the armhf build didn't finish before the i386 & amd64 build for the *next* revision. No copy-with-binaries available for us! | 07:15 |
| RAOF | mlankhorst: I'll fix that up, push to git, and upload. | 07:16 |
| mlankhorst | git merge is awesome ;P | 07:17 |
| mlankhorst | do you have dpkg-mergechangelogs set up for git merges too? | 07:19 |
| RAOF | Indeed I do. | 07:28 |
| didrocks | RAOF: ok, let me find an archive I can restore | 07:29 |
| didrocks | are you free to debug Mir? | 07:29 |
| RAOF | didrocks: Uuur, I'll be doing Zoë's bath in a 10 minutes or so. | 07:29 |
| RAOF | I can be available later, or if the machine won't be free then I guess I could get Sam to handle Zoë's bath. | 07:30 |
| alf__ | RAOF: quick question: can an output have more than one preferred modes? | 07:33 |
| RAOF | alf__: I don't believe that makes sense, no. | 07:33 |
| didrocks | RAOF: should be freed, how long will that take you? | 07:34 |
| didrocks | to know if I'm going out for exercise now or later | 07:34 |
| didrocks | or just prepare and block the machine and ping you with the details | 07:34 |
| RAOF | Probably prepare and block the machine & ping me with the details would be best for me. | 07:35 |
| RAOF | I'll probably be ready to start debugging in ~1hr or so. | 07:35 |
| didrocks | RAOF: ok, doing that | 07:35 |
| * RAOF prepares to set up the VPN on his new laptop | 07:36 | |
| robert_ancell | RAOF, damn! | 07:41 |
| thomi | RAOF: would you like it turned off forever? | 07:45 |
| robert_ancell | And the reason mir rebuilt? - didrocks daily landing bumped debian/changelog :) | 07:46 |
| didrocks | robert_ancell: sorry, was it a question? ;) | 07:46 |
| robert_ancell | didrocks, :P | 07:46 |
| thomi | RAOF: I disabled the jenkins job - let me know if/when you want it turned on again | 07:47 |
| robert_ancell | duflu, have you given up with mir+raring? I want to disable all the raring packages from the staging PPA | 07:48 |
| duflu | robert_ancell: No, still using it for now. But I know I lost that argument | 07:48 |
| robert_ancell | duflu, well, it hasn't built for raring in some time, so you must only be building it locally right? | 07:48 |
| duflu | robert_ancell: Yes, always locally. I guess I need the PPA only for the Mesa/Intel changes | 07:49 |
| robert_ancell | thomi, can you disable mir and unity-system-compositor raring builds in the staging PPA? (no rush) | 07:49 |
| robert_ancell | and unity-greeter too I guess | 07:50 |
| thomi | robert_ancell: can get to that tomorrow, sure. | 07:50 |
| thomi | robert_ancell: just raring, right> | 07:50 |
| thomi | ? | 07:50 |
| robert_ancell | yes | 07:50 |
| thomi | ok, made a note. Will do that first thing tomorrow. | 07:51 |
| duflu | ping alf__ | 08:06 |
| robert_ancell | make | 08:40 |
| robert_ancell | cd | 08:40 |
| robert_ancell | cd bzligd/sea | 08:40 |
| robert_ancell | ls | 08:40 |
| robert_ancell | jetessrter | 08:40 |
| RAOF | didrocks: Ping? New laptop has a new ssh key :( | 08:45 |
| seb128 | RAOF, he went out for exercice, he should be back in half an hour | 08:46 |
| RAOF | seb128: Ah. Are you able to shove another ssh key on the box we ssh into? | 08:47 |
| seb128 | robert_ancell, hey, if "jetessrter" is a password of yours, change it :p (you typed that and a bunch of commands in IRC) | 08:47 |
| seb128 | RAOF, I'm afraid I don't know how to do that, maybe jibel can help though | 08:47 |
| seb128 | jibel, ^ | 08:47 |
| jibel | RAOF, which box? | 08:48 |
| RAOF | Whatever 10.97.0.1 is. | 08:49 |
| RAOF | (In the QA lab, I think.) | 08:49 |
| jibel | RAOF, you don't seem to have an account on this box, which user do you use? | 08:49 |
| RAOF | desktop-team | 08:50 |
| seb128 | RAOF, how is your new laptop btw? you got one of the new system76 ones right? they look quite nice | 08:51 |
| RAOF | seb128: They are quite nice. | 08:51 |
| robert_ancell | seb128, heh, must fix that | 08:52 |
| seb128 | robert_ancell, ;-) | 08:52 |
| RAOF | Not quite the same build quality as a high-end thinkpad, but servicable, with a nicer screen and cheaper :) | 08:52 |
| seb128 | RAOF, it's renewal time for me so I'm looking around, though I'm still happy with my 3 years old latitude ... I might go for an ultrabook (the xps13 looks nice, but glossy screen ...) | 08:53 |
| RAOF | Matte screen on the galago :) | 08:54 |
| jibel | RAOF, I re-imported your ssh keys, can you try again? | 08:54 |
| RAOF | jibel: Works, thanks! | 08:55 |
| jibel | yw | 08:55 |
| RAOF | Oh, hello. | 09:03 |
| RAOF | Why is mir_wait_for blocking indefinitely, I wonder? | 09:03 |
| RAOF | Wow. unity-system-compositor has 17 threads. | 09:05 |
| RAOF | duflu: You were playing around in the mir_wait_for pool before - any ideas why mir_wait_for would be blocking indefinitely? | 09:06 |
| duflu | RAOF: Assuming you don't have a logic error, I do recall the design of mir_wait_for is actually not thread safe :/ | 09:07 |
| duflu | RAOF: Perhaps mir_wait_for_one() ... http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga4f9ee1ace58423c5482e9b3018060252 | 09:09 |
| RAOF | Hm. That's probably not it, because we only mir_wait_for in the xserver mainloop | 09:09 |
| alf__ | duflu: pong, sorry lost in console land | 09:12 |
| alf__ | alan_g: @internal_surface, how come we can call as_internal_surface() without the namespace? | 09:13 |
| duflu | alf__: I will defer bothering you while I suspect I might have caused the issue :) | 09:13 |
| alf__ | duflu: ok | 09:13 |
| alan_g | alf__: ADL | 09:14 |
| alf__ | alan_g: ok | 09:17 |
| RAOF | duflu: Why “while ((!expecting && !received) ” in wait_for_all? | 09:19 |
| RAOF | duflu: This seems to be a race condition? | 09:20 |
| duflu | RAOF: Don't know. I thought that was well tested... | 09:20 |
| duflu | RAOF: It's in a unique_lock, so can't race. Only be misused by callers... | 09:21 |
| RAOF | It seems to me that if you call mir_wait_for(mir_connection_do_something()); and your timeslice runs out between mir_connection_do_something and mir_wait_for then it's possible for the request to be processed before mir_wait_for *acquires* that lock. | 09:21 |
| duflu | RAOF: It looks like the kind of situation wait_for_one was invented to solve. The problem with wait_for is that it is unsafe to ever have more than one thread call it | 09:22 |
| duflu | ... cos if you do, the first will win and starve subsequence threads | 09:22 |
| RAOF | But this *does* only ever have one thread call it! | 09:22 |
| duflu | RAOF: Is your received < expecting? | 09:23 |
| duflu | What is expecting? | 09:23 |
| RAOF | No; both are 0 | 09:23 |
| duflu | RAOF: That means no result_received yet | 09:24 |
| RAOF | duflu: Surely it doesn't? | 09:24 |
| duflu | RAOF: It's pretty clear in mir_wait_handle.cpp | 09:24 |
| RAOF | I would have thought expecting > received was no result_received. | 09:24 |
| RAOF | Oh, no; you're quite right. | 09:26 |
| duflu | RAOF: Any result_received is a result. It's just a matter of how many you expect (are committed to wait for) | 09:26 |
| RAOF | If it had been received then there'd be non-zero numbers there. | 09:26 |
| duflu | RAOF: I'm not saying all uses of MirWaitHandle are bug-free, but it looks likely the class itself is. | 09:38 |
| RAOF | Yeah. | 09:39 |
| RAOF | Which suggests that the request just hasn't been processed. | 09:44 |
| RAOF | didrocks: If you need that box back I've probably got enough to think about. | 09:46 |
| didrocks | RAOF: ok, rebooting it to unscrew it now :) | 09:46 |
| didrocks | thanks RAOF | 09:47 |
| RAOF | Bah. Where was that bug again? I should update it. | 09:50 |
| alf__ | RAOF: it seems that KMS supports multiple preferred modes... | 09:53 |
| RAOF | Huh. You live and learn. | 09:53 |
| alf__ | RAOF: but xrandr hides this, probably selects the first/highest preferred | 09:54 |
| alf__ | RAOF: I wonder how it gets this from EDID information, I thought it had only one preferred mode field? | 09:55 |
| RAOF | I knew that I could technically set as many "preferred" modes as I liked; it's just a flag I can apply to a mode. I didn't think it would ever have more than one, though. | 09:55 |
| RAOF | alf__: Likewise. | 09:55 |
| RAOF | alf__: When you say kms supports multiple preferred modes, what do you mean? | 09:58 |
| RAOF | Or, rather - have you seen it *return* multiple preferred modes? | 09:58 |
| alf__ | RAOF: I mean that on both my laptop and desktop I get multiple modes with the preferred flag set, yes | 09:58 |
| RAOF | Oddness. | 09:58 |
| RAOF | I'm surprised you get more than one mode *at all* on your laptop, frankly :) | 09:59 |
| alf__ | RAOF: actually you are right, lvds screen, gives me just one, it's the external screen that supports more there | 09:59 |
| RAOF | Ok. It's not clear to me what the hell's happening there. | 10:30 |
| RAOF | If anyone's got a few cycles spare to be perplexed, https://bugs.launchpad.net/mir/+bug/1204939 is really odd. | 10:31 |
| ubot5 | Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (fails to find GL acceleration) (logind fails to track session?)" [Critical,Triaged] | 10:31 |
| tvoss | alan_g, ping | 10:39 |
| alan_g | tvoss: | 10:41 |
| alf__ | mlankhorst: Hi! Any idea if it's normal for KMS to return multiple "preferred" modes (DRM_MODE_TYPE_PREFERRED set in mode->flags)? A quick survey of the drm kernel code (e.g. for radeon) indicates that this shouldn't happen (unless I missed something). | 10:55 |
| mlankhorst | alf__: why do you ask? | 10:59 |
| mlankhorst | first preferred mode would be the correct one, if there is more for the same connector it's probably a bug | 11:01 |
| duflu | alan_g: The timing failure on N4, is that all the time or intermittent? | 11:10 |
| alan_g | duflu: happened twice - am increasing sample size | 11:11 |
| duflu | alan_g: OK, yeah. I think the test is more at fault than the code. I'm going to loosen the test today and work on improving it another day | 11:12 |
| alan_g | duflu: failed 3 out of 10 | 11:14 |
| duflu | alan_g: What was the highest number reported of the 3? | 11:14 |
| alan_g | duflu: all 1 vs 1 | 11:15 |
| duflu | alan_g: Right, so worst case was ~1% hiccups. That's the test being too strict, or not running long enough (since I shortened everything today) | 11:15 |
| duflu | tvoss: Done, methinks | 11:17 |
| duflu | At least that took long enough that the meat I was meant to cook is fully defrosted for sure | 11:18 |
| alf__ | mlankhorst: on both radeon and intel I get more than one preferred mode for outputs | 11:18 |
| * alan_g wonders why http://unity.ubuntu.com/mir/using_mir_on_android.html still says "stop" - didn't duflu correct that? | 11:18 | |
| duflu | alan_g: Yes but I don't know how the web gets updated | 11:19 |
| alan_g | duflu: it ought to be generated from trunk | 11:19 |
| duflu | alan_g: Wait, no. That's a doc file I forgot to fix | 11:19 |
| alan_g | Not sure how often | 11:20 |
| alan_g | duflu: np - go eat | 11:20 |
| alan_g | tvoss: How do we zap surface flinger in the current image? | 11:24 |
| alan_g | NM I found https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir | 11:53 |
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | hmz any open bugs I can look at? | 12:21 |
| kgunn | mlankhorst: if you'd like to pick up where RAOF has left off https://bugs.launchpad.net/mir/+bug/1204939 | 12:29 |
| ubot5 | Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (hang in mir_wait_for())" [Critical,Triaged] | 12:29 |
| didrocks | kgunn: I noticed that unity_support_test tool is stuck in fact | 12:32 |
| didrocks | (it's launched by compiz) | 12:32 |
| didrocks | so I guess it's the first gl app which is blocking | 12:32 |
| mlankhorst | likely | 12:39 |
| mlankhorst | kgunn: what is that machine btw? | 12:57 |
| === alan_g|lunch is now known as alan_g | ||
| kgunn | mlankhorst: its "otto" which didrocks or jibel can help get you access | 13:01 |
| mlankhorst | didrocks/jibel: ok, I have no idea what's going on from the logs so if I could get access^ | 13:03 |
| didrocks | mlankhorst: kgunn: the machines are under heavy use right now | 13:03 |
| mlankhorst | ok | 13:03 |
| didrocks | kgunn: once we'll have asac's 3h daily release, we won't be able to all to give back access | 13:03 |
| didrocks | which we are going to plug soon | 13:03 |
| didrocks | so it's the last calls, this time, please really looks at the logs, later will be too late :) | 13:03 |
| didrocks | mlankhorst: in ~1h, I should be able to block it | 13:04 |
| didrocks | will you be around? | 13:04 |
| didrocks | mlankhorst: you have the VPN access right? | 13:04 |
| mlankhorst | I'll be here in 1h, I'm on some vpn to qalab | 13:04 |
| didrocks | mlankhorst: what's your ssh key I should import? | 13:05 |
| mlankhorst | https://launchpad.net/~mlankhorst/+sshkeys | 13:05 |
| kgunn | didrocks: understand....but, we've been runnning xmir fine on other ati machines so the problem seems specific to this one | 13:10 |
| didrocks | kgunn: we know what happens with "specific to this one" which then happens to multiple configs, I'm not that idealist ;) | 13:10 |
| didrocks | if on one of the 2 machines we have, it happens (and traditional Xorg is working with acceleration), there is probably something that can affect other | 13:11 |
| kgunn | didrocks: we tried yesterday with 3 others with no problems | 13:11 |
| kgunn | 3 other ati that is | 13:11 |
| didrocks | kgunn: as Unity7, I never uploaded a Unity7 that was screwed on my machines at home | 13:11 |
| didrocks | then… you see that even testing on 4 with the 3 cards were not enough :p | 13:11 |
| didrocks | so I wish we can settle that down | 13:11 |
| seb128 | didrocks, I don't think anyone is trying to deny there is an issue, it's just harder to debug when the hardware you have local access to doesn't reproduce the issue | 13:12 |
| kgunn | didrocks: nvmd, our exchange doesn't seem helpful | 13:12 |
| didrocks | seb128: that exactly why I'm proposing access for the past 2 weeks | 13:12 |
| kgunn | didrocks: again not helpful | 13:13 |
| seb128 | kgunn, what would be helpful to debug, out of access to the machine we have which hit the issue? | 13:13 |
| asac | kgunn: didrocks: i guess you might want to align the exact execution environment so you see the same thing | 13:14 |
| kgunn | seb128: unfortunatley, we're spanning time zones (and we weren't helping ourselves with xorg churn...but we're past that)...so now we need to iterate | 13:14 |
| kgunn | asac: we've verified multiple environ's on other machines....it could even be the specific card/family at this point | 13:15 |
| asac | once you are sure you do the exact same thing, investigating difference in behavioru becomes relevant | 13:15 |
| asac | kgunn: right it could. just want to ensure that we are sure its the different card/family | 13:15 |
| asac | and not something else we do different still | 13:15 |
| didrocks | asac: it's passing with the same packages and setup on the intel machine | 13:15 |
| kgunn | asac: were you on this channel yesterday? | 13:16 |
| asac | that doesnt mean you run stuff in the exact same way that kgunn is running them | 13:16 |
| asac | kgunn: i was in this channel, but not following | 13:16 |
| didrocks | kgunn: wasn't the same with the race issue? you never reproduce it before we spot it as dailies and after that we discovered that a lot of devs got it but juts reboot? (we had the same argument of "we never saw that, it's only you") | 13:16 |
| didrocks | sorry for being extra cautious, but I think we should understand what's happen before pushing u-s-c | 13:17 |
| kgunn | didrocks: ok, let's try it otherway around....would you mind setting up lexington machine via robotfuel to be exactly like otto ? | 13:17 |
| kgunn | this way there is no more questions about setup ? | 13:17 |
| kgunn | didrocks: that would be helpful....what do you think? | 13:17 |
| kgunn | didrocks: to be clear...i am not asking you to push u-s-c....i am trying to repro the problem with ott | 13:18 |
| didrocks | kgunn: first, as we still don't have those 3h-dailies, I'll be able to give access to mlankhorst and block every stacks on this | 13:18 |
| kgunn | otto | 13:18 |
| didrocks | kgunn: I don't know if they have another ati machine with the same card? | 13:18 |
| mlankhorst | what is that machine btw? | 13:18 |
| kgunn | didrocks: got it...but i am anticipating we still won't have it solved | 13:18 |
| * kgunn is a realist | 13:18 | |
| didrocks | mlankhorst: the one I pasted the other day, you will have access | 13:18 |
| didrocks | kgunn: let's hope we know what happens first, RAOF spent more than 1h on it this morning | 13:19 |
| robotfuel | kgunn: I don't think we have a system with the same card | 13:19 |
| didrocks | kgunn: then, yeah, we need a more dynamic QA lab for stuff running on real hardware | 13:19 |
| kgunn | didrocks robotfuel ....why not make sure the one in lexington lab has the same steup/run of a trademark didrocks run ?? | 13:20 |
| kgunn | who cares if the card is different.... | 13:20 |
| kgunn | this goes back to your post a moment ago about teams claiming that stuff isn't broken only to find out it is | 13:20 |
| didrocks | jibel: can you install otto on that one? as it seems kgunn and asac may think otto is the cause of this? | 13:21 |
| didrocks | kgunn: I just wonder as we would have the same issue with intel, or even unity won't even run on traditional Xorg on ati | 13:21 |
| didrocks | which it does ~20 times a day for multiple hours for the past 5 months | 13:21 |
| kgunn | didrocks: jibel .....i am more suspicious of it being a potential ati-issue | 13:21 |
| didrocks | like that driver/card in particular? (completely possible) | 13:22 |
| mlankhorst | my ati works just fine | 13:22 |
| kgunn | didrocks: could be a combo - your specific setup + your specific test run + ati driver (general even) | 13:22 |
| mlankhorst | oh wait PROVE_LOCKING is disabled due to some regression, grrr | 13:22 |
| kgunn | mlankhorst: yeah...i'm just trying to nail the exact environ + test run eliciting the behavior | 13:23 |
| didrocks | kgunn: no test are run at this point as the session never successfully fully comes up, but yeah, setup + ati driver | 13:24 |
| jibel | didrocks, install otto on which one? if there is a box remotely accessible I can deploy the test setup on it of course | 13:24 |
| didrocks | (knowing that it's working on Xorg + unity/compiz on that card) | 13:24 |
| didrocks | robotfuel: ^ | 13:24 |
| mlankhorst | hmz :p | 13:25 |
| mlankhorst | drm: Don't pass negative delta to ktime_sub_ns() | 13:26 |
| mlankhorst | 13:26 | |
| mlankhorst | It takes an unsigned value. This happens not to blow up on 64-bit | 13:26 |
| mlankhorst | architectures, but it does on 32-bit, causing | 13:26 |
| mlankhorst | drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus | 13:26 |
| mlankhorst | timestamps for vblank events. Which in turn causes e.g. gnome-shell to | 13:26 |
| mlankhorst | hang after a DPMS off cycle with current xf86-video-ati Git. | 13:26 |
| robotfuel | jibel: didrocks you can use ps-radeon-hd6870-he | 13:28 |
| mlankhorst | makes me wonder if it only happens to blow up on i386 or not ;) | 13:28 |
| alan_g | alf__: any ideas on how best to progress https://code.launchpad.net/~alan-griffiths/mir/fix-1208774/+merge/178925? | 13:31 |
| alf__ | alan_g: I would be good to find out what the problem is (probably just a linker bug), but I think the workaround is ok for now. | 13:33 |
| kgunn | robotfuel: jibel didrocks mlankhorst ....the key is to setup & "start" the run on ps-radeon-hd6870-he in exactly the same manner | 13:34 |
| kgunn | as otto | 13:34 |
| alan_g | alf__: Feel like voting then? | 13:35 |
| alf__ | alan_g: sure | 13:35 |
| jibel | kgunn, undertood | 13:36 |
| mlankhorst | how do I connect to that one btw? | 13:36 |
| kgunn | robotfuel: ^ ? | 13:37 |
| robotfuel | mlankhorst: https://wiki.canonical.com/UbuntuEngineering/QA/Lab ctrl-f and search for ps-radeon-hd6870-he | 13:38 |
| kgunn | jibel: mlankhorst robotfuel ...thanks for all this....heroes you are! | 13:40 |
| kgunn | or will be :) | 13:40 |
| mlankhorst | is something supposed to happen when i hit connect? | 13:43 |
| mlankhorst | oh there we go | 13:44 |
| mlankhorst | kgunn: hm default xmir works? | 13:50 |
| kgunn | mlankhorst: ....can we ensure our boot and attempt to programatically run are the exact same to didrocks on otto, e.g. he ran unity_support_test | 13:54 |
| didrocks | (compiz does in fact) | 13:54 |
| didrocks | mlankhorst: the machine will be available in 5 minutes | 13:54 |
| === chihchun_afk is now known as chihchun | ||
| kgunn | didrocks: does it run that every boot regardless? (e.g. we don't need to enable any boot script or something) | 13:58 |
| === greyback_ is now known as greyback|latelun | ||
| didrocks | kgunn: if you start an unity session, it's ran | 14:00 |
| kgunn | didrocks: :-/....damn, back to otto | 14:01 |
| kgunn | didrocks: what is the specific card on that again (i'll note it in the bug) | 14:02 |
| didrocks | kgunn: one sec, launching the tests ASAP and noting it on the bug | 14:03 |
| mlankhorst | curiously is otto a machine without its outputs connected to anything? | 14:05 |
| mlankhorst | i suppose I could test that setup locally | 14:10 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mlankhorst | hm my machine died without output connected | 14:19 |
| tvoss | mlankhorst, kgunn, didrocks any more insight into the ati issue? | 14:19 |
| mlankhorst | hah | 14:20 |
| kgunn | tvoss: right now...suddenly seems to work....didrocks suspecting hybris | 14:20 |
| kgunn | getting solved | 14:20 |
| mlankhorst | <4>[ 60.988003] other info that might help us debug this: | 14:20 |
| mlankhorst | <4>[ 60.988003] Possible unsafe locking scenario: | 14:20 |
| mlankhorst | <4>[ 60.988003] | 14:20 |
| mlankhorst | <4>[ 60.988003] CPU0 | 14:20 |
| mlankhorst | <4>[ 60.988003] ---- | 14:20 |
| mlankhorst | <4>[ 60.988003] lock(&mm->mmap_sem); | 14:20 |
| mlankhorst | <4>[ 60.988003] <Interrupt> | 14:20 |
| mlankhorst | <4>[ 60.988003] lock(&mm->mmap_sem); | 14:20 |
| mlankhorst | <4>[ 60.988003] | 14:20 |
| mlankhorst | but no idea wtf is going on there | 14:20 |
| kgunn | mlankhorst: did i speak too soon....is that otto or your local ? | 14:21 |
| mlankhorst | local | 14:21 |
| didrocks | second run, works… | 14:21 |
| didrocks | (well started) | 14:21 |
| didrocks | the machine didn't die | 14:21 |
| mlankhorst | no idea wtf is going on there | 14:21 |
| kgunn | tvoss: then didrocks gonna check diff between yesterday & today | 14:22 |
| kgunn | tvoss: ....enjoying your afternoon off :) | 14:22 |
| mlankhorst | new mir patch for ati at least | 14:22 |
| mlankhorst | meh list corruption in nfs here, grrr | 14:23 |
| mlankhorst | why does nfs have to add a new corruption every time I update my kernel :/ | 14:25 |
| didrocks | kgunn: didn't yet look at it, before yesterday-today: http://paste.ubuntu.com/5962760/ | 14:26 |
| === chihchun is now known as chihchun_afk | ||
| mlankhorst | didrocks: yeah ubuntu2 ati, might have been what fixed it | 14:28 |
| didrocks | mlankhorst: interesting | 14:28 |
| === alan_g is now known as alan_g|tea | ||
| mlankhorst | but no idea really what was going on | 14:29 |
| didrocks | can be that or Mir itself | 14:30 |
| mlankhorst | hm fun, another crash at a random place in the kernel | 14:32 |
| mlankhorst | I'm definitely hitting some nasty fd corruption on this linux/master + airlied/drm-fixes kernel | 14:42 |
| === alan_g|tea is now known as alan_g | ||
| mlankhorst | other machine is fine though :/ | 14:48 |
| didrocks | ok, so can't reproduce anymore | 14:50 |
| didrocks | after 3 runs | 14:50 |
| didrocks | and then one run to regular Xorg with another stack | 14:50 |
| didrocks | no hang | 14:50 |
| didrocks | no machine getting crazy | 14:50 |
| * didrocks just removes a flacky test from the list and will push u-s-c to universe | 14:50 | |
| mlankhorst | ok I think it's radeon's fault on my machine at least, I swapped out the card for another one and that machine works | 14:51 |
| kgunn | jibel: robotfuel didrocks mlankhorst ...thanks for all the help | 14:52 |
| didrocks | kgunn: yw | 14:52 |
| * kgunn 's beer/food list is getting long | 14:52 | |
| mlankhorst | my 6570 hangs really badly, 5570 works | 14:53 |
| mlankhorst | getting really bad kernel memory corruption with the 6570, so I'll have to look at that later | 14:53 |
| kgunn | mlankhorst: thanks... | 14:54 |
| jibel | kgunn, yw, thanks to whoever fixed this crash | 14:54 |
| kgunn | robotfuel: was there a Northern Islands (HD 6xxx) Series ati in lexington working ok ?....just tieing this back to mlankhorst complaint about 6570 | 14:56 |
| robotfuel | kgunn: we have a 6870, but it's not being used on the new server. openarena worked on it before with xmir | 14:57 |
| mlankhorst | I'm close to upstream though, hm perhaps even ahead of upstream, I'll try without some patches :P | 14:58 |
| robotfuel | kgunn: it's the one jibel is testing with | 14:58 |
| mlankhorst | oh i was already testing without those | 14:58 |
| kgunn | robotfuel: cool....yeah, that's definitely same family | 14:58 |
| kgunn | seris | 14:58 |
| kgunn | series | 14:58 |
| mlankhorst | but in my case it's definitely a kernel corruption | 14:59 |
| mlankhorst | no way userspace would screw up this badly :P | 15:00 |
| smartboyhw | mlankhorst, in http://unity.ubuntu.com/mir/using_mir_on_pc.html it says in Running Mir Natively a "some-mir-client" command. | 15:03 |
| smartboyhw | What does that mean? | 15:03 |
| smartboyhw | olli_, ^ | 15:05 |
| olli_ | smartboyhw, in a meeting, kgunn^ | 15:06 |
| kgunn | smartboyhw: like for instance mir_demo_client_egltriangle | 15:12 |
| smartboyhw | kgunn, oK | 15:12 |
| smartboyhw | mir_demo_client_egltriangle | 15:13 |
| smartboyhw | kgunn, whoa nice! | 15:13 |
| kgunn | smartboyhw: there's several there | 15:15 |
| smartboyhw | kgunn, you should provide a list to us:P | 15:15 |
| === greyback|latelun is now known as greyback | ||
| alan_g | smartboyhw: ls mir_demo_client* | 15:34 |
| smartboyhw | alan_g, great, thanks | 15:34 |
| kgunn | racarr: can you join us ?? | 15:35 |
| === om26er is now known as om26er|away | ||
| === greyback is now known as greyback|dinner | ||
| === alan_g is now known as alan_g|EOD | ||
| === om26er|away is now known as om26er | ||
| kgunn | racarr: ping | 18:07 |
| kgunn | racarr: ping (sorry...i kept rebooting i know) | 18:26 |
| racarr | kgunn: pongish | 18:42 |
| racarr | Hey wait I'm supposed to be racarr|dentist | 18:42 |
| racarr | what's up? | 18:42 |
| kgunn | racarr: no worries...hopefully its a "good" dentist experience & not a "painful" one | 18:45 |
| racarr | medium lol | 18:45 |
| kgunn | racarr: was just curious...we were wondering on surface configurator if mir is to control the osk visibiltiy with the minimize attribute | 18:45 |
| kgunn | ? | 18:45 |
| racarr | kgunn: Yeah! I think that's the idea. | 18:46 |
| racarr | we need to hook it up to qtubuntu | 18:46 |
| kgunn | racarr: cool greyback|dinner ...dang he's at dinner ^ | 18:46 |
| racarr | but dandrader was telling me mallit just calls like QWindow show/hide | 18:46 |
| racarr | so, the surface configurator actually does two things for the OSK: | 18:46 |
| racarr | 1. Let's it recognize the overlay surface type (and approve/dissaprove setting this) with select_attribute_value | 18:46 |
| racarr | 2. Implement minimize/restore with the attribute_set interface | 18:47 |
| kgunn | racarr: that's perfect! | 18:47 |
| kgunn | thanks for pushing that... | 18:47 |
| racarr | :D | 18:50 |
| racarr | I have to go again soon. I failed to bring proof of residence to the DMV yesterday so trying again today | 18:51 |
| racarr | Drivers license expires tomorrow so if I don't do it today I have to take a driving test >< | 18:51 |
| racarr | I think, based on kdubs branch though, I can submit a much simpler version of client-focus-notifications | 18:51 |
| racarr | hopefully this evening or tomorrow | 18:51 |
| === greyback|dinner is now known as greyback | ||
| greyback | kgunn: ack, all sounds good to me | 19:11 |
| kgunn | bschaefer: thanks for the help yesterday!....glad it "resolved itself" | 20:05 |
| bschaefer | kgunn, haha np, as I am...and I hope it stays that way | 20:06 |
| bschaefer | and yay u-s-c is in main :) | 20:06 |
| kgunn | bschaefer: i know....feels naughty! | 20:06 |
| kdub | yay | 20:20 |
| robert_ancell | thomi, hey, did you forward that itinery? | 21:10 |
| racarr | next time you guys come to oakland I can not recommend the california DMV | 21:10 |
| racarr | for a fun afternoon | 21:10 |
| kdub | racarr, in lexington next month, i'll show you my license with my dmv picture | 21:11 |
| kdub | pretty funny how evidently angry i am in it :P | 21:11 |
| racarr | haha | 21:12 |
| robert_ancell | kdub, ha! | 21:12 |
| racarr | apparently when the person yesterday told me I needed a copy nof my birth certificate | 21:12 |
| racarr | they meant in particular, the original copy | 21:12 |
| thomi | robert_ancell: we're having trouble finding flights from bos -> SFO or LAX that don't involve a huge stopover. Should have final flights tomorrow | 21:12 |
| robert_ancell | thomi, k | 21:13 |
| robert_ancell | thomi, is it faster to go via NYC? | 21:15 |
| thomi | robert_ancell: NYC is kind of in the wrong direction | 21:20 |
| thomi | I have faith that BTS will sortit out. Worst case is 10 hours in SFO - maybe time to do a bit of sightseeing :) | 21:20 |
| racarr | thomi: That's just long enough to get a drivers license at the DMV! | 21:23 |
| racarr | :p | 21:23 |
| thomi | racarr: I already ahve two drivers licenses, why would I want a third? | 21:23 |
| racarr | thomi: :) | 21:24 |
| jono | hey guys | 21:24 |
| jono | FYI: to track flavor bugs I am going to ask flavors to tag their bugs with 'flavormirbug' | 21:25 |
| jono | the resulting search with these bugs is at https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&fie | 21:25 |
| jono | ld.tag=flavormirbug&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search | 21:25 |
| jono | kgunn, ^ | 21:25 |
| jono | is there any chance we could get #1208250 on a priority list? | 21:25 |
| thomi | haha, nice URL | 21:25 |
| jono | oh, it is Critical | 21:25 |
| jono | but seems not assigned | 21:26 |
| jono | thomi, seriously | 21:26 |
| robert_ancell | jono, cheers | 21:35 |
| jono | robert_ancell, np | 21:35 |
| jono | they are choosing whether to go with Mir on the 22nd | 21:35 |
| jono | so I think if we can resolve most of their issues by then, it should encourage the Xubuntu community to ship Mir | 21:36 |
| thomi | robert_ancell: robotfuel is still hitting this issue in the xmir tests: https://bugs.launchpad.net/xmir/+bug/1209000 | 22:11 |
| ubot5 | Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,Fix released] | 22:11 |
| robotfuel | thomi: I still need to check if that's the case with the new drivers, this is the bug I was talking about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 | 22:12 |
| ubot5 | Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "[radeonsi] radeonhd "southern islands" 3d hardware acceleration" [Undecided,Confirmed] | 22:12 |
| thomi | robotfuel: ahhh ok | 22:13 |
| robotfuel | thomi: it looks like they are related | 22:13 |
| thomi | robert_ancell: so that card is listed on the xmir go/no-go acceptance criteria | 22:13 |
| thomi | robert_ancell: so it's needed before we turn xmir on for 13.10 | 22:13 |
| thomi | robert_ancell: I wonder if you can use your team-lead super powers to poke someone to fix this for us? | 22:14 |
| robert_ancell | thomi, otp | 22:14 |
| robotfuel | thomi: there is actually a new bug, x crashes now with /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate | 22:15 |
| thomi | robotfuel: OK, can you please make sure that all the relevant bugs are linked in the SS, so I can keep bugging people until they get fixed? | 22:16 |
| robotfuel | thomi: yes everything but that bug is to date | 22:17 |
| thomi | robotfuel: OK, so there's 3 issue, the two bugs in the SS (both linked above), and the third that you've just mentioned? | 22:18 |
| robotfuel | the 1209000 isn't happening anymore, now it's undefined symbol: exaGetPixmapDriverPrivate | 22:20 |
| robotfuel | thomi: I'll ping you when apport is done uploading the bug | 22:20 |
| thomi | sweet | 22:20 |
| robert_ancell | thomi, robotfuel, ah, RAOF said that one looked like exa support wasn't loaded | 22:21 |
| robert_ancell | please assign to RAOF for triaging once its up | 22:21 |
| robert_ancell | What are the other two issues? | 22:21 |
| racarr | kdub: Have been going through connect-display-request btw. I like it :) | 22:22 |
| kdub | oh, great :) | 22:22 |
| robotfuel | robert_ancell: it's one other issue not 2 | 22:22 |
| racarr | will rework client-focus-notifications on the refactoring there to get rid of the event sink changes | 22:22 |
| robotfuel | robert_ancell: this is the other issue https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 | 22:22 |
| ubot5 | Launchpad bug 1209397 in xserver-xorg-video-ati (Ubuntu) "[radeonsi] radeonhd "southern islands" 3d hardware acceleration" [Undecided,Confirmed] | 22:22 |
| racarr | I am starting to wonder though... | 22:22 |
| racarr | (not for this branch, just in general) | 22:22 |
| robert_ancell | robotfuel, that card has issues on traditional X right? | 22:23 |
| racarr | perhaps SessionManager isn't mf::Shell | 22:23 |
| robotfuel | robert_ancell: yes https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 is a traditional x bug | 22:23 |
| racarr | you know? There are kind of different roles between this handle_surface_created, and open_session type stuff | 22:23 |
| racarr | and I'm more inclined to call the handle_surface_created, etc, the 'shell' | 22:24 |
| kdub | racarr, yeah, should make picking out right where the focus occurred a bit easier | 22:26 |
| kdub | and should also let you write an implementation of focus that depends on events | 22:26 |
| kdub | so it can be like, z-order based in a simple case, or as complicated a class you can think up | 22:26 |
| racarr | mm | 22:27 |
| kdub | being in this part of the system for a bit pointed out to me how the shell's grand data structure | 22:27 |
| kdub | is the SessionContainer | 22:27 |
| kdub | with mir's grand data structure being the SurfaceStack | 22:27 |
| kdub | things are starting to shape up along those lines :) | 22:27 |
| robotfuel | thomi: spreadsheet is up to date | 22:28 |
| racarr | Alan thinks the session assosciation should be in the SurfaceStack (SceneGraph) | 22:28 |
| racarr | and I'm not totally sure yet. | 22:28 |
| thomi | yhanks | 22:28 |
| thomi | thanks even | 22:28 |
| racarr | on one hand it might make certain synchronization issues, and exposing stuff out to the shell, etc, easier and safer | 22:29 |
| robert_ancell | thomi, did you disable the raring builds from the testing ppa? | 22:29 |
| racarr | on the other hand 1. I'm not sure how to do it and 2. I kind of like the way that the shell functions as | 22:29 |
| robotfuel | thomi: I am going to mark https://bugs.launchpad.net/xmir/+bug/1209000 fixed released because it's not happening anymore | 22:29 |
| racarr | something on top of the SurfaceStack | 22:29 |
| ubot5 | Launchpad bug 1209000 in XMir "radeon hd7850 fails to load driver from system-compositor-testing ppa with gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: radeonsi" [Undecided,Fix released] | 22:29 |
| robotfuel | heh it was already marked fixed release :P | 22:31 |
| kdub | racarr, i'm not sure either about that, but thats an initial reaction | 22:31 |
| racarr | kdub: Perhaps part of the session manager is really part of the session container | 22:44 |
| racarr | and the rest is mf::Shell | 22:44 |
| racarr | i.e.open_session/close_session anyway | 22:44 |
| racarr | then the shell gets on_session_opened, on_session_closed sort of stuff | 22:44 |
| kdub | well, the session manager is being reduced to the session factory | 22:46 |
| kdub | create_surface_for can be eliminated if we have a "SessionMediator-like" class for our internal clients | 22:47 |
| RAOF | Gah. Why is BTS 50% more expensive than flights I could book myself? | 22:48 |
| robert_ancell | RAOF, yeah, I always get that too | 23:06 |
| robert_ancell | RAOF, we really should have an Australasian travel agent | 23:06 |
| RAOF | Yeah. | 23:07 |
| RAOF | Also. UA - just say no. | 23:07 |
| racarr | kdub: mm. maybe there is a SessionMediator that can work for internal and external client sort of object | 23:08 |
| racarr | and the RPC also has a "socket mediator" or something | 23:08 |
| robert_ancell | bbl | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!