[00:06] <rsalveti> tvoss_: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863
[00:12] <robert_ancell> RAOF, do you know about mlankhorst's changed in -staging?
[00:12] <RAOF> robert_ancell: I do not.
[00:12]  * RAOF checks
[00:12] <robert_ancell> RAOF, so he overwrote -0ubuntu9 for some reason. But others have said his changes fix a crash
[00:13] <RAOF> I did tell him about your bug, and he seemed to have an idea of what was happening.
[00:13] <robert_ancell> So not sure why they don't just go directly to main?
[00:13] <kdub> rsalveti, speaking of our libhybris dependency :)
[00:14] <robert_ancell> RAOF, I was looking at the Mir patch by the way. I notice it unloads drivers if they don't work with Mir, but doesn't check if the driver count is 0 afterwards. My logs do show three drivers being unloaded
[00:14] <kdub> we keep hwcomposer.h in-tree... if libhybris maintained hwcomposer.h (like it does with gralloc.h), it would help mir's dependency situation
[00:14] <kdub> just a 'wishlist' though
[00:15] <rsalveti> kdub: sure, mind opening a bug against the libhybris package?
[00:15] <kdub> sure
[00:15] <rsalveti> also, if someone can help me understand such failures: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863
[00:15] <rsalveti> any idea why we don't have an armhf jenkins build job as well?
[00:15] <rsalveti> just building for i386 and amd64
[00:16] <rsalveti> or is it trying to cross build for armhf?
[00:17] <kdub> rsalveti, yep
[00:17] <rsalveti> right, then we might need some other changes as well...
[00:17] <rsalveti> -- Could NOT find LIBHARDWARE (missing:  LIBHARDWARE_LIBRARY)
[00:17] <rsalveti> when cross building
[00:18] <rsalveti> package wasn't even installed
[00:18] <kdub> there's a script in the top level directory (+ ./cross-compile-chroot.sh) that the builder is executing
[00:18] <kdub> you can change the script if need be, but really its probably an issue of getting cmake to sort things out correctly
[00:19] <rsalveti> right, it's only installing libhybris and libhybris-dev
[00:19] <rsalveti> not necessarily all the dependencies
[00:19] <rsalveti> let me check the script
[00:19] <rsalveti> https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/462/console also failed
[00:20] <rsalveti> but seems related with the test results
[00:20] <rsalveti> not related with my change
[00:20] <robert_ancell> kdub, does https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 make sense?
[00:20] <rsalveti> you shouldn't build-dep on libhybris-egl
[00:20] <rsalveti> that's provided by mesa
[00:21] <rsalveti> and you just need to install libhybris during runtime, as that will replace mesa's egl
[00:21] <kdub> right, we shouldnt care at buildtime whether its the hybris or mesa
[00:22] <robert_ancell> rsalveti, did you want a specific review from tvoss_ instead of just the mir team?
[00:22] <rsalveti> no, just added him there because he asked me to
[00:23] <robert_ancell> ok, kdubs review should be sufficient to land
[00:25] <rsalveti> kdub: ok, changed the cross build script, will wait to see if that helps
[00:26] <kdub> rsalveti, i reviewed with a +1, conditional on getting it past the builder
[00:27] <rsalveti> kdub: any idea why it failed for amd64 though?
[00:28] <kdub> rsalveti, no, that is a strange failure :/
[00:31] <kgunn> robert_ancell: not that you needed another data point....but using staging xorg worked for me (+mir from main, +usc from daily-build)
[00:32] <robert_ancell> RAOF, any update on that patch from mlankhorst?
[00:32] <RAOF> robert_ancell: I'm hunting it down; it doesn't seem like he pushed that to git.
[00:38] <RAOF> Ah, there it is.
[00:40] <kgunn> RAOF: quick one...what did "mesa dependent on some radeon kernel patches" mean ? or how does it relate ?
[00:44] <RAOF> kgunn: To be proper, the radeon mesa module needs to know the size of the buffer its importing; for dma-buf there's currently no way to get that, so I made a kernel patch.
[00:45] <robert_ancell> kdub, rsalveti, so it looks like those memcheck failures are happening elsewhere https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/463/console
[00:45] <RAOF> kgunn: We're doing sufficiently simple things that this shouldn't be a problem, but for upstream acceptance the general case is important :)
[00:49] <rsalveti> robert_ancell: yeah, they are not related with packaging changes for arm :-)
[00:50] <kdub> hmm
[01:15] <RAOF> Ah. *There* we go. This laptop *does* have fans.
[01:32] <RAOF> robert_ancell: New Xserver tested, fixes your bug, and uploaded.
[01:32] <robert_ancell> RAOF, nice!
[01:33] <RAOF> And with that, I think I'm no longer firefighing?
[01:33] <RAOF> Maybe I can get some actual feature work done!
[01:33] <RAOF> duflu: Good morning!
[01:33] <duflu> RAOF: Morning!
[01:33]  * duflu reserves judgement over good, for a while
[01:34] <RAOF> Heh. How's Perth travelling?
[01:34] <duflu> RAOF: It's basically spring. Been very warm lately
[01:35] <duflu> RAOF: Laptop in action yet?
[01:35] <RAOF> It is indeed.
[01:37] <robert_ancell> duflu, can I get you to re-review https://code.launchpad.net/~robert-ancell/mir/alt-ctrl-backspace/+merge/178036?
[01:37] <duflu> robert_ancell: Yes, can it wait for me to plough through email etc first?
[01:37] <robert_ancell> duflu, sure
[01:41] <RAOF> duflu: I'd still like to line up a bypass discussion at some point, too :)
[01:42] <duflu> RAOF: I know. But I have significant "switch" issues to address first. It won't go away :/
[01:42] <RAOF> duflu: ok.
[01:42] <RAOF> There's plenty of xrandr to do :)
[01:42] <duflu> RAOF: So don't expect today
[02:07] <rsalveti> RAOF: did you like your new laptop? thinking about getting a similar one in a month
[02:08] <RAOF> rsalveti: It's pretty nice.
[02:09] <RAOF> It's particularly nice to have the system76 guys in the community - I'm half-way through setting up secure boot on this machine thanks to an out-of-band firmware update I got because I mentioned that I wanted to securebootify it.
[02:09] <duflu> OK, I have now broken my VTs. Can't switch to any
[02:09] <rsalveti> RAOF: yeah, that's nice, cool
[02:10] <rsalveti> most reviews are saying good things about it as well, looking forward to move from my thinkpad t400 :-)
[02:10] <rsalveti> 4 years old already
[02:10] <RAOF> It's pleasantly light, and reasonably constructed.
[02:10] <rsalveti> nice
[02:11] <rsalveti> RAOF: running xmir on it already?
[02:11] <RAOF> It's not quite at the build quality of my old x200s, but it's a cut above the old asus I had.
[02:11] <RAOF> rsalveti: Not right at the moment; I like my VTs :)
[02:11] <rsalveti> RAOF: haha, right :-)
[02:12] <RAOF> It's easier to test in mir_demo_server_shell, anyway.
[02:12] <RAOF> You don't have to blow away your existing session to test there :)
[02:12] <rsalveti> right, indeed
[02:13] <RAOF> The laptop is also nice and quiet. Idle I don't think the fans are on at all, and under moderate load they pick up to fairly quiet.
[02:15] <rsalveti> awesome
[02:15] <rsalveti> can't wait to get one as well
[02:18] <duflu> Has anyone else noticed Mir servers crash when new clients start? Seems to be a new regression on trunk landing last night
[02:18]  * duflu is trying to trace the problem without breaking his machines
[02:21] <duflu> Rolling back to yesterday's branches work at least
[02:54] <RAOF> Dear lord. Why doesn't bzr ship with bzr-pager?
[02:55] <smspillaz> RAOF: hmm, never heard of it. What does it do?
[02:55] <RAOF> smspillaz: Pipes everything bzr outputs through a pager.
[02:55] <smspillaz> oh, I guess it automatically pipes to less
[02:55] <RAOF> ie: git's default mode.
[02:55] <smspillaz> heh
[02:55] <RAOF> This is one of the rare cases where git's default is substantially saner than bzr's.
[02:56] <smspillaz> RAOF: I dunno, I think the git branching model is saner than having to muck around with lightweight checkouts :)
[02:56] <smspillaz> though I was very happy when I found out about lightweight checkouts
[02:56] <smspillaz> unfortunately it was only after I had run out of disk space N times already
[02:57] <RAOF> I don't bother with lightweight checkouts. A repository works fine.
[02:57] <smspillaz> RAOF: repository?
[02:57] <RAOF> Now, *this* is something bzr does terribly.
[02:57] <RAOF> bzr init-repo .; will turn the current directory into a repository.
[02:58] <smspillaz> RAOF: I don't see how that's different from bzr branch' default behaviour
[02:58] <RAOF> Anything you branch into that directory will share the repository.
[02:58] <RAOF> So you've got one copy of history + n-checkouts.
[02:58] <RAOF> If your checkouts are what's pushing you over the space size, you've got problems :)
[02:59] <smspillaz> RAOF: I used to always do bzr branch lp:foo foo.whatever and then have a million foo.* drs
[03:00] <smspillaz> *dirs
[03:00] <smspillaz> each with their own build/
[03:00] <RAOF> Yeah, jml wrote a plugin to identify and remove those branches which had been merged.
[03:00] <smspillaz> when you consider that a unity build got to about 3GB, it got big quick
[03:00] <smspillaz> RAOF: yeah, I never was able to find that, but I have heard that such a thing existed
[03:01] <smspillaz> in any case, git's behaviour in that area is much *much* nicer :)
[03:02] <RAOF> lp:bzr-removable
[03:02]  * duflu has wacky graphics corruption and can't see what he's typing. brb
[03:02] <RAOF> Woot!
[03:04] <smspillaz> duflu: you do a much better job at spelling correctly when you can't see what you're typing than me :)
[03:04]  * smspillaz could never see what he was typing whenever using irssiconnectbot or whatever on android, hence all the spelling mistakes generally
[03:10] <duflu> smspillaz: Well, that time I was looking at the keyboard
[03:10] <smspillaz> heh
[03:10] <robert_ancell> RAOF, I still have the X lockup, investigating more here
[03:10] <duflu> It seems a Mir (heap corruption?) bug hit me in the middle of libgbm, which then corrupted X too
[03:10] <RAOF> Huh. It fixed it here, damnit!
[03:10] <robert_ancell> RAOF, I didn't think you'd reproduced it had you?
[03:10] <RAOF> robert_ancell: You've got 0ubuntu9, from the archive?
[03:10] <robert_ancell> RAOF, yes
[03:11] <RAOF> robert_ancell: I managed to reproduce it on my hybrid system.
[03:16] <robert_ancell> RAOF, what was the cause for you?
[03:16] <RAOF> Spinning in deletedriver, because radeon was marked for deletion but wasn't getting deleted
[03:17] <racarr> Back for the night shift
[03:21] <duflu> robert_ancell: Not sure if you want to wait for someone to do a proper fix, but this is rather critical... https://code.launchpad.net/~vanvugt/mir/revert-r931/+merge/178877
[03:22] <robert_ancell> duflu, I'm looking at it now. We should revert if it's causing problems.
[03:22] <robert_ancell> duflu, can you note in the bug what you're doing to confirm it?
[03:22] <robert_ancell> I assume this is mir_demo_server and mir_demo_client_*?
[03:23] <RAOF> Huh. I tested that commit with mir_demo_server_shell and xmir.
[03:23] <RAOF> Presumably I should also have done so with a native Mir client :)
[03:24] <duflu> robert_ancell: Yes, I added a comment
[03:24] <duflu> It would be nice to figure out how that got past all automated testing...
[03:28] <RAOF> Ok, I can reproduce the crash with mir_demo_client_eglplasma.
[03:28] <robert_ancell> duflu, did the whole video system lock up when testing the client?
[03:29] <duflu> robert_ancell: It killed the Mir server, which does turn off the display. You need to switch to X to restore the state correctly (Ctrl+Alt+F7)
[03:30] <duflu> robert_ancell: There's a separate bug for that :)
[03:30]  * RAOF +1s the revert, then heads to lunch.
[03:31] <robert_ancell> duflu, I'll just confirm your branch fixes it, then +1 from me too
[03:36] <robert_ancell> argh. Stupid cmake
[03:36] <robert_ancell> duflu, don't block on me
[03:37] <duflu> robert_ancell: I will. I already blocked the morning for this :S
[03:39] <duflu> Damn. I'm involved in too many reviews again
[03:48] <robert_ancell> RAOF - https://code.launchpad.net/~mir-team/mir/expose-debug-buffer-id-to-client/+merge/176843 would break ABI/API
[03:52] <duflu> robert_ancell: I will defer testing ctrl+alt+backspace till the regression is fixed. So I can test properly
[04:01] <robert_ancell> rsalveti, have some associated packaging changes broken android builds? https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1622/console
[04:07] <robert_ancell> duflu, hoping that android build failure is going to disappear?
[04:18] <robert_ancell> RAOF, is there a reason you compact the driver list on deletion?
[04:21] <duflu> robert_ancell: Yes hoping one way or the other
[04:26] <tvoss_> good morning :)
[04:27] <robert_ancell> RAOF, ah, so turned out I had the -0ubuntu9 from yesterday. The new -0ubuntu9 from main does fix the problem for me
[04:30] <robert_ancell> bbl
[04:41] <sam113101> HELLO
[04:41] <sam113101> I want to know what's the equivalent of a window manager (in the X world) with mir? is it the compositor?
[04:42] <sam113101> the thing that draws the window borders, offers special effects, etc.
[04:45] <duflu> sam113101: It's the "shell". And as yet there is no shell that does any window management really. But we're slowly building a demo in examples/demo-shell/. And later it will be done in the Unity8 project's shell.
[04:45] <duflu> All you can do with demo-shell is Alt-Tab and move windows around (Alt+drag or three fingers)
[04:45]  * duflu goes to lunch
[04:56] <sam113101> I don't know what's a shell, it's kind of confusing (at least to me)
[05:13] <RAOF> sam113101: Yes. The compositor is the equivalent of a window manager; same as wayland.
[05:14] <sam113101> RAOF: what's a shell, then?
[05:14] <RAOF> sam113101: Think "desktop environment".
[05:14] <RAOF> sam113101: It's the bit of the compositor that is the desktop environment.
[05:16] <tvoss_> good morning again :)
[05:17] <RAOF> Heeelo.
[05:18] <sam113101> the shell is part of the compositor?
[05:18] <RAOF> Yes
[05:18] <robert_ancell> duflu, I think we have to land https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 first to fix the android build errors
[05:18] <sam113101> you're sure it's not the opposite?
[05:19] <robert_ancell> sam113101, the shell *is* a compositor
[05:19] <RAOF> Is a display server.
[05:19] <robert_ancell> there's no special component called a compositor. There can be a number of compositors
[05:20] <RAOF> Everything is rolled into one - display server, compositor, shell, window manager.
[05:24] <alf__> RAOF: Does X/XRandR handle rotation internally? That is, for XMir does Mir need to provide some kind of rotation option when configuring the display?
[05:25] <RAOF> It would be better if it did; let me check.
[05:25] <sam113101> robert_ancell: there can be multiple compositors?
[05:26] <robert_ancell> sam113101, yes, in the Ubuntu case we have Unity Shell as one compositor and Unity System Compositor switching between shells
[05:27] <RAOF> alf__: I'd be better to handle it in Mir, but it's currently handled in the drivers.
[05:28] <RAOF> alf__: So if it's hard for Mir to expose that, XMir can do that work.
[05:29] <sam113101> is there a mir server a compositor talks to or is the compositor the server itself?
[05:30] <smspillaz> sam113101: like wayland compositors, the clients connect to it directly
[05:30] <RAOF> sam113101: The compositor is the server itself. Everything is in the one place; display server, compositor, shell, window manager.
[05:30] <RAOF> Just like wayland.
[05:32] <duflu> sam113101: I think you're used to the X/Compiz/WM way of doing (and naming) things. Mir is more like Gnome Shell, Windows or OSX in that the whole UI (shell) is one thing. And that thing does composition, window management, etc.
[05:32] <sam113101> yeah I'm used to the old scenario
[05:32] <alf__> RAOF: For now (due to time constraints), I'd rather if XMir handled it, if it is something that is ready.
[05:33] <alf__> RAOF: What would X require from Mir in terms of rotation?
[05:34] <sam113101> so there are only two things, a compositor (which uses the mir library) and clients (which also use the mir library to talk to the compositor), is that right?
[05:35] <RAOF> alf__: Ideally it would take the buffer from XMir and rotate it during the composition phase based on what XMir asked.
[05:35] <duflu> alf__: I was thinking about that. Rotation requires (1) Screen transformation, (2) Cursor transformation, (3) surface resize support as width becomes height etc
[05:35] <RAOF> alf__: So XMir could set RotateClockwise90 on it's 1920x1080 window, and Mir would take the 1920x1080 buffer and rotate it through 90 degrees when compositing to the framebuffer
[05:36] <duflu> ... in other words, Mir is not ready for that. Let XMir do it :)
[05:38] <duflu> I suspect (3) resize support is the major blocker. That's probably quite non-trivial
[05:38] <alf__> duflu: RAOF: right, at the same time the contents need to be transformed accordingly, e.g., X needs to know that this is now a 1080x1920 surface and draw accordingly, so XMir should be involved at some point?
[05:38] <sam113101> I think I'm going to write my own compositor some day, if I ever get knowledgeable enough
[05:38] <duflu> sam113101: We aim to provide examples that help people to do that. Just need time to make the examples more interesting
[05:39] <sam113101> alright
[05:39] <duflu> sam113101: You could start now by copying examples/demo-shell/ but the API is likely to change somewhat still
[05:40] <tvoss_> RAOF, ping
[05:40] <RAOF> tvoss_: Pong
[05:41] <RAOF> alf__: No, X wants it to be a 1920x1080 surface always.
[05:42] <alf__> RAOF: But in terms of content drawing it will treat it as a 1080x1920 surface, right?
[05:45] <RAOF> I think the answer to that is "no"
[05:45] <RAOF> But I need to trace further
[05:46] <alf__> RAOF: in any case... we need to find out what more, if anything, XMir needs from Mir to support screen rotation
[05:47] <RAOF> Yes
[05:48] <alf__> RAOF: I would imagine that since XRandR uses KMS normally, that it can handle everything internally, and that Mir (for now) can just replace the functionality that KMS provides
[05:48] <alf__> RAOF: so no rotations/transformations
[05:48] <RAOF> Yeah.
[06:01] <duflu> Ugg. My audio settings are broken again. Need to reboot to hangout
[06:03] <kgunn> thomi: psychedelic !
[06:03] <thomi> kgunn: I know, but watch this!
[06:05] <kgunn> robert_ancell: weekly ?
[06:06] <robert_ancell> kgunn, yes...
[06:34] <thomi> ugh, hangout is broken all of a sudden
[06:35] <thomi> hmm, can't log back in
[06:37] <tvoss|test> hmmm, unity-system-compositor does not compile for me, failing with /usr/include/mirserver/mir/default_server_configuration.h:23:40: fatal error: mir/options/program_option.h: No such file or directory
[06:37] <tvoss|test>  #include "mir/options/program_option.h"
[06:39] <tvoss|test> looking into my include files, that include file is indeed missing
[06:41] <robert_ancell> thomi, :(
[06:42] <robert_ancell> thomi, it's coming up to your turn
[06:48] <didrocks> tvoss|test: I confirm: https://launchpadlibrarian.net/146957401/buildlog_ubuntu-saucy-amd64.unity-system-compositor_0.0.1%2B13.10.20130807-0ubuntu1_FAILEDTOBUILD.txt.gz
[06:49] <tvoss|test> robert_ancell, ^
[06:49] <racarr> I am too tired to talk constructively about surface-configuration-interface/client-focus I think
[06:49] <robert_ancell> tvoss|test, hrm. Looks like someone changed the API
[06:50] <robert_ancell> racarr, :( Get some sleep!
[06:50] <racarr> but would appreciate if people could try and think about them, and say...not tomorrow, but the next morning
[06:50] <racarr> I will make it an extra early morning day and can sync up with everyone
[06:50] <alf__> robert_ancell: Looking at your branch... I think I have a less intrusive way to do this (e.g. not needing to set the server explicitly)
[06:50] <racarr> :)
[06:50] <kgunn> robert_ancell: i'll let you decide ultimately....but if you're sway-able...i'd say update ppa asap since we;re still struggling ^
[06:50] <tvoss|test> robert_ancell, it's not even that, the include file mentioned in default_server_configuration does not exist anymore
[06:50] <robert_ancell> alf__, ok, please propose an alternative. We just need to get something landed
[06:50] <alf__> robert_ancell: ok
[06:51] <racarr> robert_ancell: My pleasure :D
[06:51] <robert_ancell> kgunn, Do you think being unable to VT switch is a blocker?
[06:51] <robert_ancell> I'm otherwise happy to update
[06:51] <kgunn> robert_ancell: not a blocker imho
[06:51] <robert_ancell> ok, will do
[06:51] <kgunn> just a bug :)
[06:51] <robert_ancell> and I'll point the complaints to you :)
[06:52] <kgunn> certainly
[06:52]  * kgunn goes to bed
[06:53] <didrocks> tvoss|test: another day without u-s-c to distro I think :/
[06:53] <robert_ancell> alf__, I'm about to EOD - lp:~robert-ancell/mir/vt-switch-keys is the VT switching branch (not working). If you want to fix/change that feel free
[06:55] <alf__> robert_ancell: Do we want both quit and vt to live only in examples? Will u-s-c do its own thing separately?
[06:55] <robert_ancell> RAOF, can you upload the recent X to the staging PPA so I can copy it to the s-c-t PPA?
[06:55] <RAOF> robert_ancell: Is there any particular... oh, yeah. Pinning.
[06:55] <robert_ancell> alf__, the VT switching is in DefaultServerConfiguration, the alt+ctrl+backspace just in DemoServerConfiguration
[06:55] <robert_ancell> RAOF, yep
[06:56] <alf__> robert_ancell: ok
[06:56] <RAOF> Oh, I think it'll be rejected because it's not newer than the archive?
[06:56] <RAOF> Let's find out!
[06:56] <robert_ancell> alf__, I think that makes sense. It was kind of yuck to have the VT switching code separate from the GBM code, but I couldn't think of a way around it
[06:56] <robert_ancell> RAOF, because of the obsolete -0ubuntu9?
[06:57] <RAOF> robert_ancell: Yeah.
[06:57] <RAOF> Other option is to delete the X server in s-c-t?
[06:57] <RAOF> Then it'll drop out of pinning and they'll get the archive version.
[06:57] <robert_ancell> RAOF, yeah, that might work
[06:59] <robert_ancell> RAOF, we can drop xserver-xorg-video-* as well right?
[06:59] <RAOF> robert_ancell: Yes
[06:59] <robert_ancell> and libdrm and mesa?
[06:59] <tvoss|test> robert_ancell, RAOF announcing that by mail might be a good idea. How can we test before removing it?
[06:59] <RAOF> Yes.
[07:02] <RAOF> alf__: Oh, another thing that Mir doesn't provide on the monitor-configuration front? Names for the outputs.
[07:02] <RAOF> alf__: There's no way to distinguish between HDMI-1 and VGA-1 and…
[07:09] <RAOF> alf__: It doesn't need to be a string; you could also send an enum. But we do need some way to tell.
[07:16] <alf__> RAOF: ok
[07:21] <duflu> RAOF/alf__: I too vote for names/numbers/anything.
[07:22] <duflu> Hmm, no wonder X is always confused. Xrandr says VGA is active even when the monitor is physically turned off
[07:22] <alf__> duflu: RAOF: sure, probably both an enum with the type VGA/HDMI etc, and a unique name
[07:23] <duflu> alf__: Also, in the absence of GUI's it would be awesome to be able to say "VGA1 rightof DVI1 align top" or similar
[07:24] <duflu> alf__: I'd be happy to do such a text interface providing arbitrary placement is functional
[07:24] <duflu> But obviously we have higher priorities right now...
[07:28] <didrocks> kgunn: tvoss|test: FYI, I disable u-s-c tests and run for now
[07:29] <didrocks> kgunn: tvoss|test: apparently, nobody is working on debugging it, and that's what which is screwing the -ati machine everyday
[07:29] <duflu> Another option which doesn't even need names is to have special key combos which move the current monitor (with the cursor) relative to others
[07:29] <didrocks> kgunn: tvoss|test: like nothing else is running after that when starting the session, I think the ati driver state isn't right then and we have to reboot it
[07:30] <didrocks> jibel: FYI ^ let's do that
[07:31] <didrocks> Mirv: so don't bother with mirslaves for now, as per ^
[07:32] <didrocks> good to have a least a start of explanation why we got the -ati machine screwed everyday
[07:34] <Mirv> didrocks: yeah I didn't already because you told me so on Monday
[07:37] <RAOF> duflu: The DDC pins provide power for the EDID firmware; it's not possible to distinguish between an unpowered monitor connected to a VGA port and a fully armed and operation monitor plugged in to a VGA port.
[07:38] <duflu> RAOF: OK, makes sense if your OS handles multi-monitor more reliably than this one :/
[07:39] <duflu> But it will be super-psychic-always-right in Mir :)
[07:39] <RAOF> Not really. It never really makes sense.
[07:39] <RAOF> Fortunately, you *can* tell if a DisplayPort monitor is turned off, and it's also possible to detect some HDMI (but I'm not sure whether we do at the moment)
[07:40] <RAOF> So once everyone's thrown away their current hardware this problem will go away!
[07:40] <duflu> RAOF: Hmm, I will need a system with multiple digital outs and at least one new monitor first
[07:41] <duflu> Wait, no. Just the former.
[07:55] <dholbach> good morning
[08:03] <tvoss|flaky> alan_g, ping
[08:03] <alan_g> tvoss|flaky: ?
[08:04] <tvoss|flaky> alan_g, good morning. your recent refactoring to the platform stuff breaks compiling unity-system-compositor as the options-headers are not installed
[08:05] <alan_g> tvoss|flaky: https://code.launchpad.net/~robert-ancell/mir/mirplatform/+merge/178895
[08:07] <tvoss|flaky> alan_g, does not pass CI due to the install directory directive not being correct
[08:07] <tvoss|flaky> alan_g, do you have cycles available to take care of landing it?
[08:08] <alan_g> tvoss|flaky: will do
[08:08] <tvoss|flaky> alan_g, thx
[08:32] <alan_g> tvoss_:  https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
[08:41] <alan_g> alf__: any chance of a quick top-approve for https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
[08:43] <alf__> alan_g: looking
[08:51] <alf__> alan_g: are the headers included in some package?
[08:53] <alan_g> alf__: Good point
[09:31] <alan_g> tvoss_:  https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
[09:37] <RAOF> alf__: Oh, and could we also grab the EDID?
[09:39] <alf__> RAOF: I guess so, why do you need it?
[09:39] <RAOF> Clients sometimes care about it.
[09:40] <RAOF> You can grab useful information from it, like the name of the display etc.
[09:43] <RAOF> Oh, and subpixel layout; likewise, clients can use it.
[09:43] <alf__> RAOF: how does xrandr get edid now? Does KMS provide it, or does it grab it from /sys?
[09:43] <RAOF> kms provides it.
[09:43] <alf__> RAOF: can you point me to the function?
[09:44] <tvoss_> alan_g, looking
[09:45] <alf__> RAOF: is it a "property blob"?
[09:45] <RAOF> alf__: extern drmModePropertyBlobPtr drmModeGetPropertyBlob(int fd, uint32_t blob_id); with blob_id ==... yeah
[09:45] <RAOF> You need to grab the properties, iterate over them finding which one has name == "EDID", and then that's the blob to get.
[09:45] <alf__> RAOF: thanks
[09:46] <alf__> RAOF: ok, so to sum up: subpixel, edid, unique name
[09:47] <RAOF> These are the things I've hit so far, yes :)
[09:47] <RAOF> I think they cover the main bases.
[09:50] <tvoss_> alan_g, building mir now, and usc subsequently
[09:50] <tvoss_> katie, ping
[09:50] <katie> tvoss_, ping pong
[09:50] <alan_g> tvoss_: thanks
[10:05] <RAOF> alf__: Whoops! subpixel, edid, type/name, *and* the number of independent outputs that can be driven.
[10:06] <alf__> RAOF: ok
[10:06] <alf__> RAOF: How blocking are these? Any preference about order of implementation?
[10:07] <RAOF> I don't think any are totally blocking. count_crtcs would be my first preference, then EDID, then type/name, then subpixel.
[10:09] <RAOF> Of those, if we shipped without subpixel it wouldn't be terrible. We *could* ship without EDID, it just makes my life easier. The type & count_crtcs are absolutely mandatory.
[10:12] <alf__> RAOF: we will ship with all, mostly caring if any of these is blocking you in the short term
[10:12] <alf__> duflu: FYI, https://code.launchpad.net/~afrantzis/mir/gbm-alloc-validate-buffer-format/+merge/178928
[10:12] <duflu> alf__: Yeah saw it
[10:45] <RAOF> Hah! alf__ - is the modes array sorted at all? If not, is there a way of getting the output's preferred mode?
[11:00] <alan_g> tvoss_: does it work for you?
[11:00] <tvoss_> alan_g, still compiling. had some hiccups as I have libhybris installed
[11:11] <tvoss_> alan_g, compilation works fine here
[11:11] <tvoss_> alan_g, approved :) alf__ would you mind taking a second look and top-approving?
[11:11] <alan_g> tvoss_: great.
[11:11] <tvoss_> alan_g, I haven't tried usc, though
[11:13] <alan_g> tvoss_: but it builds?
[11:13] <tvoss_> alan_g, ack
[11:13] <alan_g> good enough for me
[11:27] <alf__> RAOF: The modes are as KMS gives them back, so sorted from higher to lower resolutions. I haven't come across a situation where the preferred mode is not the first (but of course I haven't had the chance to try with a lot of outputs)
[11:28] <alf__> tvoss_: which MP is that?
[11:28] <tvoss_> alf__, https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909
[11:29] <alf__> tvoss_: alan_g: top approved
[11:34] <tvoss_> alf__, \o/
[11:36] <RAOF> alf__: Probably time to add preferred-mode to that to the list, then ☺ (or, at least, ensure preferred mode is the first in the array). I'm pretty sure CRTs will have a highest-resolution mode that's non-preferred.
[11:37] <alf__> RAOF: ok
[11:38] <alf__> RAOF: the list grows :) but thankfully all are simple additions
[11:38] <RAOF> And now, sleep.
[12:28] <greyback> alf__: hey, could I maybe add this bug to your list of things to do: https://bugs.launchpad.net/mir/+bug/1209216 - or please comment if I'm not using the API correctly
[12:29] <alf__> greyback: will take a look
[12:30] <tvoss_> didrocks, ping
[12:30] <didrocks> tvoss_: pong
[12:30] <greyback> alf__: if you'd like more info in that bug, do say. It is very textual :)
[12:30] <alf__> greyback: could you point me to the code where the code is used
[12:30] <alf__> ?
[12:31] <tvoss_> didrocks, staging has got a new version of mir that has got all the headers installed
[12:31] <tvoss_> didrocks, tested locally, can build usc against it
[12:32] <greyback> alf__: http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/modules/Unity/ApplicationManager/applicationscreenshotprovider.cpp#L46
[12:32] <didrocks> tvoss_: ok, let me retry manually then, hoping that it won't screw up the ati machine again
[12:32] <didrocks> first, building mir
[12:32] <tvoss_> didrocks, ack
[12:35] <alf__> greyback: I can't think a way for Mir to be getting this wrong (not that it's not possible0. Could the non-fullscreen surface be really implemented as a fullscreen surface with transparency on the top?
[12:35] <greyback> alf__: hmm, that's a possibility. Let me look
[12:43] <didrocks> tvoss_: cmake isn't available on all archs yet, it will take a little bit more time for armhf
[12:43] <tvoss_> didrocks, cmake as in? sorry, ENOCONTEXT :)
[12:44] <didrocks> tvoss_: cmake made Mir FTBFS (a new upload, arch mismatchs)
[12:44] <didrocks> I'll retry Mir once cmake is published on armhf
[12:44] <tvoss_> didrocks, okay
[12:45] <alf__> greyback: btw, in the code I see that you are mirroring the image. Note, that I am mirroring too internally when transforming from texture (bottom-up) to byte data (top-down). Perhaps we can avoid both mirrorings.
[12:46] <greyback> alf__: yes that would make sense
[12:52] <greyback> alf__: you are correct, it appears every qtubuntu surface is actually fullscreen. It is using platform-api to move & resize the surface, but those a stubs. Qt itself I believe is drawing the white padding
[13:23] <doko> didrocks, shouldn't happen anymore with the loosened dependency
[13:24] <didrocks> doko: yeah, I hope so :) just retried armhf
[13:49] <tvoss> didrocks, ping
[13:49] <tvoss> alf__, alan_g what is the review status on duflu's switch branch?
[13:50] <alan_g> tvoss: I started looking at it a couple of days ago. Then it went to WIP. I see it is now back again.
[13:50] <didrocks> tvoss: pong
[13:51] <alan_g> tvoss: It is a LOT of change to get one's head around and validate.
[13:59] <tvoss> alan_g, I know, it still fixes the lag issue, though
[14:00] <alf__> tvoss: alan_g: I haven't validated every line (nor I plan to), but it seems to work reasonably well last I checked. It effectively triple-buffers all the time, though, and what concerns me is that attempts to enforce double-buffering haven't been successful yet, which may indicate a more fundamental algorithmic issue. I am OK with getting this in without the enforced double-buffering, but we need to fix it soon, if only to prove that it is doa
[14:02] <tvoss> alf__, ack
[14:14] <kgunn> didrocks: ping
[14:14] <didrocks> kgunn: pong
[14:14] <kgunn> didrocks: hey read the scrollback...checked mails, so it seems the ati machine is the last hurdle ?
[14:15] <didrocks> kgunn: hum, ati and intel
[14:15] <didrocks> kgunn: the other issues isn't confirmed to be fixed AFAIK
[14:15] <didrocks> (like no GL)
[14:15] <didrocks> the additional input is that we have confirmation that it's that failing state which makes the ati machine irresponsive then
[14:15] <didrocks> and we have to electrically reboot it
[14:17] <kgunn> didrocks: i apologize for my questioning...just trying to help :)...but "other issues isn't comfirmed to be fixed" you are referring to intel xorg seq fault ?
[14:18] <didrocks> kgunn: right, it was intel/ati (the symptoms looked the same), was that worked on? I didn't see any change on the bug I referred
[14:19] <kgunn> didrocks: for sure intel "has a fix"....me, tvoss, bschafer all verified a fix
[14:20] <kgunn> the magic combo was main-mir, xorg-staging, u-s-c-daily-build
[14:20] <didrocks> kgunn: when was it committed? today?
[14:20] <kgunn> didrocks: actually, that's what i have a difficult time with...backtracking code changes to xorg (lp so much easier in that regard :)
[14:20] <tvoss> didrocks, it was working yesterday
[14:21] <didrocks> ok, but then, we had the FTBFS on u-s-c
[14:21] <tvoss> didrocks, is libhybris installed on the testing machine?
[14:21] <didrocks> tvoss: I don't think so
[14:21] <didrocks> let me confirm
[14:21] <tvoss> didrocks, yeah, if that is the case, usc won't come up
[14:22] <didrocks> tvoss: it wasn't installed
[14:22] <tvoss> didrocks, okay, what is the usc log? or better: does it come up?
[14:24] <didrocks> " More annoying, on both the intel and ati machines we currently use for testing (and no nvidia plugged in by QA yet :/), latest Mir with u-s-c hangs on boot. I can clearly see compiz hanging on the opengl driver loading. If I DISPLAY=:0 /usr/lib/nux/unity_support_test -p, it hangs forever (but not sure if this should work in the Mir world)."
[14:24] <didrocks> tvoss: what I wrote on Monday in my email ^
[14:24] <didrocks> tvoss: if needed, can rebuild (now that it builds, right?) latest u-s-c and put you on the machine
[14:32] <tvoss> didrocks, unity_support_test should work ... but that's not on boot, right?
[14:32] <didrocks> tvoss: it's run by unity on boot (but I guess not on the Mir case anymore)
[14:32] <didrocks> tvoss: let see, I'm retrying a build of u-s-c now
[14:33] <tvoss> didrocks, yeah, give that a spin please
[14:33] <tvoss> didrocks, the new xserver fixed a bunch of spin issues, too
[14:33] <didrocks> tvoss: ok, we have it (but not latest -ati driver from midday)
[14:36] <tvoss> didrocks, okay
[14:37] <tvoss> didrocks, to clarify: what are you doing now?
[14:37] <didrocks> tvoss: rebuild u-s-c now that it shouldn't FTBFS and the tests will run again on both -ati and -intel
[14:37] <didrocks> with latest snapshot of distro (taken at 9am UTC)
[14:37] <tvoss> didrocks, thx
[14:43] <mattld> tvoss: I have an easy question you could answer. Is xmir a fork of xwayland?
[14:44] <tvoss> mattld, no, although it naturally takes a very similar approach
[14:47] <mattld> tvoss: Thanks for the answer. I will use this to combat Reddit FUD.
[14:48] <tvoss> mattld, thanks :)
[14:49] <mattld> tvoss: Have an awesome day!
[14:50] <tvoss> mattld, thank you, to you too! Let me know if you need any further information
[15:03] <didrocks> tvoss: kgunn: intel passed now, ati is still stuck
[15:03] <didrocks> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-ati/808/console
[15:06] <kgunn> didrocks: so ati boots fine, just gets stuck on AP testing ?
[15:06] <didrocks> kgunn: yeah, as you can see unity doesn't start
[15:07] <didrocks> kgunn: compiz seems to hang on the opengl compiz init
[15:07]  * kgunn looking at it right now
[15:09] <kgunn> didrocks: so can we grab the /var/log/Xorg*'s
[15:09] <didrocks> kgunn: doing right now
[15:11] <didrocks> kgunn: Xorg.0.log: http://paste.ubuntu.com/5959227/
[15:11] <didrocks> unity-system-compositor.log contains:
[15:11] <didrocks> dm_connection_start
[15:11] <didrocks> set_active_session '0'
[15:11] <didrocks> set_active_session
[15:11] <didrocks> and it's running
[15:11] <didrocks> compiz is running as well
[15:12] <didrocks> (but no plugin loaded after opengl as you can see)
[15:13] <didrocks> kgunn: I'm closing the container so that you can download the tar
[15:31] <jibel> kgunn, tvoss for what it's worth, here is the kernel trace when we try to restart an X session after running mirslave tests on radeon http://paste.ubuntu.com/5959277/
[15:32] <kgunn> jibel: thanks...altho, a subsequent symptom of something nasty previous i think
[15:32] <jibel> yes
[15:34] <tvoss> mlankhorst, something for your interest :) http://paste.ubuntu.com/5959277/
[15:36] <mlankhorst> tvoss: try again with PROVE_LOCKING :p
[15:53] <tvoss> mlankhorst, is that really an env var?
[16:01] <kgunn> bschaefer: we're back to ati hell
[16:02] <bschaefer> kgunn, o no...
[16:02] <mlankhorst> tvoss: no, it's a kernel option
[16:02] <bschaefer> whats going on with ati?
[16:02] <tvoss> mlankhorst, argh ...
[16:03] <kgunn> bschaefer: so didrocks ati machine locks to the point of requiring hard reboot
[16:03] <tvoss> mlankhorst, any gut feeling what kind of issue we are hitting?
[16:03] <mlankhorst> it's quite obvious from the backtrace ;P
[16:03] <bschaefer> kgunn, hmm thats not good...is there a bug out for it yet?
[16:04] <kgunn> bschaefer: nope...i think didrocks was trying to get the xorg log for us, they did try to respawn x and kernel crashed (what voss and lankhorst are chatting about)
[16:04] <kgunn> watchdog timer fired
[16:04] <didrocks> kgunn: and there is no Xorg log
[16:05] <didrocks> nor lightdm ones
[16:05] <bschaefer> :( thats a bad crash then
[16:05] <didrocks> on the respawn
[16:05] <didrocks> (so after the first run)
[16:05] <didrocks> kgunn: did you get the archive file?
[16:05] <didrocks> (from the u-s-c run)
[16:06] <kgunn> didrocks: if you mean ubuntu_13.10_saucy_salamander_alpha_i386_20130806.1375887034.otto....my browser just does the sit-n-spin....and it never downloads
[16:06] <kgunn> lemme try again....
[16:06] <didrocks> kgunn: hum, really?
[16:07] <kgunn> didrocks: its going now...i prob was trying in midst of reboot or something
[16:07] <didrocks> possible yeah
[16:08] <tvoss> mlankhorst, mind enlightening me? :)
[16:09] <bschaefer> i also get the sit-n-spin
[16:09] <mlankhorst> tvoss: you're hitting a deadlock with w/e lock was being taken, and PROVE_LOCKING will tell you exactly what deadlock it is and how to cause it
[16:10] <mlankhorst> prove_locking is awesome, it catches bugs before they deadlock :P
[16:10] <bschaefer> kgunn, its working for me now
[16:10] <bschaefer> (download)
[16:10] <tvoss> mlankhorst, okay, thanks for the hints :)
[16:10] <tvoss> bschaefer, kgunn, didrocks any chance we can have a kernel with that flag enabled on the machine?
[16:11] <bschaefer> mlankhorst, thats awesome
[16:11] <bschaefer> tvoss, hmm I don't see why not
[16:11] <kgunn> that is awesome..but gotta rebuild kernel
[16:11] <mlankhorst> I don't know if it's smart enough to catch THIS particular bug before it deadlocks, but it very well might be ;P
[16:11] <bschaefer> hmm rebuilding the kernel sounds like fun
[16:12] <kgunn> didrocks: bschaefer that archive file downloads ok...but fails to unzip for me (tried to redownload, same result)
[16:12] <mlankhorst> and with that I mean it will probably have catched it at the point of deadlock, but if lucky it will warn way before that point already
[16:13] <bschaefer> kgunn, o hmm
[16:13] <didrocks> kgunn: did you try with tar xzf ?
[16:13] <bschaefer> mlankhorst, well that is if it deadlocks again...and if its a dead lock
[16:13] <kgunn> didrocks: gonna try
[16:14] <mlankhorst> bschaefer: if it's a deadlock there's a fat chance lockdep will have complained long before the actual deadlock :D
[16:14] <mlankhorst> and come on, it's an interrupt while holding a ton lof locks for committing new crtc state, of course it's very likely to be a deadlock..
[16:15]  * bschaefer hasn't ever seen a deadlock :)
[16:15] <bschaefer> i've learned about them...
[16:15] <mlankhorst> it's spinning [21683.801142]  [<c16237f2>] _raw_spin_lock_irqsave+0x22/0x30
[16:15] <bschaefer> mlankhorst, has lockdep complained
[16:15] <mlankhorst> bschaefer: lockdep is not enabled by default, requires PROVE_LOCKING kernel :-)
[16:15] <bschaefer> ooo, yeah now im on page :)
[16:16] <mlankhorst> but it checks if a deadlock is theoretically possible between the lock classes
[16:17] <mlankhorst> in some cases without ever being able to hit it, but there are workarounds if you believe lockdep is wrong. :P
[16:17] <bschaefer> haha, I would like to believe in lockdep :)
[16:17] <mlankhorst> I want to try the userspace version at one point :(
[16:18] <bschaefer> kgunn, do we have a machine we can rebuild the kernel on?
[16:18] <kgunn> bschaefer: yeah...this one, at least if didrocks says ok
[16:18] <bschaefer> mlankhorst, isn't any deadlock detecting algorithm externally inefficient? Which is why its not enabled by default...
[16:18] <didrocks> kgunn: we can't, we are starting 3h-daily releases now
[16:18] <bschaefer> err
[16:18] <bschaefer> extremely*
[16:19] <didrocks> kgunn: as it was a strong upstream demand, we'll not be able to build/block the machine for anything anymore soon
[16:19] <kgunn> bschaefer: do you have ati local ?
[16:19] <bschaefer> kgunn, Ill have to try to installed ubuntu on it again, my hard drive seems to hate me
[16:19] <kgunn> otherwise we may have to beg robotfuel to help us repro on his ati machine(s)
[16:19] <bschaefer> kgunn, let me give that another go
[16:19] <kgunn> bschaefer: talk nice to it
[16:20] <robotfuel> bschaefer: you can use ps-radeon-hd6870-he
[16:20] <didrocks> bschaefer: ensure you use radeon
[16:20] <bschaefer> kgunn, its so easy not to though!
[16:20] <kgunn> encourage the 1's and 0's to be in the right spot
[16:20] <mlankhorst> bschaefer: sort of, it's better here
[16:20] <mlankhorst> lockdep operates on classes of locks
[16:20] <mlankhorst> not individual locks
[16:20] <bschaefer> robotfuel, cool :)
[16:21] <mlankhorst> and also checks for things like 'is this lock ever taken with irqs disabled' etc
[16:21] <bschaefer> mlankhorst, ooo, thats interesting
[16:21] <kgunn> didrocks: just to confirm....we're main for mir+xorg-xmir+xorg-radeon & u-s-c from daily-build ppa
[16:21] <kgunn> right ?
[16:21] <mlankhorst> see linux/Documentation/lockdep-design.txt
[16:21] <kgunn> didrocks: for the sake of bschaefer ^
[16:21]  * bschaefer looks
[16:22] <didrocks> kgunn: exactly
[16:22] <bschaefer> didrocks, yeah, I would like to make little errors like using the wrong ppa :)
[16:22] <kgunn> cool
[16:22] <bschaefer> like to not*
[16:22] <bschaefer> mlankhorst, cool, that might be for out of work reading though...
[16:22] <kgunn> bschaefer: the main thing is to avoid daily-build-next ppa :)
[16:22] <bschaefer> haha
[16:22] <mlankhorst> bschaefer: heh it saved my life dealing with the ttm reworking
[16:23] <mlankhorst> and found quite a few 'almost impossible to hit' bugs :P
[16:23] <bschaefer> mlankhorst, that sounds like very complicated/fun work!
[16:23] <kgunn> bschaefer: whatever the fastest route is...local or in lexington....maybe lankhorst can help us out if we get debug info before his eod (whenever that may be)
[16:23]  * bschaefer looks up ttm
[16:24] <bschaefer> kgunn, yeah, well its also been a while since i've rebuilt the kernel, soo Ill have to spend sometime with that
[16:24] <kgunn> bschaefer: understood...
[16:24] <bschaefer> kgunn, but shouldn't be to hard
[16:24] <kgunn> kernel builds are usually damn quick...take you longer to find the flag :
[16:24] <kgunn> :)
[16:24] <mlankhorst> technically it's already EOD, but I'm feeling generous
[16:25] <kgunn> mlankhorst: we appreciate your generosity
[16:25] <mlankhorst> might be because the weather is too horrible to do outdoors sports :P
[16:25] <kgunn> mlankhorst: you're building you "i owe you a beer" backlog
[16:25] <bschaefer> haha
[16:25]  * kgunn hopes mlankhorst drinks beer
[16:25] <bschaefer> kgunn, yeah, well then I should poke around with the qa machine first
[16:26] <bschaefer> robotfuel, soo, ill use that machine! Ill try to remember to let you know when im done with it!
[16:26] <mlankhorst> alcohol free only, sadly
[16:28] <bschaefer> robotfuel, is there a quicker way of getting the ip of the machine then doing the kvm stuff?
[16:28]  * bschaefer isn't sure where the list of IPs are
[16:28] <robotfuel> bschaefer: the list is here https://wiki.canonical.com/UbuntuEngineering/QA/Lab
[16:29] <bschaefer> robotfuel, i went there to go to the kvm to log into the machine to do ifconfig..geez
[16:29] <bschaefer> robotfuel, thanks!
[16:32] <kgunn> mlankhorst: than a good meal...
[16:32] <kgunn> bschaefer: mlankhorst was able to pull the archive file from didier's machine....updated the bug here
[16:32] <kgunn> https://bugs.launchpad.net/mir/+bug/1204939
[16:33] <kgunn> brb
[16:33] <bschaefer> kgunn, cool thanks
[16:36] <mlankhorst> hm fun :P
[16:38] <mlankhorst> a few wtf errors from compiz though
[16:38] <mlankhorst> compiz (core) - Info: Unity is fully supported by your hardware.
[16:38] <mlankhorst> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
[16:39] <bschaefer> mlankhorst, usually means the driver didn't load hmm
[16:45] <kgunn> racarr: any progress on surface-configurator for osk? (starting to build backpressure i think)
[18:21] <kgunn> bschaefer: any luck repro'ing ?
[18:23] <bschaefer> kgunn, just finished getting the kernel built and now I need to make sure I have the ppas set up
[18:24] <kgunn> bschaefer: cool
[18:24] <bschaefer> along with the setting that kernel option on the x86 defconf
[18:24] <bschaefer> kgunn, soo hopefully soon :)
[18:24] <kgunn> bschaefer: yeah...and you'll probably want to check that flag after you load it
[18:25]  * kgunn remembers experiences of flag setting but it not really being set
[18:25] <kgunn> flags on flags
[18:25] <bschaefer> kgunn, i hope this doesn't happen to me...
[18:25] <kgunn> :)) me too
[18:26] <tvoss_> hello :)
[18:26] <tvoss_> kgunn, bschaefer any new insights?
[18:26] <bschaefer> tvoss_, getting the kernel setup right now
[18:26]  * bschaefer got lost a bit in it
[18:26] <tvoss_> bschaefer, ack
[18:26] <bschaefer> I should have the flag set, and just need to update the kernel version, make sure im on the right ppas, then reboot and hope for the best
[18:32] <tvoss_> bschaefer, okay, can you send a status mail to mircosmonauts when you eod?
[18:33] <bschaefer> tvoss_, microsmonauts? And sure
[18:33] <tvoss_> bschaefer, swap r and c
[18:34] <bschaefer> tvoss_, im still not sure who that is :)
[19:01] <tvoss_> bschaefer, some time back you looked into plain opengl support for raw-mir, right?
[19:01] <bschaefer> tvoss_, right, and you can get an opengl context from egl
[19:02] <bschaefer> which works
[19:02] <bschaefer> tvoss_, tested with sdl1.2 and sdl2.0
[19:02] <tvoss_> bschaefer, great, thank you
[19:02] <bschaefer> tvoss_, np!
[19:02] <tvoss_> bschaefer, is the code available somewhere?
[19:02] <bschaefer> tvoss_, yup, its in the mir staging ppa :)
[19:02] <bschaefer> tvoss_, hmm I wonder if any ABI has been broken though
[19:02] <tvoss_> bschaefer, thx, mind pinging me the branches, too?
[19:02] <bschaefer> tvoss_, will do
[19:09] <racarr> qtubuntu uses a plain opengl context too on desktop
[19:16] <robotfuel> I ran into this error again on intel using the s-c-t ppa (the in the unity-system-compositor.log) std::exception::what: Failed to set the current VT mode [boost::errinfo_errno_*] = 5, "Input/output error"
[19:16] <tvoss_> kgunn, cross-check mir is in main?
[19:16] <kgunn> tvoss_: yep
[19:17] <tvoss_> kgunn, and usc is in universe?
[19:17] <tvoss_> or not landed yet?
[19:17] <kgunn> racarr: ooo, nice fun fact
[19:18] <kgunn> tvoss_: u-s-c is only in daily-build ppa
[19:19] <tvoss_> kgunn, ack
[19:19] <robotfuel> reopening this bug https://bugs.launchpad.net/mir/+bug/1195509
[19:20] <kgunn> robotfuel: best combo atm would be main (which has latest mir + xorg) & u-s-c from daily-build ppa
[19:21] <robotfuel> kgunn: I'll test it with that. but we need it fixed in the s-c-t ppa for benchmarks
[19:22] <kgunn> robotfuel: yes...i'm with you on the ppa being updated (thot it would be this morning ..but it wasn;t :-/)
[19:24] <tvoss_> racarr, ping
[19:25] <robotfuel> kgunn: will it be updated tomorrow? I really want to get those benchmarks up.
[19:26] <kgunn> robotfuel: can we not go with main + u-s-c from daily-build ppa ?
[19:27] <kgunn> the system-compositor-testing ppa will disappear as soon as we clear the ati bug
[19:27] <kgunn> e.g....we'll be completely in main
[19:28] <racarr> tvoss_: pong
[19:29] <tvoss_> racarr, hey there :) can i ask you to write me a summary mail of your current design issue?
[19:29] <robotfuel> kgunn: ok I'll use that for now.
[19:29] <racarr> tvoss_: Yeah I've been thinking of asking you to talk about it actually...will write an email today
[19:30] <tvoss_> racarr, yeah, let's just discuss it via mail. perhaps you can try to state the problem without class names first
[19:30] <racarr> XD fun ok
[19:31] <racarr> I don't feel as blocked on the existing two branches anymore but it's still a
[19:31] <racarr> recurring problem I guess...
[19:31] <racarr> we've started to have this "grand unified state problem" :p
[19:32] <bschaefer> kgunn, hmm I still get a dependency problem from main xmir + u-s-c from daily build
[19:32]  * bschaefer looks at downgrading
[19:33] <bschaefer> kgunn, well looks like its using the libmir from daily-build
[19:33] <kgunn> bschaefer: make sure your purged, unpinned, update/dist-upgraded....then you can rebuild u-s-c locally
[19:34] <bschaefer> kgunn, yeah, I can do that as well, but im downgrading libmerserver0 to main from daily build so I can install u-s-c- from daily build
[19:34] <bschaefer> *should* work
[19:34] <kgunn> bschaefer: true...
[19:34] <bschaefer> well still doesn't like it :), seems to want to upgrade the libmirserver0 anyway
[19:35]  * bschaefer just builds u-s-c locally
[19:35] <robotfuel> bschaefer: If I pin just the u-s-c package in the daily-build ppa, will xmir work? (after apt-get and dist-upgrade)
[19:35] <kgunn> robotfuel: in theory
[19:35] <robotfuel> ok I'll let you know how that goes
[19:35] <bschaefer> robotfuel, it seems you'll have to build u-s-c your self...as Im getting a dependency error from daily-build
[19:35] <bschaefer> for u-s-c
[19:35] <bschaefer> on libmirserver0
[19:36]  * bschaefer purges daily build and tries again
[19:38] <kgunn> mlankhorst: tvoss_ ....to make sure i understand it all...is the xserver-xorg-video-ati that's in main coming from the source package located at https://code.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir
[19:38] <kgunn> ?
[19:38] <tvoss_> kgunn, not sure, best to cross-check with bschaefer I would say
[19:39]  * bschaefer looks
[19:39] <bschaefer>   Installed: 1:7.1.0+git20130801.g2ae6bb1-0ubuntu4
[19:39] <bschaefer> kgunn, I would like to think so, it says its stored on git
[19:40] <bschaefer> kgunn, err...but thatbranch isn't on git hmm
[19:41] <kgunn> bschaefer: right...its on lp/bzr...but i'm sure an upstream feeds it
[19:41] <bschaefer> kgunn, yeah and this is what happens when i try to get source:
[19:41] <bschaefer> http://paste.ubuntu.com/5960085/
[19:42] <robotfuel> bschaefer: unity-system-compositor I want is  from the ppa:ubuntu-unity/daily-build-next?
[19:42] <bschaefer> robotfuel, noo daily-build
[19:42] <bschaefer> not next :)
[19:42] <bschaefer> ppa:ubuntu-unity/daily-build
[19:42] <bschaefer> so that ppa
[19:42] <bschaefer> kgunn, i mean you should be able to pull the source with out a sudo :)
[19:43] <bschaefer> opps
[19:43]  * bschaefer was in a bad dir
[19:43] <bschaefer> kgunn, it looks like it pulls the source from: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-ati
[19:44] <kgunn> bschaefer: right...but there has to be an "xmir" patch on it
[19:45] <bschaefer> kgunn, yeah with all this pretty xmir wrapping stuff
[19:45] <kgunn> bschaefer: so  i did apt-cache policy which is i assume what you did ?
[19:45] <kgunn> and it showed git likewise....
[19:46] <bschaefer> yup, but is it the same as the launchpad branch?
[19:46] <kgunn> however...if i do intel & nouveau...it doesn't have  git reference
[19:46] <bschaefer> oo
[19:46] <bschaefer> hmm I wonder if the ati wasn't moved?
[19:46] <kgunn> wondering...are we chasing a packaging issue
[19:46] <bschaefer> kgunn, that would be very awesome
[19:46] <kgunn> bschaefer: can you double check apt-cache policy for intel/nouveau
[19:46] <kgunn> and see what you think
[19:46] <bschaefer> yup
[19:47] <bschaefer> kgunn, yeah no git mention
[19:47] <kgunn> tvoss_: if this is it ^ it deserves a "ffs"
[19:47]  * bschaefer wishes didrocks, or some other packaging person worked during this time zone 
[19:48] <kgunn> bschaefer: was just about to ask you ...who
[19:48] <kgunn> :-/
[19:48] <bschaefer> kgunn, yeeah, at this point hmm not sure :(
[19:48] <kgunn> bschaefer: ok...first...can you repro the hang on "a" machine somewhere either local or in lexington ?
[19:49] <bschaefer> kgunn, right, im trying one more time to get u-s-c from daily build if that fails ill just compile it my self
[19:49] <bschaefer> reboot, confirm its hanging, then install my built kernel with this PROVE_LOCKING config enabled
[19:49] <bschaefer> and try to get prove theres a deadlock
[19:49] <kgunn> bschaefer: cool
[19:50] <mlankhorst> kgunn: I'm using xserver-xorg-video-ati.git from debian
[19:50] <kgunn> bschaefer: and secondary to that...i was thinking, pull video-ati debs from mir-team/staging....install those see what happens
[19:50] <mlankhorst> oh pushed changes btw
[19:50] <bschaefer> kgunn, good idea
[19:51] <kgunn> AND/or rebuild from  https://code.launchpad.net/~mir-team/mir/xf86-video-ati-vladmir
[19:51] <bschaefer> mlankhorst, but shouldn't it be using that launchpad branch?
[19:51] <bschaefer> like intel/nouveau
[19:51] <kgunn> mlankhorst: can you read our recent scrollback ?
[19:51] <kgunn> we're suscpicious that what's in main doesn't have xmir patches ?
[19:52] <mlankhorst> bschaefer: all packaging in the ubuntu archives are synced to ubuntu branch from debian git
[19:52] <bschaefer> kgunn, that apt-get sources does in fact have the xmir patches
[19:52] <bschaefer> mlankhorst, well shoot, still strange the intel/nouveau don't mention git
[19:52] <mlankhorst> they do
[19:53] <bschaefer> mlankhorst, when you apt-cache policy on them, its not pulling it from git
[19:53] <bschaefer> the info
[19:53] <bschaefer> the ones on main
[19:54] <bschaefer> xserver-xorg-video-ati:
[19:54] <bschaefer>   Installed: 1:7.1.0+git20130801.g2ae6bb1-0ubuntu4
[19:54] <bschaefer> xserver-xorg-video-intel:
[19:54] <bschaefer>   Installed: 2:2.21.12-1ubuntu1
[19:54] <bschaefer> which is a bit strange why the atis name is so mangled
[19:55] <mlankhorst> because it was a random snapshot of upstream git
[19:55] <mlankhorst> if you enable saucy-proposed
[19:55] <mlankhorst>      1:7.2.0-0ubuntu1 0
[19:55] <mlankhorst>         500 http://archive.ubuntu.com/ubuntu/ saucy-proposed/main amd64 Packages
[19:55] <mlankhorst>      1:7.1.0+git20130801.g2ae6bb1-0ubuntu4 0
[19:55] <mlankhorst>         500 http://archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
[19:55] <bschaefer> mlankhorst, which is the same package? ie. it wont fix anything using saucy-proposed...
[19:56] <mlankhorst> I have no idea why xxv-ati is stuck in proposed atm
[19:57] <bschaefer> hmm, but the one in main does have the xmir patch sooo I highly doubt its that package...just strange it was held back
[19:57] <mlankhorst> ask in #ubuntu-devel I guess
[19:59] <bschaefer> will do, thanks
[20:01] <bschaefer> mlankhorst, soo also to enable that PROVE flag in the kernel, I added this in my kernel:
[20:01] <bschaefer> linux-3.10.0/arch/x86/configs/x86_64_defconfig
[20:01] <bschaefer> CONFIG_PROVE_LOCKING=y
[20:01] <bschaefer> does that sounds about right to set that flag?
[20:02] <mlankhorst> i dont know how the kernel team builds kernels and/or sets config parameters
[20:03] <bschaefer> alright, just wanted to double check, cause hopefully I can test this out soon...
[20:08] <kgunn> bschaefer: #ubuntu-kernel should know
[20:08] <bschaefer> kgunn, I missed how you checked if it was hanging?
[20:08] <bschaefer> kgunn, also: /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: xmir_get_drm_fd
[20:09] <bschaefer> that sounds bad as well
[20:09] <bschaefer> in lightdm/x-0.log
[20:09]  * bschaefer checks didrocks bug
[20:10] <kgunn> bschaefer: very
[20:10] <bschaefer> kgunn, hmm but didrocks doesn't get that
[20:10] <bschaefer> hmm I wonder if im doing something wrong? Im just using all main packages
[20:10] <bschaefer> and u-s-c built from trunk
[20:10]  * bschaefer wonders if thats a problem?
[20:11] <bschaefer> hmm can't be u-s-c it was last updated with that disable input push...
[20:13] <kgunn> bschaefer: i don't think so....but if you read the bug, seems RAOF and duflu elude failing to get a drm handle
[20:14] <bschaefer>  hmm an undefined symbol is very strange to get all of sudden though...hmm
[20:14] <bschaefer> and my Xorg.0.log is odd as well
[20:14]  * bschaefer pastebins it
[20:15] <bschaefer> hmm I also get this in it: [    12.731] (EE) Failed to load module "xmir" (module does not exist, 0)
[20:15] <bschaefer> http://paste.ubuntu.com/5960193/
[20:17] <bschaefer> kgunn, let me purge daily ppa
[20:17] <bschaefer> possibly that could have caused an issue...
[20:17] <kgunn> bschaefer: freaky enough...i had to load xorg-xmir yesterday
[20:17] <kgunn> not completely sure why
[20:18] <bschaefer> install it?
[20:18] <kgunn> bschaefer: yep...meant install, apt-get install
[20:18] <bschaefer> kgunn, o alright, I was thinking you could manually load it or something :)
[20:19] <kgunn> bschaefer: yeah...strange...if you do apt-cache...it'll say candidate:blah...but installed:nothing
[20:19]  * bschaefer is iinstalling xmir now
[20:19] <bschaefer> strange
[20:21]  * kgunn again wishes we had a north/south american version of didrocks
[20:22] <bschaefer> kgunn, haha very true!
[20:22] <bschaefer> kgunn, hmm from these logs atm the ati machine seems to be working? Wth...
[20:22]  * bschaefer goes to log into the kvm
[20:23] <bschaefer> urggg
[20:23] <bschaefer> why do I see unity
[20:24] <kgunn> bschaefer: are you local or lexington ?
[20:25] <bschaefer> kgunn, lexington
[20:25] <kgunn> bschaefer: can you verify ps aux | grep unity-system-comp
[20:25] <kgunn> make sure you didn't fallback
[20:25] <bschaefer> kgunn, forgot to do that :)
[20:25] <bschaefer> its running :(
[20:25] <kgunn> bschaefer: do we have any other radeon machines ?
[20:26] <bschaefer> root       959  0.5  0.3 739224 30044 ?        Sl   20:24   0:00 /home/jenkins/staging/sbin/unity-system-compositor --enable-input=false --from-dm-fd 10 --to-dm-fd 13 --vt 7
[20:26] <bschaefer> robotfuel, ^
[20:26] <kgunn> bschaefer: if you want to try same config local before your EOD that would be interesting
[20:26] <kgunn> ...so we got 3 data points
[20:26] <bschaefer> kgunn, right, i still have 4-5 hours of my day :)
[20:27] <kgunn> 1) didrocks otto machine 2) lexington machine#1 3) your local
[20:27] <kgunn> it would be nice to have even more
[20:27] <kgunn> all good data
[20:27] <bschaefer> yes, I really really wished I could repro this
[20:27] <kgunn> can you run glxinfo
[20:27] <kgunn> and glxgears?
[20:27] <bschaefer> kgunn, why does didrocks always get the bad machine?
[20:27] <bschaefer> yup
[20:27] <robotfuel> bschaefer: they are running tests right now, we have this one https://bugs.launchpad.net/xmir/+bug/1209000 that's trying the daily-build ppa now
[20:27] <bschaefer> err let me run it
[20:28] <bschaefer> robotfuel, alright, would we be able to switch machines at some point?
[20:28] <bschaefer> when they finish?
[20:28] <robotfuel> bschaefer: yes
[20:29] <robotfuel> bschaefer: I'll let you know
[20:29] <bschaefer> robotfuel, cool, as im done with that machine as it seems to be working ...
[20:29] <bschaefer> kgunn, just to re-iterate
[20:29] <bschaefer> kgunn, the problem occurs with libmirserver0 from main, and u-s-c built locally?
[20:29] <kgunn> bschaefer: yep...please do
[20:29] <bschaefer> on an ati machine?
[20:29] <bschaefer> kgunn, as right now I have 0 ppas installed
[20:30] <bschaefer> and xmir is working
[20:30] <kgunn> bschaefer: good point....didrocks had all main + u-s-c from daily-build ppa
[20:30] <kgunn> bschaefer: also we should not forget that you and i both had to install xorg-xmir
[20:30] <bschaefer> kgunn, I couldn't install u-s-c from the daily-build ppa because of a dependency problem :(
[20:30] <bschaefer> right that was strange as well...
[20:31] <bschaefer> kgunn, but that could have come from doing the purge of u-s-c testing
[20:31] <kgunn> bschaefer: jibel just joined...he might be able to get us onto the otto machine
[20:31]  * bschaefer checks when u-s-c was rebuilt in daily-build
[20:32] <bschaefer>  unity-system-compositor - 0.0.1+13.10.20130807.2-0ubuntu1 	(changes file) 	ps-jenkins (ps-jenkins: 235412) [ubuntu-bugcontrol] 	5 hours ago 	Published 	Saucy 	X11
[20:32] <bschaefer> 5 hours ago hmm
[20:33] <bschaefer> kgunn, i wonder if didrocks was able to use the version before? It shouldn't matter though... as u-s-c hasn't changed since 8-01
[20:33] <bschaefer> hmm
[20:34]  * bschaefer doesn't know how he got u-s-c to only install it self from daily-build ppa
[20:36] <kgunn> bschaefer: ok...just now, updated to ensure..i'm using main + daily build ppa for usc....rebooting
[20:41] <bschaefer> hmm u-s-c from daily build vs local build cannot be the problem...as trunk hasn't updated since last Thursday ...
[20:41] <bschaefer> kgunn, the only thing that might be different, is if you hav ethe daily build ppa and upgrade some libmir packages...hmm
[20:42] <kgunn> bschaefer: ok i rebooted just fine
[20:42] <bschaefer> kgunn, you're on an ati?
[20:42] <kgunn> bschaefer: no intel....but go no complaints about mismatch either
[20:42] <bschaefer> kgunn, you were getting that before?
[20:43] <kgunn> bschaefer: nope but thot you were
[20:43] <bschaefer> kgunn, o that abi stuff went away ... when I installed xorg-xmir :)
[20:44] <kgunn> bschaefer: for clarity sake...my steps purged/unpinned (days ago), apt-get update/dist-upgrade, then....i download the deb file from the ppa site....and do dpkg -i on unity-system-comp.deb
[20:44] <bschaefer> and you can install u-s-c from daily build?
[20:44] <bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.1-0ubuntu1 is to be installed
[20:44] <bschaefer> oo
[20:44] <bschaefer> kgunn, see I was add-apt-repos on the ppa
[20:45] <bschaefer> and tried to install unity-system-compositor
[20:45]  * bschaefer purges daily build and tries that
[20:45] <bschaefer> kgunn, so you do not have daily build ppa installed right?
[20:45] <kgunn> bschaefer: right...i only cherry pick u-s-c off the daily-build ppa website
[20:46] <bschaefer> kgunn, i didn't even know you could do that :)
[20:46]  * bschaefer grabs is
[20:46] <bschaefer> it*
[20:46]  * kgunn been hanging out with shady folk like robert_ancell
[20:46] <bschaefer> haha
[20:48] <kgunn> bschaefer: do you know the command line to get the deb patch file applied to the source ?
[20:48] <bschaefer> kgunn, still get a dependency error :(
[20:48] <bschaefer> kgunn, well you should just be able to do a dget, and from the use dpkg-buildpackage -us -uc
[20:48] <bschaefer> and then install the *.deb
[20:49] <kgunn> bschaefer: when you dpkg -i install it'll gripe about runtime deps....it should be ok
[20:49] <kgunn> not build time deps
[20:49] <kgunn> what did it whine about ?
[20:49] <bschaefer> o hmm
[20:49]  * bschaefer pastebins
[20:50] <bschaefer> http://paste.ubuntu.com/5960302/
[20:50] <bschaefer> kgunn, it says its installed through though policy
[20:52]  * bschaefer tries it out
[20:52] <kgunn> bschaefer: hmmm...i get all the other whining except lines 7-14 in your pastebin
[20:53] <kgunn> bschaefer: make sure you've purged, unpinned, updated, dist-upgraded, then dpkg install u-s-c
[20:53]  * bschaefer goes to make sure
[20:54]  * kgunn glad to see in pastebin someone else forgets sudo on dpkg install....
[20:54]  * kgunn does it every _single_ time
[20:54] <bschaefer> haha
[20:55] <bschaefer> didn't mean to copy that much info!
[20:57] <kgunn> robotfuel: wrt this bug https://bugs.launchpad.net/xmir/+bug/1209000
[20:58] <kgunn> would you mind adding the /var/log/lightdm/* & /var/log/Xorg*
[20:59] <kgunn> robotfuel: actually....only if you can run on main(mir/xorg) + daily-build(u-s-c) ....note not daily-build-next :)
[20:59] <kgunn> jibel:
[20:59] <robotfuel> kgunn: ok, main(mir/xorg) + daily-build(u-s-c) fails due to packaging
[20:59] <kgunn> jibel: oops..meant to ask...could we get on otto ? or is it busy?
[21:00] <robotfuel> kgunn: there is another issue with that system, without the xorg stuff it's super slow
[21:00] <robotfuel> * 3d accel is slow
[21:00] <kgunn> robotfuel: so it the machine suspect ?
[21:00] <bschaefer> kgunn, hmm I also can't rebuild u-s-c when just using main
[21:00] <robotfuel> kgunn: it seems like a bug in the driver
[21:01] <bschaefer> http://paste.ubuntu.com/5960342/
[21:01] <bschaefer> eek
[21:01] <bschaefer> missing mirserver-dev
[21:01] <robotfuel> kgunn: I am writing a bug now for the slowness in the regular xorg driver
[21:01] <kgunn> bschaefer: ...yeah, i noticed that a couple of hours ago....don't know how daily-build built it 5 hours ago...nothing changed ?
[21:02] <kgunn> bschaefer: ah
[21:02] <bschaefer> kgunn, yeah...it causing fun problems for me :(
[21:02] <bschaefer> http://paste.ubuntu.com/5960347/
[21:02] <bschaefer> kgunn, which is what dpkg was complaining about
[21:03]  * bschaefer wonders what else was rebuild in daily build
[21:04] <bschaefer> kgunn,  mir - 0.0.8+13.10.20130807.3-0ubuntu1
[21:04] <bschaefer> was rebuilt 4 hours ago
[21:05] <bschaefer> and u-s-c was rebuilt 5 hours ago...soo u-s-c I think needs to be rebuilt...
[21:07] <robert_ancell> bschaefer, bug 1209104. Fixed now
[21:07] <robert_ancell> brb
[21:09]  * bschaefer guesses it hasen't made it to main yet...
[21:10] <bschaefer> robert_ancell, well thats good, but im trying to cherry pick u-s-c from daily-build ppa to test out a very bad ati bug :(
[21:10] <robert_ancell> bschaefer, I'm just updating the system-compositor-testing PPA right now, not sure if that helps (that bug was blocking it)
[21:11] <bschaefer> robert_ancell, sadly it has to make it to main, as im trying to track down a possible deadlock in the kernel :(
[21:11] <bschaefer> robert_ancell, and trying to follow how didrocks reproed it, and cant...
[21:12] <bschaefer> kgunn, soo should I try using the daily build ppa for now to see if I can repro it?
[21:13] <kgunn> bschaefer: do you mean
[21:13] <kgunn> bschaefer:  main(mir/xorg) + daily-build(u-s-c)
[21:13] <bschaefer> kgunn, can't get u-s-c to work with daily-build due to dependency problems
[21:13] <bschaefer> but if I do daily build (mir/xorg) I can build u-s-c my self
[21:14] <kgunn> bschaefer: so weird...i don't get that
[21:14] <bschaefer> kgunn, as mir was rebuilt in daily build 4 hours ago, and u-s-c  was rebuilt 6 hours ago :(
[21:14]  * bschaefer attempts to install it again
[21:15] <robert_ancell> bschaefer, which bzr versions do you need to test?
[21:15] <kgunn> bschaefer: yeah...but then you're combo would just need to be  main(mir/xorg) + "locally built"(u-s-c)
[21:16] <bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.1-0ubuntu1 is to be installed
[21:16] <bschaefer> robert_ancell, hmm I need those mir header fixed so I build u-s-c locally, can I build those headers locally as well?
[21:16] <bschaefer> or is that part of the libmirserver?
[21:16] <robert_ancell> bschaefer, yes, part of libmirserver
[21:17] <bschaefer> shoot, and at the point I would just be rebuilding libmirserver from trunk which we are trying to use it from main, for some reason?
[21:18] <bschaefer> s/the/that
[21:18] <robert_ancell> bschaefer, if you need both the latest of mir and u-s-c, you should be able to use the system-compositor-testing PPA, which is just updating now
[21:18] <bschaefer> robert_ancell, hmm I should have gotten more info out of didrocks :)
[21:18] <bschaefer> robert_ancell, ill give that a try when its finished
[21:19] <bschaefer> kgunn, whats your version os libmirserver0?
[21:19] <bschaefer> of*
[21:19] <kgunn> Installed: 0.0.8+13.10.20130807.1-0ubuntu1
[21:20] <bschaefer> strange...cause u-s-c seems to depend on:
[21:20] <bschaefer>  unity-system-compositor : Depends: libmirserver0 (= 0.0.8+13.10.20130807.2-0ubuntu1) but 0.0.8+13.10.20130807.3-0ubuntu1 is to be installed
[21:20] <bschaefer> the *7.2*
[21:20]  * bschaefer is on the daily build ppa
[21:20] <bschaefer> well I should at lease be able to build u-s-c from trunk, and give it another test
[21:21] <kgunn> bschaefer: yep...gonna try to build now too
[21:22] <bschaefer> dam my 10*.conf was removed...gotta remove it ..
[21:22] <kgunn> robert_ancell: so when i try to build u-s-c it says "fatal error: mir/options/program_option.h: No such file or directory"
[21:23] <robert_ancell> kgunn, right, that was broken in alan_g 's change to split out libraries
[21:23] <robert_ancell> it's fixed now
[21:23] <robert_ancell> see bug 1209104
[21:23] <bschaefer> kgunn, yup, but it hasn't made it into main
[21:23] <bschaefer> and I don't think it will very shortly
[21:24] <kgunn> roger tha
[21:24] <kgunn> that
[21:24] <bschaefer> kgunn, soo, im rebooting using daily build mir + local built u-s-c
[21:24]  * bschaefer think u-s-c just needs to be rebuilt in daily build ppa
[21:24] <bschaefer> robert_ancell, could we do that with out having to push a new package?
[21:24] <robert_ancell> bschaefer, once it's built you have to upload a new one
[21:25] <bschaefer> dang
[21:25] <robert_ancell> oh, hang on, in jenkins?
[21:25] <bschaefer> o well, locally built is no different then the ppa
[21:25] <robert_ancell> I'm just having a look, but I don't know how to trigger rebuilds
[21:25] <bschaefer> robert_ancell, i mean in the daily build ppa
[21:25] <robert_ancell> thomi, do you know?
[21:25] <thomi> otp, one minute
[21:25] <robert_ancell> bschaefer, ppa:ubuntu-unity/daily-build?
[21:26] <bschaefer> robert_ancell, yup
[21:26] <kgunn> bschaefer: https://pastebin.canonical.com/95607/
[21:26] <kgunn> just to be sure...that's what i get when i cherry pick...and it still seems to work
[21:27] <bschaefer> soo daily build mir + locally built u-s-c works fine on ATI
[21:27] <bschaefer> kgunn, why do we have to use main?
[21:27] <bschaefer> isn't daily-build about to be pushed to main?
[21:27] <kgunn> bschaefer: yes...you are right
[21:27] <robert_ancell> bschaefer, kgunn, system-compositor-testing should now be up to date for amd64 and i386
[21:27] <kgunn> robert_ancell: thanks
[21:28] <bschaefer> robert_ancell, thanks, ill test that out now
[21:28] <kgunn> w/ no vt switching ?
[21:28] <bschaefer> kgunn, vt was broken yesterday as well :(
[21:28] <bschaefer> I think duflu was looking into it but im not sure
[21:28] <kgunn> bschaefer: yeah...there's like 4 MPs that all need to hit
[21:29] <bschaefer> kgunn, cool, hmm soo off to test u-s-c
[21:29] <kgunn> bschaefer: when you said "daily build mir + locally built u-s-c works fine on ATI"
[21:29] <bschaefer> though I know didrocks isn't going to be happy we can't repro this, as he will be able to as soon as he wakes up
[21:29] <robert_ancell> kgunn, just landed th efirst one
[21:29] <kgunn> you meant the lexington machine ?
[21:29] <bschaefer> kgunn, right
[21:30] <bschaefer> kgunn, i still need to wipe my HD to install ubuntu
[21:30] <bschaefer> its having problems partitioning it still
[21:30] <kgunn> bschaefer: yeah...best bet to do that, another data point
[21:30] <bschaefer> which I can do when I go eat lunch at some point
[21:30] <bschaefer> kgunn, yup, let me test u-s-c out then go do that
[21:30] <kgunn> robert_ancell: RAOF's got an ati card right ?
[21:30] <robert_ancell> kgunn, yes
[21:30] <kgunn> can you get him to test as well....
[21:31] <kgunn> seems we may be back to didrock's "otto" machine
[21:31] <kgunn> taking this all very personally :)
[21:31] <bschaefer> kgunn, we should break didrocks machine, its the only one that gets angry!
[21:32] <bschaefer> (joking)
[21:32] <kgunn> robert_ancell: so if bschaefer can run on his local ati, and RAOF can run on his....can you please arrange something with didier to debug his morning (this may mean asking RAOF to stay late)....but i'm at a loss
[21:32] <robert_ancell> kgunn, is this the existing bug?
[21:33] <kgunn> https://bugs.launchpad.net/mir/+bug/1204939
[21:33] <bschaefer> as soon as we can reproduce this, we still nee to recompile the kernel with the PROVE_LOCKING enabled
[21:33] <bschaefer> just to see if its deadlocking or not
[21:34] <kgunn> bschaefer: right....right now, we're hunting for reproduction
[21:34] <kgunn> otherwise deadlock is only interesting on didrocks machine
[21:34] <bschaefer> kgunn, yeeah, which sucks :(, I would love to try to actually solve the issue
[21:34] <bschaefer> yeah
[21:35] <robotfuel> robert_ancell: do you know who I can ping about this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397? maybe it's the radeon driver doesn't support the 7850 card?
[21:36] <bschaefer> kgunn, also, where do you see the hanging problem?
[21:36] <bschaefer> kgunn, with didrocks machine, his logs arne't showing much of an ERROR
[21:36] <kgunn> bschaefer: correct...he was the one with the hang/only resulted in kernel panic when he tried to relaunch x
[21:37] <robert_ancell> robotfuel, opt, be back in 5
[21:37] <kgunn> robotfuel: that might be better for mlankhorst to help with
[21:37] <bschaefer> kgunn, soo otherwise it works? ... hmm as im trying to see maybe iam getting the problem but i don't see it?
[21:37] <bschaefer> as looking at his logs, xmir did start up (from what I can tell with out looking at a vm)
[21:38]  * bschaefer assumed a deadlock would cause xmir to not start up at all
[21:40] <bschaefer> well I have hardware acceleration sooo hmm
[21:41] <bschaefer> and xmir is running ...
[21:45] <bschaefer> robert_ancell, cool, and I can install u-s-c from the testing ppa
[21:46] <robert_ancell> robotfuel, RAOF would know
[21:47] <robotfuel> robert_ancell: he is in a  european timezone?
[21:47] <robert_ancell> robotfuel, australian, he will be on in ~1:10
[21:47] <robotfuel> robert_ancell: cool I will ask then :)
[21:49] <bschaefer> kgunn, well im going to eat some lunch and reformat my ati machine to get ubuntu on it
[21:50] <kgunn> cool
[21:50] <bschaefer> u-s-c testing ppa is working with ATI card as well, and I have hardware acceleration
[21:50] <bschaefer> same with daily build ppa
[21:50] <bschaefer> soo so far ati is not having a problem loading GL acceleration that I see
[21:52] <bschaefer> kgunn, whooa
[21:52] <bschaefer> compiz (core) - Info: Unity is fully supported by your hardware.
[21:52] <bschaefer> compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
[21:52] <bschaefer> kgunn, un my ~/.cache/upstart/gnome-session
[21:53] <bschaefer> which is very strange, cause I m running opengl for sure, as things are getting blured (the dash/launcher/hud)
[21:53] <bschaefer> kgunn, seems that has happened before* now its fine ... hmm wellim going to set up my ati machine and see what I can find
[21:54]  * bschaefer goes to eat some food
[21:56] <kgunn> bschaefer: sounds good
[21:59] <robert_ancell> kgunn, can you also confirm the s-c-t PPA works for you?
[22:00] <kgunn> robert_ancell: sure...lemme try now
[22:06] <robert_ancell> brb
[22:18] <kgunn> robert_ancell: good to go...s-c-t ppa worked for me
[22:18] <robert_ancell> \o/
[22:18] <robert_ancell> Now to fix VT switching..
[22:18] <robotfuel> robert_ancell: the s-c-t worked for me openarena passed on it
[22:18] <robotfuel> on a radeon 7450
[22:19] <robert_ancell> robotfuel, is that the radeon that was having trouble?
[22:20] <robotfuel> robert_ancell: no that was the 7850 that has problems, didrocks has a different version as well
[22:21] <kgunn> robotfuel: right but your 7850 had problems with standalone X as well ??
[22:22] <robotfuel> kgunn: yes, it has no 3d accel
[22:22] <robotfuel> kgunn: will xmir work with the non-free ati drivers?
[22:23] <robotfuel> catalyst driver
[22:24] <kgunn> robotfuel: nope...only free drivers
[22:31] <bschaefer> kgunn, sweet, it installed successfully this time, you were right about not yelling out it
[22:31]  * bschaefer goes to update things
[22:31] <RAOF> robotfuel: Yo?
[22:32] <robotfuel> RAOF: I have this bug,  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1209397 I am thinking it might be the radeon driver doesn't support the 7850 card?
[22:33] <RAOF> robotfuel: Ah, yes. The 7850 is a southern islands card which requires glamor to do 2D acceleration and requires 2D acceleration to do 3D accel, and we don't currently build glamor.
[22:33] <robert_ancell> robotfuel, so bug 1209000 is fixed or still occurring?
[22:35] <kgunn> bschaefer: good to hear...can't wait for the results
[22:35] <robotfuel> robert_ancell: I haven't tried it with the newest s-c-t ppa, but I think it will fail because there is no 3d
[22:36] <RAOF> Huh. I'm not sure why it's failing to find radeonsi?
[22:37] <robotfuel> robert_ancell: I just kicked off a test run so we will know in about 10 minutes
[22:37] <robert_ancell> robotfuel, nice
[22:37] <bschaefer> RAOF, well does it exist in the path its looking for?
[22:38] <robotfuel> robert_ancell: there is a new mir jenkins server here http://10.97.2.12:8080/
[22:38] <bschaefer> kgunn, as am i...
[22:38] <RAOF> bschaefer: On my system, yes.
[22:39] <robert_ancell> robotfuel, that is running the tests on the new hardware?
[22:39] <robotfuel> robert_ancell: yes, we are still waiting for 1 machine
[22:39] <bschaefer> robotfuel, have you been able to check if the file is located on one of those paths?
[22:39] <bschaefer> possibly it got installed to the wrong spot?
[22:39] <robert_ancell> robotfuel, nice work! Loving it's mostly green :)
[22:40] <robert_ancell> thomi, now we just need some nice graphs..
[22:40] <thomi> robert_ancell: right. robert_ancell, I understand that there's work being merged into the dashboard to support that>?
[22:41] <thomi> robert_ancell: BTW, I realise I never answered your question from before - is it still open?
[22:41] <robotfuel> robert_ancell: thomi I have some older graphs here http://10.97.9.23:8002/graphics/
[22:42] <robert_ancell> thomi, open? It seems to have rebuilt 4mins ago
[22:42] <thomi> robert_ancell: ok, good
[22:42] <thomi> robert_ancell: right, but we want it in the dashboard. I think Francis said there was work being merged to support that?>
[22:43] <robotfuel> thomi: yes, I am working on that too
[22:43] <thomi> robotfuel: I see now - that's the staging isntance?
[22:43] <robotfuel> thomi: yes
[22:44] <robotfuel> thomi: it doesn't have the stuff from the new jenkins server in it.
[22:44] <thomi> yeah
[22:44] <thomi> and we probably need to clean up the data a bit before publishing it
[22:44] <thomi> but otherwise, it look sgood
[22:48] <robert_ancell> robotfuel, oh, now I see why it's all green - the xmir jobs haven't completed :)
[22:49] <robotfuel> robert_ancell: this is a bug again https://bugs.launchpad.net/mir/+bug/1195509
[22:49] <robotfuel> it was fixed for a little while it seems
[22:50] <robert_ancell> robotfuel, yes, we think it will be fixed with https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/177800, but we need to fix the VT switch keys first. That's the four MPs kgunn was talking about
[22:52] <robert_ancell> kgunn, btw I just pushed the updated mir to main
[22:53] <kgunn> robert_ancell: cool...sounds very powerful
[22:53] <bschaefer> yay
[22:53] <robert_ancell> ROAR!
[22:55]  * racarr GONG
[22:55]  * RAOF TING
[22:56] <robert_ancell> racarr, did you talk to kdub? He was looking for you
[22:58] <robert_ancell> mlankhorst, ping
[22:59] <racarr> robert_ancell: Not yet :)
[22:59] <racarr> kdub: I was just getting ready to digest how all your changes went
[22:59] <racarr> and am now participating in leak testing because apparently the shop downstairs has water spots
[23:00] <robotfuel> I am getting a new failure on the radeon hd7850 with xmir /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate
[23:00] <kdub> racarr, ah, ok. hopefully i have my focus changes out the door soon
[23:00] <robert_ancell> racarr, that wasn't the leak testing I was expecting :)
[23:00] <robert_ancell> RAOF, ^
[23:00] <robotfuel> that's with the s-c-t ppa
[23:00] <robotfuel> I'll have a bug up shortly
[23:01] <RAOF> robotfuel: Well, that would be because it hasn't loaded the EXA module, which is perfectly reasonable :)
[23:01] <kdub> racarr, pretty much, i've detangled create_surface_for (almost) which lets you control better when you get focused event
[23:01] <RAOF> What's not reasonable is that it's trying to resolve EXA symbols.
[23:02]  * RAOF notes that there isn't any X in s-c-t; it's all in the archive.
[23:02] <racarr> kdub: Excellent.
[23:02] <racarr> new MP today you are hoping?
[23:02] <robotfuel> it's running in failsafe mode now, it tried starting X 2 times.
[23:03] <RAOF> robotfuel: My expectation is that a 7850 would not work correctly with the free driver at the moment, XMir or not.
[23:05] <robotfuel> RAOF: robert_ancell: do we want to make the radeon 7850 work? with xmir we can drop that hardware from the test plan, but also have document that the card doesn't work with bugs.
[23:06] <RAOF> robotfuel: I think we should make the 7850 work; it' just not an xmir issue that it doesn't.
[23:06] <robert_ancell> robotfuel, we just need to match the existing X behaviour. So if it doesn't work currently, then it should continue not to work.
[23:06] <robert_ancell> robotfuel, in saying that - if we make it worse, we should blacklist that card and test it correctly falls back to non-xmir behaviour
[23:31] <bschaefer> kgunn, soo, its working :)
[23:32] <bschaefer> mir/xorg from main + cherry pick u-s-c from daily build
[23:32]  * bschaefer digs through logs to make sure hard ware acceleration is on...but it seems to be
[23:56] <bschaefer> kgunn, soo to sum up today...it appears to be working on 2 ati machines...
[23:56] <bschaefer> RAOF, ping
[23:56] <RAOF> bschaefer: Pong.
[23:56] <bschaefer> RAOF, hello, did you still have your other ati machine up and running?
[23:56] <RAOF> Yeah, my 4350.
[23:56] <RAOF> XMir worked on that yesterday.
[23:57] <bschaefer> RAOF, hmm well you already commented on the bug, the logind one
[23:57] <bschaefer> https://bugs.launchpad.net/mir/+bug/1204939
[23:58] <bschaefer> RAOF, i've been looking at it for the most the day, and both the ATI machines I've used have worked with xmir
[23:58] <bschaefer> if you had a chance to test it out, didrocks was running a bad problem this morning, possibly a deadlock in the kernel
[23:58] <bschaefer> running into*