[00:00] I'll fire up the ati system again. [00:01] RAOF, thanks, kgunn just wanted another working xmir data point, so for 1 is failing and 2 are working [00:02] s/for/far ... geez [00:05] Heh [00:08] * robert_ancell -> lunch [00:23] my 1tb harddrive is 80% full of compiled mir code... bzr -_- [00:24] RAOF: can you please ping didrocks when he comes online & try to help resolve his ati issue...its our last blocker [00:24] kgunn: Sure. [00:25] kdub: cd ~/.bazaar/plugins; bzr branch lp:bzr-removable ; cd ~/Devel/Mir ; for I in $(bzr removable trunk ) ; do rm -r $I ; done ☺ [00:26] RAOF, hmm, might give it a try! [00:27] 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] ah, that would be useful [00:28] It also adds the "unremovable" command, which does the reverse, and tells you why it's not removable [00:29] * 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:30] * RAOF books travel to Boston [00:31] bschaefer: Yup; My ati box still works with unity-system-compositor [00:32] RAOF, thanks [00:38] Now; does this XMir populate xrandr data? [00:42] RAOF, where would one check for this data? [00:42] i see this in my syslog: Aug 7 16:30:51 bschaefer-GA-870A-UD3 colord: Device added: xrandr-XMIR-1 [00:45] bschaefer: Oh, your XMir definitely doesn't. I'm just hooking up the new Mir multi-head API. [00:45] oo cool, though im not sure what that is :) [00:48] xrandr will report the full set of modes your outputs can do, rather than just the single mode Mir set on startup :) [00:49] 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:50] Yeah. You'll need to switch to mir_connection_create_display_config() at some point ☺ [00:50] sweet, yeah I saw that in the egl examples yesterday, now that makes much more sense :) [00:51] Yeah. Make sure you check the most recent egl examples; I fixed a thinko in them yesterday :) [00:52] 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] cool, yeah I need to go back and update some of my branches... I think the ABI might have changed as well [00:53] bschaefer: The client ABI shouldn't have changed. If it did, please hit us with a stick. [00:53] The server ABI is... not yet ☺ [00:53] RAOF, haha, will do [00:53] I think the last time was ... the swap buffers call [00:54] it use to be mir_connection_next_buffer or something? [00:54] but that was a while ago... [00:55] Ah, yes. We did change that. [00:55] That was a while ago. [00:55] Woot! We have xrandr info. [00:55] yes it was, I just haven't re-compiled my branch in sometime :) [00:55] :) [00:55] 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:57] that could help haha [01:10] duflu, RAOF etc, can you review https://code.launchpad.net/~robert-ancell/mir/vt-switch-keys/+merge/179067? [01:10] would like to knock out the VT issues today [01:13] robert_ancell: Looks like you've still got some debug printfs in there? [01:13] RAOF, ah, missed one [01:13] Quite a few, it seems? [01:14] 51, 87, 126... [01:14] RAOF, ah, no I just didn't push the last commit [01:14] the "clean this up for merging" commit [01:15] :) [01:15] Also, what is KEY_L? [01:15] robert_ancell, yep [01:15] RAOF, also debug and also removed [01:15] Good, good. [01:15] RAOF, I needed to check I wasn't hitting the existing alt+ctrl+Fn keys [01:15] Yeah, fair suck of the saz. [01:15] sav [01:32] robert_ancell: Hm. Why are you explicitly initialising a std::initialiser_list? [01:33] RAOF, because std::make_shared seems to get confused [01:33] Ah, if you just do ...({vt_filter})? [01:34] RAOF, because the it treats it as a std::initializer_list> not, std::initializer_list> [01:34] Urgh. [01:35] yes [01:35] spent a lot of time trying to understand the error message [01:38] export CC=clang; export CXX=clang++ in ~/.bashrc makes that much easier :) === jono is now known as Guest576 [01:59] 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... [02:02] 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] robert_ancell: Does it require https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800 ? [02:02] RAOF, yeah, I saw something similar. It goes away with setsid [02:04] robert_ancell: I knew I would have to test with setsid. Does a prereq somewhere make sense? [02:04] Yes. [02:04] duflu, I don't think it's strictly required, though I would land it next [02:05] 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:07] As long as we land both at approximately the same time it's ok. [02:07] Ideally we'd land setsid and vt-switch-keys atomically, though. [02:10] RAOF: Atomicity can only be guaranteed by telling people not to pull from trunk for a while, I guess [02:11] No, it can also be guaranteed by merging the two branches and landing them as one? [02:11] RAOF: Other than that, which clearly we're trying to avoid [02:11] That said, I'm already building/testing them together [02:11] It's not clear to me that we're trying to avoid that? [02:12] Anyway, +1 on vt-switch-keys and +1 on setsid. [02:56] robert_ancell, hangout? [02:57] duflu, syre [03:55] thomi, weird thing - https://launchpadlibrarian.net/147042471/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130807.3bzr943saucy0_FAILEDTOBUILD.txt.gz [03:56] Fails to build (I saw it locally too). But doesn't occur when the CI builds occur [03:56] And the error seems quite straight forward - just missing #import [03:57] hmmmm [03:57] that is odd [03:57] you'd expect them both to fail [03:58] yeah. When I build locally with ./native-compile.sh it works, but not when using debuild [03:59] Maybe debuild sets some cflags and normally it's just a warning, but for debuild it's an error [03:59] -Wbe-pedantic-about-std-cerr [03:59] 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? [04:00] hah, looks like I broke it in a previous merge. The CI just didn't pick it up [04:00] actually it was alf, when he finished off my alt+ctrl+backspace branch [04:03] robert_ancell: should we add that flag to the builds? [04:03] thomi, We probably should if you can work it out. [04:03] robert_ancell: or rather, can you add it to the standard compile flags? [04:03] thomi, don't the builds run debuild anyway? [04:03] robert_ancell: yeah, I'm not sure what's going on [04:03] hmmm.. perhaps the pkg builds override CXXFLAGS? [04:04] thomi, can you review https://code.launchpad.net/~robert-ancell/mir/missing-import/+merge/179092 [04:04] * robert_ancell shrugs [04:04] sure [04:04] guess we wait until it happens a second time before spending too much time fixing it [04:05] 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] 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:06] heading out - be back in an hour [04:06] thomi, sure, forward them [04:06] ta [04:10] robert_ancell: OK, jobs are all kicked off again for the next test run [04:28] good morning :) [04:29] hi tvoss_, how's life? [04:29] thomi, pretty good :) how is life on your side? [04:29] tvoss_: still getting over the jetlag, but otherwise good [04:29] thinking about investing in a pottery wheel... ;) [04:31] thomi, having a pottery wheel around is always a good idea [04:31] ;) [04:31] gotta get some practise in, before the international competition [04:33] I gotta head out, will be back later for late calls. [04:34] Hm. There is no problem that can't be fixed with another layer of indirection! [04:34] RAOF, for sure :) [04:41] 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] demo_inprocess_surface_client.cpp:58:27: error: 'cerr' is not a member of 'std' [04:44] Mirv: robert_ancell was just talking about that [04:45] ah, I see [04:46] and approved, nice, I'll rerun the stack when it has been merged [05:00] ok, rerunning [05:02] well, unity got there first, might take some time.. [05:21] thomi: Could you kindly turn off the autolanding for mesa into the staging ppa. [05:33] didrocks: Yo! [05:33] RAOF: hey! [05:34] didrocks: I understand you've got a kernel backtrace for the ati system of death? [05:36] RAOF: I don't have a kernel backtrace AFAIK. All the traces were pasted on IRC. [05:37] didrocks, jibel pasted the original kernel tr [05:37] bt [05:38] didrocks, RAOF browser-history ftw: http://paste.ubuntu.com/5959277/ [05:43] Hm. That's interesting. [05:44] 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:45] RAOF, hah [05:45] RAOF: right, so we had one run with u-s-c [05:45] which starts, but compiz never finished its init [05:45] (blocked on opengl plugin) [05:45] then, we restart without u-s-c/Mir, under raw Xorg [05:45] and this is what happens ^ [05:46] didrocks, this is a very wild guess, but could we update the machine's bios? [05:46] tvoss_: that doesn't change that the previous run failed [05:46] the machine blocking is a consequence [05:46] could we accidentally drop that machine out the window? [05:47] 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] RAOF: new install, other stack to tests [05:48] didrocks: So, a reboot? [05:48] RAOF: without any reboot [05:48] it's a lxc container [05:48] Ah, ok. Right. [05:49] so the previous run (with u-s-c failing) was ended [05:49] then, another one for another stack with regular Xorg [05:49] 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] And then there's the problem of u-s-c failing in the first place. [05:49] right [05:50] (only on ati) [05:50] robert_ancell, +1 [05:50] intel with the same packages works perfectly [05:50] 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] robert_ancell: Ok. [05:50] Then follow up with u-s-c rev 40 when that autolands (with rebuild) [05:51] Sure. [05:51] I'm in fear that by the time I come back and new revision will have landed and wipe out the build :/ [05:51] :) [05:57] didrocks: I don't suppose it's possible to log into that box while it's running the test? [05:57] RAOF: we can, just not now [05:57] doko broke Qt5… [05:57] K [05:57] need to fix that first [05:59] * RAOF goes back to xrandr hotplug [06:08] 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:09] So that was mostly fixed when we enabled page flipping. And would be more fixed by using regional logic again [06:16] duflu: You mean they render *incorrectly* outside the damage region, and expect any rendering outside the damage region to be invisible? [06:17] RAOF: Yes [06:17] That's messed up. [06:17] RAOF: Most of the obvious occurrences were fixed last year, but not all [06:17] RAOF: unityshell too :P [06:17] Also, XMir will display any rendering they do. [06:18] Because XMir sees the damage that *compiz* does. [06:18] Oh. I guess unless compiz does partial frontbuffer updates. [06:18] RAOF: Yes, that's just a CCSM tickbox away [06:18] In which case XMir will just see the bits of the frontbuffer you updated. [06:20] RAOF: Just untick everything except sync_to_vblank in CCSM>OpenGL [06:20] Frankly I'd prefer to just show the broken rendering and fix it. [06:21] RAOF: I don't think you will see any bugs outside of obscure plugins [06:57] good morning [07:04] Wow, Mir takes a while to build on arm. [07:05] RAOF, locally ? or on the buildd [07:05] On the builld. [07:05] (we got new buildds yesterday ... ) [07:05] 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:06] is that a distro buildd or PPA ? [07:06] PPA. [07:06] would be worrying if its distro [07:06] ah [07:06] I understand we have shiny new caldexa nodes for our distro buildds. [07:06] That do things like build Mir in less than an hour :) [07:07] on the distro buildera firefox build takes ~5h now ... was between 20 and 30 before [07:11] RAOF: ping [07:11] https://launchpadlibrarian.net/146986827/buildlog_ubuntu-saucy-powerpc.xserver-xorg-video-ati_1:7.2.0-0ubuntu1_FAILEDTOBUILD.txt.gz [07:11] mlankhorst: Pong. [07:11] Gah. Did I fail to push the fixed patch for that [07:11] + [07:11] ? [07:12] it has come to this [07:12] 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:13] hm reverse debdiff it? :P [07:14] seems you're right [07:14] git merge to the rescue. [07:15] 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:16] mlankhorst: I'll fix that up, push to git, and upload. [07:17] git merge is awesome ;P [07:19] do you have dpkg-mergechangelogs set up for git merges too? [07:28] Indeed I do. [07:29] RAOF: ok, let me find an archive I can restore [07:29] are you free to debug Mir? [07:29] didrocks: Uuur, I'll be doing Zoë's bath in a 10 minutes or so. [07:30] 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:33] RAOF: quick question: can an output have more than one preferred modes? [07:33] alf__: I don't believe that makes sense, no. [07:34] RAOF: should be freed, how long will that take you? [07:34] to know if I'm going out for exercise now or later [07:34] or just prepare and block the machine and ping you with the details [07:35] Probably prepare and block the machine & ping me with the details would be best for me. [07:35] I'll probably be ready to start debugging in ~1hr or so. [07:35] RAOF: ok, doing that [07:36] * RAOF prepares to set up the VPN on his new laptop [07:41] RAOF, damn! [07:45] RAOF: would you like it turned off forever? [07:46] And the reason mir rebuilt? - didrocks daily landing bumped debian/changelog :) [07:46] robert_ancell: sorry, was it a question? ;) [07:46] didrocks, :P [07:47] RAOF: I disabled the jenkins job - let me know if/when you want it turned on again [07:48] duflu, have you given up with mir+raring? I want to disable all the raring packages from the staging PPA [07:48] robert_ancell: No, still using it for now. But I know I lost that argument [07:48] duflu, well, it hasn't built for raring in some time, so you must only be building it locally right? [07:49] robert_ancell: Yes, always locally. I guess I need the PPA only for the Mesa/Intel changes [07:49] thomi, can you disable mir and unity-system-compositor raring builds in the staging PPA? (no rush) [07:50] and unity-greeter too I guess [07:50] robert_ancell: can get to that tomorrow, sure. [07:50] robert_ancell: just raring, right> [07:50] ? [07:50] yes [07:51] ok, made a note. Will do that first thing tomorrow. [08:06] ping alf__ [08:40] make [08:40] cd [08:40] cd bzligd/sea [08:40] ls [08:40] jetessrter [08:45] didrocks: Ping? New laptop has a new ssh key :( [08:46] RAOF, he went out for exercice, he should be back in half an hour [08:47] seb128: Ah. Are you able to shove another ssh key on the box we ssh into? [08:47] 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] RAOF, I'm afraid I don't know how to do that, maybe jibel can help though [08:47] jibel, ^ [08:48] RAOF, which box? [08:49] Whatever 10.97.0.1 is. [08:49] (In the QA lab, I think.) [08:49] RAOF, you don't seem to have an account on this box, which user do you use? [08:50] desktop-team [08:51] RAOF, how is your new laptop btw? you got one of the new system76 ones right? they look quite nice [08:51] seb128: They are quite nice. [08:52] seb128, heh, must fix that [08:52] robert_ancell, ;-) [08:52] Not quite the same build quality as a high-end thinkpad, but servicable, with a nicer screen and cheaper :) [08:53] 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:54] Matte screen on the galago :) [08:54] RAOF, I re-imported your ssh keys, can you try again? [08:55] jibel: Works, thanks! [08:55] yw [09:03] Oh, hello. [09:03] Why is mir_wait_for blocking indefinitely, I wonder? [09:05] Wow. unity-system-compositor has 17 threads. [09:06] duflu: You were playing around in the mir_wait_for pool before - any ideas why mir_wait_for would be blocking indefinitely? [09:07] RAOF: Assuming you don't have a logic error, I do recall the design of mir_wait_for is actually not thread safe :/ [09:09] RAOF: Perhaps mir_wait_for_one() ... http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga4f9ee1ace58423c5482e9b3018060252 [09:09] Hm. That's probably not it, because we only mir_wait_for in the xserver mainloop [09:12] duflu: pong, sorry lost in console land [09:13] alan_g: @internal_surface, how come we can call as_internal_surface() without the namespace? [09:13] alf__: I will defer bothering you while I suspect I might have caused the issue :) [09:13] duflu: ok [09:14] alf__: ADL [09:17] alan_g: ok [09:19] duflu: Why “while ((!expecting && !received) ” in wait_for_all? [09:20] duflu: This seems to be a race condition? [09:20] RAOF: Don't know. I thought that was well tested... [09:21] RAOF: It's in a unique_lock, so can't race. Only be misused by callers... [09:21] 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:22] 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] ... cos if you do, the first will win and starve subsequence threads [09:22] But this *does* only ever have one thread call it! [09:23] RAOF: Is your received < expecting? [09:23] What is expecting? [09:23] No; both are 0 [09:24] RAOF: That means no result_received yet [09:24] duflu: Surely it doesn't? [09:24] RAOF: It's pretty clear in mir_wait_handle.cpp [09:24] I would have thought expecting > received was no result_received. [09:26] Oh, no; you're quite right. [09:26] RAOF: Any result_received is a result. It's just a matter of how many you expect (are committed to wait for) [09:26] If it had been received then there'd be non-zero numbers there. [09:38] RAOF: I'm not saying all uses of MirWaitHandle are bug-free, but it looks likely the class itself is. [09:39] Yeah. [09:44] Which suggests that the request just hasn't been processed. [09:46] didrocks: If you need that box back I've probably got enough to think about. [09:46] RAOF: ok, rebooting it to unscrew it now :) [09:47] thanks RAOF [09:50] Bah. Where was that bug again? I should update it. [09:53] RAOF: it seems that KMS supports multiple preferred modes... [09:53] Huh. You live and learn. [09:54] RAOF: but xrandr hides this, probably selects the first/highest preferred [09:55] RAOF: I wonder how it gets this from EDID information, I thought it had only one preferred mode field? [09:55] 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] alf__: Likewise. [09:58] alf__: When you say kms supports multiple preferred modes, what do you mean? [09:58] Or, rather - have you seen it *return* multiple preferred modes? [09:58] RAOF: I mean that on both my laptop and desktop I get multiple modes with the preferred flag set, yes [09:58] Oddness. [09:59] I'm surprised you get more than one mode *at all* on your laptop, frankly :) [09:59] RAOF: actually you are right, lvds screen, gives me just one, it's the external screen that supports more there [10:30] Ok. It's not clear to me what the hell's happening there. [10:31] If anyone's got a few cycles spare to be perplexed, https://bugs.launchpad.net/mir/+bug/1204939 is really odd. [10:31] 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:39] alan_g, ping [10:41] tvoss: [10:55] 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:59] alf__: why do you ask? [11:01] first preferred mode would be the correct one, if there is more for the same connector it's probably a bug [11:10] alan_g: The timing failure on N4, is that all the time or intermittent? [11:11] duflu: happened twice - am increasing sample size [11:12] 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:14] duflu: failed 3 out of 10 [11:14] alan_g: What was the highest number reported of the 3? [11:15] duflu: all 1 vs 1 [11:15] 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:17] tvoss: Done, methinks [11:18] At least that took long enough that the meat I was meant to cook is fully defrosted for sure [11:18] 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:19] alan_g: Yes but I don't know how the web gets updated [11:19] duflu: it ought to be generated from trunk [11:19] alan_g: Wait, no. That's a doc file I forgot to fix [11:20] Not sure how often [11:20] duflu: np - go eat [11:24] tvoss: How do we zap surface flinger in the current image? [11:53] NM I found https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir === alan_g is now known as alan_g|lunch [12:21] hmz any open bugs I can look at? [12:29] mlankhorst: if you'd like to pick up where RAOF has left off https://bugs.launchpad.net/mir/+bug/1204939 [12:29] Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (hang in mir_wait_for())" [Critical,Triaged] [12:32] kgunn: I noticed that unity_support_test tool is stuck in fact [12:32] (it's launched by compiz) [12:32] so I guess it's the first gl app which is blocking [12:39] likely [12:57] kgunn: what is that machine btw? === alan_g|lunch is now known as alan_g [13:01] mlankhorst: its "otto" which didrocks or jibel can help get you access [13:03] didrocks/jibel: ok, I have no idea what's going on from the logs so if I could get access^ [13:03] mlankhorst: kgunn: the machines are under heavy use right now [13:03] ok [13:03] kgunn: once we'll have asac's 3h daily release, we won't be able to all to give back access [13:03] which we are going to plug soon [13:03] so it's the last calls, this time, please really looks at the logs, later will be too late :) [13:04] mlankhorst: in ~1h, I should be able to block it [13:04] will you be around? [13:04] mlankhorst: you have the VPN access right? [13:04] I'll be here in 1h, I'm on some vpn to qalab [13:05] mlankhorst: what's your ssh key I should import? [13:05] https://launchpad.net/~mlankhorst/+sshkeys [13:10] didrocks: understand....but, we've been runnning xmir fine on other ati machines so the problem seems specific to this one [13:10] kgunn: we know what happens with "specific to this one" which then happens to multiple configs, I'm not that idealist ;) [13:11] 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] didrocks: we tried yesterday with 3 others with no problems [13:11] 3 other ati that is [13:11] kgunn: as Unity7, I never uploaded a Unity7 that was screwed on my machines at home [13:11] then… you see that even testing on 4 with the 3 cards were not enough :p [13:11] so I wish we can settle that down [13:12] 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] didrocks: nvmd, our exchange doesn't seem helpful [13:12] seb128: that exactly why I'm proposing access for the past 2 weeks [13:13] didrocks: again not helpful [13:13] kgunn, what would be helpful to debug, out of access to the machine we have which hit the issue? [13:14] kgunn: didrocks: i guess you might want to align the exact execution environment so you see the same thing [13:14] 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:15] asac: we've verified multiple environ's on other machines....it could even be the specific card/family at this point [13:15] once you are sure you do the exact same thing, investigating difference in behavioru becomes relevant [13:15] kgunn: right it could. just want to ensure that we are sure its the different card/family [13:15] and not something else we do different still [13:15] asac: it's passing with the same packages and setup on the intel machine [13:16] asac: were you on this channel yesterday? [13:16] that doesnt mean you run stuff in the exact same way that kgunn is running them [13:16] kgunn: i was in this channel, but not following [13:16] 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:17] sorry for being extra cautious, but I think we should understand what's happen before pushing u-s-c [13:17] didrocks: ok, let's try it otherway around....would you mind setting up lexington machine via robotfuel to be exactly like otto ? [13:17] this way there is no more questions about setup ? [13:17] didrocks: that would be helpful....what do you think? [13:18] 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] 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]