[03:40] <RAOF> duflu: Oh, I've realised that one of my problems with DRI bypass is actually a generic problem with nested bypass, so I'm interested in how you've solved it
[03:42] <RAOF> The problem is - what happens if you need to unbypass? You've only got one buffer from the server you're running against, and you've handed it out to the bypass-client. So now you need to wait for it to swap_buffers before you can unbypass, but there's no mechanism to make it swap_buffers (and can't be in general).
[03:46] <duflu> RAOF: My first prototype worked that way but then I realized the same problem. The client could hold it indefinitely.
[03:47] <RAOF> So how did you solve that?
[03:47] <duflu> The current approach is to make client buffers (sometimes) scanout capable and give them directly to the server as required
[03:47] <robert_ancell> RAOF, on the phone, when unity8/mir runs as the user it's logged in as - does it have enough permissions to get input directly? Or do we have to go via the system compositor?
[03:48] <RAOF> robert_ancell: If we want to have any form of user-switching then input needs to go via the system-compositor.
[03:48] <robert_ancell> RAOF, but we're not doing that for XMir right?
[03:48] <duflu> RAOF: There will be some smarts required to limit which clients get scanout capable buffers, and maybe event change it at runtime. But right now I just have all clients given scanout capable buffers. And sometimes they will be scanned out (bypass), sometimes not (composited)
[03:48] <RAOF> Right. Which is why user switching under XMir is currently a terribly bad idea.
[03:49] <RAOF> Also, we run XMir as root.
[03:49] <robert_ancell> yes
[03:49] <robert_ancell> I just got support to run Mir sessions and VT switch between them, but that's probably a no-go
[03:49] <RAOF> And the design for 13.10 is that we trust XMir to acquire/release input when its session gets switched to/from.
[03:50] <RAOF> As long as the Mir sessions can acquire/release input on VT switch, and unity-system-compositor can acquire/release input on VT switch that should work.
[03:51] <robert_ancell> I think you need to be root to watch for VT switches
[03:51] <RAOF> Indeed you do.
[03:51] <RAOF> Anything we run on a VT needs to do so as root.
[03:52] <robert_ancell> Is there any way to authorize certain processes to run on a VT?
[03:52] <RAOF> Anything we run under unity-system-compositor *can* run unprivileged, as long as it gets input through u-s-c.
[03:52] <robert_ancell> yeah
[03:52] <RAOF> I'm not sure that's enough.
[03:53] <RAOF> Because (if you're running on a VT) you need to be able to access /dev/input/* to get input.
[03:53] <robert_ancell> yeah, and that's root right?
[03:53] <RAOF> Indeed
[03:53] <RAOF> And if your *user* can access /dev/input/*, then they can just open it, switch away, and they snoop all input.
[03:53]  * RAOF notices it's 2pm and goes for lunch.
[03:54] <robert_ancell> yes, you would have to limit it to just the shell to be useful
[04:18] <RAOF> Which is pretty similar to "just run the shell as root"
[04:37] <RAOF> duflu: Ah. That doesn't help me, then (and won't work for the nested-compositor case)
[04:37] <RAOF> duflu: We should probably work out how to do it properly :)
[04:42]  * duflu does lunch too
[05:02] <tvoss> good morning :)
[05:05] <RAOF> Aloha
[05:06] <tvoss> robert_ancell, RAOF did we have any luck with the ati machine?
[05:08] <RAOF> tvoss: I thought that got all resolved?
[05:09] <tvoss> RAOF, not sure :) I hope it it is
[05:13] <robert_ancell> tvoss, RAOF that's bug 1204939 and we don't have a solution
[05:13] <robert_ancell> RAOF, duflu can you have a look at that one and triage it please?
[05:14] <tvoss> RAOF, we saw  [  2417.963] (II) UnloadModule: "radeon"
 [  2417.963] (EE) Screen(s) found, but none have a usable configuration.
[05:14] <tvoss> RAOF, from the next ppa that didrocks wanted to test
[05:16] <RAOF> So the problem is that XMir hasn't been loaded at all.
[05:16] <robert_ancell> RAOF, did the packaging changes mess things up?
[05:16] <duflu> OK, title improved but needs much more attention to be "triaged"
[05:17] <RAOF> robert_ancell: Possibly? I would have thought the server would die if it couldn't load xmir.so
[05:25] <tvoss> didrocks, good morning
[05:25] <didrocks> hey tvoss
[05:26] <tvoss> RAOF, any ideas why the new packaging might fail?
[05:27] <RAOF> tvoss: Not off the top of my head.
[05:28] <tvoss> didrocks, do we have access to the machine? would like to track this issue down
[05:29] <didrocks> tvoss: the machines are currently running the tests for daily release
[05:30] <didrocks> as having those in the image is the priority, no access to the machine now
[05:30] <RAOF> didrocks: Do we have a dump of /var/log anywhere?
[05:30] <didrocks> RAOF: you can have that if you uncompress the archive from yesterday
[05:30] <didrocks> I'll give you a pointer in 5
[05:30] <RAOF> Ta
[05:33] <robert_ancell> didrocks, you'll be in IOM right?
[05:33] <didrocks> robert_ancell: right
[05:33] <didrocks> RAOF: http://10.97.4.138/otto/saucy-i386-20130725-1116/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130725.1374764535.otto
[05:33] <didrocks> RAOF: this is a tar file
[05:33] <robert_ancell> didrocks, tvoss, see you guys there
[05:33] <didrocks> you have a delta/ directory
[05:33] <didrocks> robert_ancell: see you there as well dude! :)
[05:34] <didrocks> in the delta, it's a bump of all what was modified
[05:34] <didrocks> so you should have var/log and so old
[05:34] <RAOF> Well, that is of moderate size!
[05:34] <didrocks> so on*
[05:34] <didrocks> RAOF: don't install that many packages :p
[05:35] <didrocks> (it's really just a delta, with mir installed on top of it)
[06:02] <RAOF> didrocks: It looks to me like xmir worked as expected on that test run - it's the failsafe session that failed to start.
[06:03] <didrocks> RAOF: why failsafe was executed?
[06:04] <didrocks> shouldn't we have u-s-c running?
[06:04] <RAOF> lightdm.log shows that u-s-c started up fine, XMir started up fine, then upstart asked lightdm to terminate, which it did, cleanly.
[06:05] <RAOF> (upstart sent SIGTERM ~20s after lightdm came up)
[06:05] <didrocks> RAOF: the session even didn't start
[06:05] <didrocks> (user session)
[06:06] <RAOF> [+1.88s] DEBUG: Session 1085 running command /usr/sbin/lightdm-session gnome-session --session=ubuntu
[06:06] <RAOF> Then: [+22.80s] DEBUG: Got signal 15 from process 1
[06:06] <didrocks> RAOF: right, the question is why the session was killed?
[06:06] <didrocks> as nothing changed and the same package versions are working reliably on intel
[06:06] <didrocks> with session starting
[06:07] <didrocks> unity spawn
[06:07] <didrocks> RAOF: it seems that the acceleration test maybe doesn't work (what is tested before starting unity)
[06:07] <didrocks> so can't start unity -> required component
[06:07] <didrocks> -> exit
[06:09] <RAOF> Plausibly - ~/.cache/upstart/unity7.log contains a lot of ‘unity7 stop/pre-start, process 1216’
[06:09] <didrocks> RAOF: my guess is that acceleration doesn't work
[06:11] <RAOF> There's no evidence of that in the Xorg.0.log, but it's possible.
[06:14] <RAOF> But in gnome-session.log - compiz (core) - Info: Unity is not supported by your hardware. Enabling software rendering instead (slow).
[06:21] <didrocks> yeah, seems like a good hint
[06:21] <duflu> Hey that's what I was getting after updating last night :/
[06:22] <tvoss> argh, gdb in an armhf chroot is pure pain
[06:28] <tvoss> didrocks, what does the unity test script check?
[06:30] <didrocks> tvoss: if hardware acceleration is available and multiple other things
[06:30] <didrocks> tvoss: it's in nux sources, tools/
[06:30] <didrocks> but maybe duflu debugged it as he saw it
[06:30] <tvoss> didrocks, is there a log of it? I think I saw something in /tmp
[06:31] <didrocks> tvoss: just returning 0 or 1 if supported/unsupported
[06:31] <duflu> didrocks: No, I ignored the bug because it was on raring (which I assume we don't care about)
[06:31] <tvoss> didrocks, hmmm, not what I would call overly chatty :)
[06:31] <duflu> Though interestingly, the fix was to downgrade the latest lightdm update
[06:31] <didrocks> you can launch it with -p to have more logs, but you need access for that on the machine
[06:31] <didrocks> but as duflu gets it
[06:32] <didrocks> maybe he can run it to get more infos?
[06:32] <didrocks> duflu: interesting, that is a potential issue, right, latest lightdm
[06:33] <duflu> didrocks: Also, on this raring machine I am not using USC. It's plain old X. Just that the staging PPA gave me a dud update
[06:45] <dholbach> good morning
[06:48] <tvoss> didrocks, can we downgrade lightdm on the machine for testing purposes?
[06:49] <didrocks> tvoss: it's possible, will take time… time I don't have today TBH
[06:49] <didrocks> tvoss: i'm already on pressure to deliver something I didn't know that was planned for IoM as top priority
[06:49] <didrocks> tvoss: I pushed it back for the last 2 week mainly because of Mir already…
[06:49] <tvoss> didrocks, ack
[06:50] <didrocks> sil2100/jibel should be able to help though to do that
[06:50] <tvoss> didrocks, ack
[07:02]  * RAOF is sad that you can't build X with clang ☹
[07:04] <duflu> That's odd. I'm getting small amounts of graphics corruption since getting a new intel driver from staging
[07:04] <tvoss> duflu, likewise
[07:14] <tvoss> RAOF, duflu is there any way that I can try the staging ppa xserver and intel driver?
[07:15] <duflu> tvoss: Is that a trick question? You mean with the other PPA? Maybe just download the deb(s)
[07:15] <tvoss> duflu, nope, not a trick question
[07:15] <tvoss> didrocks, or can I try to switch to next for intel?
[07:16] <didrocks> tvoss: daily-build-next -> intel
[07:16] <didrocks> it's working from what the tests says
[07:17] <tvoss> didrocks, okay, will give it a spin now
[07:17] <didrocks> tvoss: keep me posted ;)
[07:17] <tvoss> sil2100, hey there
[07:17] <sil2100> Morning!
[07:26] <didrocks> hey sil2100!
[07:32] <tvoss> didrocks, apt-get dist-upgrade removes unity-common? is that okay?
[07:32] <didrocks> yep ;)
[07:34] <tvoss> didrocks, in progress
[07:35] <tvoss> alf__, ping
[07:50] <tvoss> okay
[07:50] <tvoss> no hw accel on unity
[07:58] <tvoss> didrocks, tried daily-build-next with intel, comes up but no hw-accel, flickering screen
[07:58] <didrocks> tvoss: interesting that times out on tests are so big that they pass then…
[07:59] <didrocks> tvoss: ok, so clearly either an issue with latest Xorg or lightdm
[07:59] <tvoss> didrocks, you sure?
[07:59] <tvoss> I will reenable the system-compositor-testing ppa now
[07:59] <tvoss> and compile usc and mir from current trunk
[07:59] <tvoss> that's what you essentially do, correct?
[07:59] <didrocks> tvoss: duflu mention that revering lightdm helped
[07:59] <didrocks> tvoss: yeah, you have latest usc and mir normally
[08:00] <tvoss> didrocks, ack, I will stick with the older xorg and intel driver in the testing ppa then
[08:04] <tvoss> duflu, which version of lightdm did you downgrade to?
[08:04] <duflu> tvoss: 1.7.5bzr1634raring0
[08:04] <duflu> The broken one was 1636
[08:05] <tvoss> duflu, ack and thx
[08:05] <tvoss> duflu, did you experience flickering, too?
[08:05] <duflu> tvoss: No... But then this raring machine is using plain X, not Mir
[08:05] <tvoss> duflu, ack
[08:05] <duflu> ... so that I can start new Mir servers concurrently
[08:07] <tvoss> hmmm, compiling mir trunk fails with unit-tests requiring eglCreateImageKHR
[08:07] <tvoss> I thought we had fixed that
[08:25] <duflu> back in 30
[08:27] <tvoss> duflu, ack
[08:49] <tvoss> sil2100, any luck with the unity-test script?
[08:52] <tvoss_> sil2100, ping
[08:52] <tvoss_> RAOF, ping
[08:52] <sil2100> tvoss_: still waiting for the machine to be free ;/ We might consider killing some jobs if this is urgent
[08:52] <tvoss_> sil2100, nope, no worries
[08:52] <tvoss_> any eta?
[08:53] <sil2100> Let me see how far the stupid unity testing is
[08:53] <tvoss_> sil2100, ack
[08:54] <sil2100> tvoss_: I would say around 30 minutes, since unity testing is finishing and then just some smaller jobs are queued up
[08:54] <tvoss_> sil2100, ack and thx
[08:55] <sil2100> jibel: can we somehow block the autopilot-saucy-daily_release job not to accept any new requests for a moment?
[08:56] <jibel> sil2100, stop the slave on the machine
[08:57] <jibel> sil2100, sudo stop jenkins-slave on ait
[08:57] <jibel> ati
[08:58] <jibel> sil2100, but wait until the current runs are  finished
[08:58] <jibel> as it will interrupt them
[08:59] <RAOF> tvoss_: Pong
[09:00] <tvoss_> RAOF, hey there :) I'm trying to bisect and track down why daily-build-next gives me a fucked up xmir stack
[09:00] <tvoss_> RAOF, starting with system-compositor-testing ppa, what would be next? installing mir and usc from staging?
[09:01] <RAOF> Hm. Wouldn't you install from daily-build-next?
[09:01] <RAOF> You're trying to work out the component that's broken in daily-build-next, right?
[09:03] <sil2100> jibel: thanks!
[09:03] <tvoss_> RAOF, yeah, the problem is: daily build next is completely unusable for me on intel
[09:04] <RAOF> tvoss_: And you want to find which component of daily-build-next is broken for you, so you'd install components one-by-one from there, right?
[09:04] <tvoss_> RAOF, ack
[09:06] <tvoss_> RAOF, I was wondering whether I could update X and xorg-video-intel before getting the new mir from daily-next
[09:07] <RAOF> You could, yes.
[09:08] <tvoss_> RAOF, okay
[09:09] <tvoss_> RAOF, that would work although the packaging added the xorg-xmir package?
[09:09] <RAOF> You'd need to ensure that xserver-xorg-xmir is installed, but apart from that, yes.
[09:09] <tvoss_> okay
[09:15] <RAOF> Hurray! Pixman is less annoying that I thought!
[09:15] <RAOF> Although ‘the docs are the source’ remains a less than optimal state.
[09:22] <tvoss_> RAOF, ?
[09:25] <RAOF> Oh, RegionUnion and RegionSubtract don't mind if the destination Region is the same as one of the arguments.
[09:25] <RAOF> Although it's not obvious that this is the case.
[09:26] <tvoss_> RAOF, ah
[11:54] <Walther> Any news on when mir will be enabled by default to alpha/beta?
[11:58] <tvoss> Walther, on it :)
[12:01] <tvoss_> alf__, ping
[12:02] <Walther> tvoss_: Huh? Last I checked it required adding a ppa, required open drivers instead of binary blobs for gpu, etc
[12:02] <Walther> I mean, I'm running saucy already
[12:03] <Walther> and tried manually installin mir once with catastrophic results, went back to "regular plain saucy"
[12:03] <tvoss_> Walther, yup, we are working on getting Mir and XMir into the archive right now. For binary driver support: That's not something we are targetting for 13.10, so it will be Mir/XMir on open source drivers, falling back to vanilla X on closed-source drivers
[12:03] <Walther> hm, ok
[12:04] <Walther> (I just happen to have a too new GPU that doesn't really have passable support in open drivers :/ )
[12:04] <Walther> on work computer, not an issue though
[12:04] <tvoss_> Walther, that's unfortunate
[12:05] <Walther> 7970, last time i tried, just doesn't want to cooperate on anything else than bin
[12:05] <tvoss_> didrocks_busy, I was able to come up with a somewhat usable solution from staging ppa
[12:05] <Walther> But yeah, thanks to all for doing your job, will join testing when I can
[12:06] <tvoss_> Walther, thanks :) looking forward to finally being able to support you
[12:07] <Walther> hehe
[12:07] <Walther> Also, how's the status of native apps other than demos going?
[12:07] <Walther> as in, the fallbacking to X when needed, and actual mir-supporting apps
[12:24] <tvoss_> didrocks_busy, okay, taking the intel driver from the system compositor testing ppa gets rid of the weird glitches
[12:25] <didrocks_busy> tvoss_: so, there are more fixes that were in the pipes?
[12:25] <tvoss_> didrocks_busy, I have got lightdm from system-comp testing, intel driver from system-comp testing, everything else from staging, with usc build manually
[12:26] <didrocks_busy> tvoss_: do you know the diff between u-s-c in daily-build-next and in the staging ppa,
[12:26] <didrocks_busy> ?
[12:26] <didrocks_busy> did you try to revert lightdm as well to distro? maybe it's lightdm from staging "fixing" it
[13:35] <hikiko> hi, question: what exactly is the crtc? I got an exception on trunk: "Output has no associated crtc
[13:35] <hikiko> and I was getting another flipping related one before
[13:36] <ogra_> a CRT is a tube monitor ... i would guess the last C means connector
[13:37] <hikiko> oh. it
[13:37] <hikiko> thanks ogra_ :) I didn't realize it :)
[13:38] <tvoss> mlankhorst, ping
[13:40] <mlankhorst> pong, but not a work day for me
[13:50] <tvoss_> mlankhorst, okay: I'm seeing a driver needs flags 0, nested not support in Xorg.0.log
[13:50] <tvoss_> that's for kms with the latest intel from daily-build-next
[13:51] <mlankhorst> it's not mir enabled, then..
[13:52] <mlankhorst> and if it is it'll have to wait till monday, gone
[13:58] <tvoss_> mlankhorst, thx
[15:12] <mterry> What's the state-of-art for flashing a device with a unity-mir image?  Still to flash a special saucy-preinstalled-phablet-armhf.zip ?
[15:15] <kgunn> bregma: is brandon around today?
[15:16] <bregma> he should be, but he's on left coast time so he will probably start his day within an hour or so
[15:21] <kgunn> bregma: duh! he just told me seattle yesterday...(gray hair moment)
[15:23] <bregma> kgunn, it looks like the all-important https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 may also be blocked on some issues, I'm going to file bugs for those and tag them entering-saucy
[15:23] <bregma> kgunn, if you could get that intel bug tagged, that would be great
[15:28] <kgunn> bregma: on it...yeah...sorry
[15:37] <kgunn> bregma: there now https://bugs.launchpad.net/mir/+bug/1205383
[15:37] <bregma> kgunn, thanks
[16:07] <bschaefer> kgunn, hey, i've a couple things to finish then I can help look into which rev has causing the ati issue
[16:07] <kgunn> bschaefer: thank you
[16:08] <kgunn> since you had a local card...you might be able to use that....i think you might have been on -testing ppa
[16:08] <bschaefer> kgunn, np! I've a desktop with an ATI card, in the evergreen family but I should get the info for didrocks ati machine
[16:08] <kgunn> excellent!
[16:09] <bschaefer> kgunn, yeah, also would you happen to know how to point a local built mir to get lightdm load it?
[16:09] <bschaefer> so I can start reverting trunk mir to figure out what rev caused the problems :)
[16:11] <xjunior> tvoss_: hey dude, good morning/afternoon/whatever-is-there :)
[16:12] <tvoss_> xjunior, otp, with you in a few
[16:19] <kgunn> bschaefer: honestly...i think if you build is....it tries to use your usr bins first
[16:20] <kgunn> at least i'm pretty sure...cause i fell victim one time, it wouldn't work from ppa
[16:20] <bschaefer> kgunn, alright, Ill have to dig around to how to make lightdm point to my buiild ;)
[16:20] <kgunn> but only i was broken...and yeah..oops
[16:20] <kgunn> old binary in my usr dir
[16:21] <bschaefer> right, hmm well I ll need staging, worst case I can  move it into /bin but that is reall the worst case
[16:22] <kgunn> bschaefer: might ask tvoss when he's off the phone
[16:22] <bschaefer> kgunn, sounds good, thanks!
[19:27] <smintheu> hi everybody
[19:27] <smintheu> trying to get mir to work on saucy
[19:27] <smintheu> ran into a problem that has been reported before, but i haven't found a solution yet
[19:28] <smintheu> here is my /var/log/lightdm/unity-system-compositor.log
[19:28] <smintheu> ERROR: /build/buildd/mir-0.0.6bzr848saucy0/src/server/graphics/gbm/gbm_cursor.cpp(46): Throw in function mir::graphics::gbm::GBMCursor::GBMBOWrapper::GBMBOWrapper(mir::graphics::gbm::GBMPlatform&)
[19:28] <smintheu> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
[19:28] <smintheu> std::exception::what: failed to create gbm buffer
[19:28] <smintheu> any ideas?
[19:29] <tvoss_> smintheu, are you running on ati?
[19:29] <smintheu> nvidia if i'm not mistaken
[19:29] <smintheu> lspci -v | grep "VGA compatible"
[19:29] <smintheu> 01:00.0 VGA compatible controller: NVIDIA Corporation G84GLM [Quadro FX 570M] (rev a1) (prog-if 00 [VGA controller])
[19:30] <tvoss_> smintheu, how did you install? from the testing ppa?
[19:30] <smintheu> yes
[19:32] <smintheu> I saw on launchpad that other people encountered this, and that it was supposedly fixed as of yesterday
[19:32] <smintheu> https://bugs.launchpad.net/mir/+bug/1203070
[19:32] <smintheu> if I understood correctly, it's supposed to be fixed
[19:32] <smintheu> but I still have the same problem
[19:33] <tvoss_> smintheu, the testing ppa is behind as we are busy landing in distro
[19:33] <tvoss_> smintheu, can you wait until next week?
[19:33] <smintheu> tvoss, sure, just playing around a bit
[19:33] <smintheu> tvoss, I'll give it another try next week
[19:34] <smintheu> tvoss, by landing in distro you mean that mir/xmir is going to become default in the daily builds?
[19:34] <kgunn> smintheu: that's the idea
[19:35] <smintheu> kgunn: cool. I'll give it a try again next week
[19:35] <smintheu> tvoss, kgunn: thanks for your help
[19:35] <tvoss_> smintheu, yw :)
[19:35] <bschaefer> tvoss_, sweet, confirmed it fixes the cursor issue :)
[19:36] <bschaefer> even though I assume it was already :)
[19:36] <tvoss_> bschaefer, yup
[19:36] <tvoss_> bschaefer, what are you running now?
[19:36] <tvoss_> which version exactly, which ppa?
[19:37] <bschaefer> tvoss_, I running testing, but compiled u-s-c my self
[19:37] <bschaefer> im*
[19:38] <bschaefer> though I had to remove the *.sleep  part
[19:41] <tvoss_> bschaefer, fair
[19:41] <tvoss_> bschaefer, interesting bit is actually daily-build-next
[19:41] <bschaefer> tvoss_, o the sleep binary is in that ppa?
[19:42] <tvoss_> bschaefer, it's a wrapper script
[19:42] <bschaefer> or rather what so interesting part of that ppa?
[19:42] <bschaefer> tvoss_, o well that makes more sense
[19:43] <bschaefer> o that should have the the cursor fix...hmm I wonder if I should be testing this ati card with that
[19:44] <tvoss_> bschaefer, if you can it to work, you are my hero
[19:44] <bschaefer> tvoss_, well I think thats what Im looking at today :)
[19:44]  * bschaefer installs ppa
[19:44] <tvoss_> bschaefer, first purge the testing ppa
[19:45] <bschaefer> tvoss_, thanks, almost didn't do that...
[19:48] <kgunn> bschaefer: wanna stay in here ?
[19:48] <bschaefer> kgunn, sounds good
[19:48] <kgunn> cool
[19:48] <kgunn> robotfuel: we moved :)
[19:49] <bschaefer> so i just realized chris == robotfuel...
[19:50] <kgunn> ha
[19:50] <bschaefer> haha
[19:50] <tvoss_> bschaefer, did you install the next ppa?
[19:50] <bschaefer> tvoss_, doing that right now! just got down purging and updating
[19:51] <tvoss_> bschaefer, ah :)
[19:51] <bschaefer> now upgrade with the new ppa...hopefully things don't go tooo bad
[19:53] <bschaefer> tvoss_, but looking at the ppa, theres no mir there?
[19:53] <bschaefer> and after purging the testing ppa, should I be compiling mir my self?
[19:53] <bschaefer> opps, I guess theres more then 1 page!
[19:54]  * bschaefer is not use to that many packages in a ppa
[19:54] <bschaefer> tvoss_, hmm working here
[19:55] <tvoss_> wtf? no flickering?
[19:55] <tvoss_> bschaefer, did you remove the pinning file for the testing ppa?
[19:55] <bschaefer> tvoss_, shoot
[19:56] <bschaefer> tvoss_, sorry! got your hopes up...
[19:56]  * bschaefer upgrades again
[19:56] <kgunn> how many times has each of us done that
[19:57] <bschaefer> :), now I don't feel as bad haha
[19:57] <bschaefer> kgunn, so am i expecting a crash or flickering?
[19:58] <tvoss_> bschaefer, unity not coming up
[19:58] <bschaefer> tvoss_, alright, that doesn't sound good :(, is mir still running in the background with the xserver?
[19:58] <bschaefer> or is it the server as well?
[19:58] <tvoss_> ?
[19:58] <tvoss_> usc will be running, but xmir won't start
[19:59] <bschaefer> err, so do you mean unity it self just crashes
[19:59] <bschaefer> oo alright, when I hear unity doesn't run im thinking only compiz/unity
[19:59] <tvoss_> ack
[20:03] <bschaefer> hmm i just get a "no signal" from my monitor now ... thats somewhat strange
[20:04] <tvoss_> can you ssh to the machine?
[20:05] <bschaefer> tvoss_, well I should have gotten the ip first, but yeah i can guess a few
[20:05] <bschaefer> should be 1-6...
[20:05] <bschaefer> dang, forgot to install openssh...hmm thats going to be fun
[20:05] <bschaefer> openssh-server
[20:05] <tvoss_> bschaefer failsafe mode is yourr friend
[20:07] <bschaefer> thanks, installing now, but the error I got was strange
[20:07]  * bschaefer looks at the longs
[20:07] <bschaefer> logs*
[20:08] <bschaefer> (EE) no screen founds
[20:09] <bschaefer> but that could be attempting failsafeX
[20:09] <tvoss_> bschaefer, please get the xserver-xmir deb from the mir staging ppa manually and install it manually
[20:10] <kgunn> This is a very general message telling you that something went wrong and there is no screen left which the server can successfully drive. Usually you'll see another error message describing what went wrong in more detail:
[20:10] <kgunn> EE no screen found ^ from xorg
[20:10] <bschaefer> kgunn, right, thats correct
[20:10] <bschaefer> tvoss_, hmm getting the deb manually from the staging ppa?
[20:11] <bschaefer> you mean add the ppa, and only install that package?
[20:11] <tvoss_> bschaefer, cancel that
[20:11] <bschaefer> alright, well the screen part is still true, but I can ssh into it now
[20:11] <tvoss_> bschaefer, can you check if xserver-xorg-xmir is installed?
[20:11] <bschaefer> dm_connection_start
[20:11] <bschaefer> Failed to read header
[20:11] <bschaefer> from lightdm log
[20:11] <bschaefer> tvoss_, yeah let me check
[20:12] <bschaefer> tvoss_,   Installed: 2:1.14.2-0ubuntu2+xmir1.1
[20:12] <tvoss_> ack
[20:12] <tvoss_> bschaefer, can you pastebin Xorg.0.log?
[20:13] <bschaefer> tvoss_, yup!
[20:14] <bschaefer> tvoss_,   Installed: 2:1.14.2-0ubuntu2+xmir1.1
[20:14] <bschaefer> opps
[20:14] <bschaefer> http://paste.ubuntu.com/5916056/
[20:16] <bschaefer> tvoss_, ^
[20:17] <kgunn> it wants exa ?
[20:17] <kgunn> thot that was an intel thing
[20:17] <bschaefer> on my Xorg failsafe attempt it has: [    33.829] (WW) Warning, couldn't open module vbe
[20:17] <bschaefer> instead of exa...
[20:18] <bschaefer> kgunn, it looks like it sees it doesn't exist
[20:19] <bschaefer> kgunn, err, actually ati has XAA/EXA
[20:19] <bschaefer> http://dri.freedesktop.org/wiki/ATIRadeon/
[20:20]  * bschaefer wonders if XAA would workd
[20:20] <bschaefer> work*
[20:21] <tvoss_> bschaefer, try xaa please
[20:21] <bschaefer> was just trying
[20:22] <tvoss_> bschaefer, kgunn the interesting line is https://www.google.de/search?client=ubuntu&channel=fs&q=Driver+needs+flags+0,+incompatible+with+nested,+deleting.&ie=utf-8&oe=utf-8&gws_rd=cr&ei=adryUZCXL8SBtAa9v4CQDQ#safe=off&client=ubuntu&hs=i1p&channel=fs&sclient=psy-ab&q=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&oq=%22Driver+needs+flags+0%2C+incompatible+with+nested%2C+deleting.%22&gs_l=serp.3...7152.7609.0.78
[20:22] <tvoss_> 45.2.2.0.0.0.0.78.147.2.2.0....0...1c.1.22.psy-ab..2.0.0.Umv3IgNixhE&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.49784469,d.Yms&fp=2582c0630cd1accc&biw=1316&bih=680
[20:22] <tvoss_> bschaefer, kgunn even Driver needs flags 0, incompatible with nested, deleting.
[20:23] <bschaefer> hmm it didn't seem to like my xconf file...
[20:23]  * bschaefer tries again
[20:26] <bschaefer> tvoss_, hmm but my xmir isn't even crashing, I don't think it gets that far
[20:26] <bschaefer> it does...
[20:26] <bschaefer> tvoss_, nevermind I see what you were looking at now :)
[20:30] <bschaefer> tvoss_, hmm its loading my xorg.conf but its still looking for exa and not xaa
[20:38] <tvoss_> bschaefer, kgunn hold on, looking at the source package from the next ppa, there is a conditional for xmir, translating into an XMIR preprocess define
[20:38] <tvoss_> bschaefer, kgunn looking at the ati and intel source package, there is nowhere a define of the preprocessor macro
[20:39] <kgunn> hmm
[20:39] <tvoss_> bschaefer, kgunn xorg-xserver has an xserver-xorg.h.in that will get configured and finally (hopefully) contains the define
[20:39] <bschaefer> wait so theres a define in the ppa thats replacing what?
[20:39] <tvoss_> however, the header is nowhere included in the drivers
[20:40] <tvoss_> bschaefer, kgunn so in total: I think we don't compile the x drivers for XMIR with nested support
[20:40]  * bschaefer re calls RAOF mentioning to always include a header similar to that
[20:40] <kgunn> little confused....who added the define ? is that upstream ?
[20:40]  * bschaefer greps 
[20:40] <bschaefer> tvoss_, well that would cause some problems...
[20:40] <kgunn> bschaefer: yep....recal that too
[20:41] <kgunn> header hell
[20:41] <bschaefer> preprocessor hell :)
[20:42] <tvoss_> okay guys, I'm eoding now
[20:43] <tvoss_> please keep me posted here on irc, will pick up tomorrow morning
[20:43] <bschaefer> tvoss_, alrright, have a good night sleep!
[20:43] <bschaefer> yup!
[20:43] <kgunn> good night tvoss_ see you on sunday!
[20:43] <kgunn> thanks for the prodding :)
[20:44] <bschaefer> kgunn, tvoss_ #include <xorg-config.h>
[20:45]  * bschaefer doesn't know if this is whats missing though
[20:47] <kgunn> bschaefer: hmm, digging..but it'd be in xorg patches from RAOF in his git branch i think
[20:48] <kgunn> and as tvoss indicated it should be some sort of xmir macro
[20:48] <bschaefer> so we are missing thi preprocessor define in the ati/intel source packages
[20:48] <bschaefer> that should fix everything haha...
[20:49] <kgunn> so it seems...so would need a recompile of those
[20:50] <bschaefer> yeeah, but first dig through RAOFs git branches for some defines
[20:50] <bschaefer> kgunn, do you have a link?
[20:51] <kgunn> bschaefer: i would think in here....https://github.com/RAOF/xserver
[20:51] <bschaefer> kgunn, cool, I just wasn't sure of what RAOF git account was, but I guess its RAOF :)
[20:52] <bschaefer> thanks!
[20:52] <kgunn> hmmm...don't see a mir ref in that header tho...(am i looking in the right one)
[20:53] <bschaefer> kgunn, does that xserver encompass all of intel/ati? or are those in a separate branch?
[20:54] <kgunn> bschaefer: seperate branches...same convention i think
[20:54] <bschaefer> kgunn, hmm alright, cause tvoss_ mentioned it was in the ati/intel source packages
[20:54] <kgunn> ...oop, no...they're in bzr
[20:54] <kgunn> http://unity.ubuntu.com/mir/building_source_for_pc.html
[20:55] <bschaefer> well thats also a good place to check :)
[20:59] <chjunior> kgunn, are you guys talking about https://bugs.launchpad.net/xmir/+bug/1203776 ?
[21:00] <kgunn> chjunior: yes...basically
[21:00] <kgunn> suffering too many damn channels
[21:00] <chjunior> kgunn, cool :) is there a work around?
[21:01] <kgunn> but i think there's some current thinking the sna not ready for prime time
[21:01] <bschaefer> chjunior, ChrisTownsend mentions you can downgrade your intel driver
[21:01] <chjunior> bschaefer, how can I do that exactly?
[21:02] <kgunn> so in xorg.conf set  "AccelMethod"  "uxa"
[21:02] <bschaefer> chjunior, you can do what kgunn is mentioning  (which was just tested)
[21:02] <bschaefer> or reading this comment: https://bugs.launchpad.net/xmir/+bug/1203776/comments/36
[21:03] <chjunior> bschaefer, does that prevent future updates?
[21:04] <bschaefer> chjunior, i would think the next time you upgrade it would upgrade it, but im not sure :(
[21:04] <chjunior> E: Version '2.21.9+xmir5870-0~saucy1' for 'xserver-xorg-video-intel' was not found
[21:05] <bschaefer> chjunior, :(, hmm it might have been bumped hmm, you could try what kgunn was mentioning :)
[21:05] <bschaefer> chjunior, in /etc/X11/xorg.conf
[21:05] <chjunior> yeah, I hate messing up with xorg.conf
[21:05] <bschaefer> yeeaah
[21:06] <chjunior> I'm a happier person since the last time I did it
[21:06] <bschaefer> :)
[21:07] <bschaefer> chjunior, you tried? sudo apt-get install xserver-xorg-video-intel=2:2.21.6-0ubuntu4
[21:07] <bschaefer> you'll lose mir though :(
[21:07] <chjunior> yeah
[21:08] <chjunior> that's why I did the other one
[21:08] <chjunior> If you want to keep mir: "=2.21.9+xmir5870-0~saucy1"
[21:11] <bschaefer> :(, that was the last version, as currently we are on: 2:2.21.9+xmir5870-1~saucy1
[21:13] <chjunior> yeah, and seem like there's no older version in there
[21:16] <xjunior> kgunn, bschaefer: switching to uxa worked
[21:17] <kgunn> xjunior: thanks data point 2 of success :)
[21:17] <bschaefer> xjunior, awesome :), we'll have to figure out what sna doesn't work
[21:18] <xjunior> bschaefer, kgunn: thank you guys. I have the bug here, I can help you out with anything
[21:18] <xjunior> just let me know which logs/procedures you need
[21:19] <bschaefer> xjunior, thanks :)
[21:21] <bschaefer> kgunn, so looking at this ati branch
[21:22] <bschaefer> if XMIR is not defined, we don't include a lot of things
[21:22] <bschaefer> but i don't see it defined here though
[21:22] <bschaefer> sooo something else must be defining it...
[21:22] <mlankhorst> bschaefer: xorg-server ought to define it
[21:22] <bschaefer> mlankhorst, well that make sense...
[21:22]  * bschaefer looks through there
[21:26] <bschaefer> configure.ac:1146:	PKG_CHECK_MODULES([XMIR], [mirclient], [XMIR=yes], [XMIR=no]), soo possibly we aren't enabling XMIR in daily next?
[21:27] <bschaefer> kgunn, ^
[21:27] <bschaefer> in RAOF xserver git branch
[21:27] <bschaefer> malthanks for the info :)
[21:28] <bschaefer> thanks*
[21:28] <bschaefer> http://paste.ubuntu.com/5916291/
[21:28] <bschaefer> so something is failing in here, thats setting it to false...
[21:29] <bschaefer> opps copied a bit to much...
[21:36] <kgunn> bschaefer: so its just a build/packaging bug ?
[21:36] <bschaefer> kgunn, im not sure, as I want to confirm they are missing from main possibly...
[21:36] <bschaefer> kgunn, but possibly!
[21:37] <xjunior> bschaefer, kgunn: from the package diff, in the ppa, yes
[21:37] <xjunior> the change was to default to sna instead of uxa
[21:38] <bschaefer> xjunior, we are talking about this problem with a different ppa :), sna was just enabled ( IIRC)
[21:39] <xjunior> sorry
[21:39] <bschaefer> xjunior, no worries :)
[21:39] <kgunn> xjunior: we've got a couple of moving pieces we're chasing...1 bug w/ sna....and another bug with what seems to be xmir preproc missing somehow (that bschaefer is talking about)
[21:40] <xjunior> kgunn, gotcha ;)
[21:40] <bschaefer> kgunn, should we push something to change things back to uxa, until we figure out what sna is not working atm?
[21:41] <bschaefer> kgunn, not a signal mention of mir in xserver-xorg-video-ati-7.1.0
[21:41] <kgunn> bschaefer: yeah...we probably should...
[21:41] <bschaefer> from the daily-next ppa
[21:41] <bschaefer> kgunn, so now why does xserver not think we should inculde xmir... hmm
[21:42] <mlankhorst> to the build logs..
[21:42] <bschaefer> yup, was about to try to just build xserver on my machine, but i suppose logs that exist already would be helpful :)
[21:43]  * bschaefer gets an XMIR = YES here
[21:45] <kgunn> bschaefer: ok....not sure what the hell...i swear i didn't see this earlier....
[21:45] <kgunn> https://github.com/RAOF/xserver/blob/04b01054c2f0eb020b588c976cb4c6a3fb8d867e/include/xorg-server.h.in
[21:45] <kgunn> XMIR undef in this one ^
[21:45] <kgunn> for nested
[21:45] <bschaefer> hmm strange: https://github.com/RAOF/xserver/blob/04b01054c2f0eb020b588c976cb4c6a3fb8d867e/include/xorg-server.h.in
[21:45] <bschaefer> opps
[21:45] <bschaefer> haha just copied that sorry!
[21:45] <bschaefer> kgunn, yeah I saw that...
[21:45] <bschaefer> but hmm
[21:46] <Sarvatt> its a .in, changes based on build options
[21:46] <bschaefer> kgunn, cause xorg-server read as: checking for XMIR... yes
[21:46] <bschaefer> soo XMIR is getting undefed somewhere else...
[21:46] <bschaefer> unless the ati/intel bits aren't using the right xorg from the ppa?
[21:47] <mlankhorst> or they were built before xorg-server was built in the ppa.
[21:48] <Sarvatt> try no change rebuilding the drivers that probably built before xserver with xmir did?
[21:48] <bschaefer> possibly, how could we test this? Rebuild those packages?
[21:49] <bschaefer> and it looks like xorg-server was built on 25th, and ati was on the 18th
[21:49] <bschaefer> but intel was on the 25th as well
[21:49] <bschaefer> https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+packages?batch=75&direction=backwards&start=300
[21:51] <kgunn> bschaefer: yeah...just pull from bzr build local should work right ?
[21:51] <kgunn> to prove it
[21:53] <bschaefer> kgunn, hmm well im just wondering why the apt-get source on the ati/intel doesn't give use anything mentioning xmir... i mean the source should
[21:53] <bschaefer> mention the xmir stuff either way right? (Even before its built?)
[21:54]  * kgunn wants to say true...but digging first
[21:54] <Sarvatt> forgot the deb-src line?
[21:55] <bschaefer> possibly, its almost like we aren't using RAOFs version...
[21:58] <kgunn> bschaefer: that's what i was going to dig on....
[21:58] <kgunn> i wonder...
[22:00] <bschaefer> kgunn, hmm let me double check the intel version...
[22:01] <bschaefer> kgunn, cause I just realized I might have pull the wrong source...
[22:01] <kgunn> :)
[22:02] <bschaefer> kgunn, well I did pull the wrong one, but its still wrong on the right one :)
[22:02] <kgunn> well...these bugs definitely make you neurotic
[22:02] <bschaefer> yeeaah
[22:02] <kgunn> check, double check...then check again
[22:02] <bschaefer> yeah, well its still true! whew...
[22:08] <kgunn> bschaefer: so you gotta intel_xmir.h with #if XMIR
[22:12] <bschaefer> kgunn, well  thats only included if XMIR right?
[22:13] <kgunn> now...that header, "asks" if that predefine exists and then acts on it
[22:13] <kgunn> oops/now/no
[22:14] <bschaefer> kgunn, right, but it has be defined, and XMIR doesn't exist in the apt-get source ati/intel
[22:15] <kgunn> right
[22:16] <bschaefer> kgunn, im trying to do a dget on the packge to see if the deb-src is correct...but gpg is not liking who signed it (or rather the like of...)
[22:21] <kgunn> ok...getting convinced...i think the drivers just need to be rebuilt
[22:23] <bschaefer> kgunn, yeah...how would we go about doing this :)
[22:24] <Sarvatt> looked into it a bit and its more likely the refactoring the intel dev did when RAOF switched the branch to his 2.21.12 one broke SNA to be honest, the one in the ppa did build with mir support..
[22:24] <Sarvatt> the one in daily-staging is versioned 2.21.9 but its really a 2.21.12 git snapshot from http://cgit.freedesktop.org/~ickle/xf86-video-intel/log/?h=xmir
[22:25] <Sarvatt> (can see that in configure.ac)
[22:26] <kdub> maybe once ff is over i'll restructure some android display code...
[22:27] <bschaefer> Sarvatt, hmm well doing a dget on that package Im picking up xmir stuff
[22:27] <bschaefer> but not when doing a apt-get source...
[22:36] <bregma> bschaefer, that's because you don;t have the deb-src lines set up correctly:  trust the dget
[22:38] <Sarvatt> bschaefer: it needs to be using https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup instead of https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir which it just switched to yesterday and probably never got tested..
[22:39] <bregma> Sarvatt, are you saying there's a change somewhere that needs to get reverted?
[22:40] <Sarvatt> or 3 days ago rather
[22:42] <Sarvatt> well it switched from 2.21.9 that had been tested with SNA I imagine for a long time to a branch that is a much newer git snapshot where the intel guys changed the xmir stuff around on 7/23, i'm just guessing thats where the problem started?
[22:42] <kgunn> Sarvatt: yep...i think you're right
[22:42] <kgunn> we went to head...untested
[22:42] <Sarvatt> i have no context here but i'm just seeing an obvious thing
[22:46] <bregma> bschaefer, do you feel confident about bisecting that delta when you get back from lunch?
[23:11] <bschaefer> bregma, well ill trust dget for now onwn
[23:11] <bschaefer> Sarvatt, awesome, thanks for looking into that!
[23:12] <bschaefer> bregma, how would one bisect the delta from the branches?
[23:12] <bschaefer> bregma, shouldn't we just have to point to the new one?
[23:12] <bschaefer> or take the ickles changes and merge them with RAOFs?
[23:18] <bregma> bschaefer, I would think the easiest thing is to revert to the old branch, but I'm thinking there was a reason why the newer one was used
[23:21] <bschaefer> bregma, hmm well looking at the rev, ins't the old branch the one we are using?
[23:21] <bschaefer> ie. https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir
[23:22] <bschaefer> which I thought was the old one, but we should be using this one: https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup
 bschaefer: it needs to be using https://code.launchpad.net/~mir-team/mir/xf86-video-intel-fixup instead of https://code.launchpad.net/~mir-team/mir/xf86-video-intel-vladmir which it just switched to yesterday and probably never got tested..
[23:22] <bschaefer> bregma, well... yeah that would make the fixup the old one
[23:23]  * bschaefer checks the diff of the 2
[23:24] <bregma> Ya know what, I'd feel more comfortable if RAOF could explain why the change was made, and in the mean time drop back to the xf86-video-intel-fixup version -- can you try that and test to see if it solves the problem?
[23:25]  * bregma does not want bschaefer to be working over the weekend
[23:25] <bschaefer> bregma, haha, yeah that does sound like a good approach
[23:26] <bschaefer> i've still got to make sure this ibus stuff is working as well
[23:26] <bregma> ibus will wait patiently until next week, we want mir to land as soon as possible
[23:27] <bschaefer> right, ill focus on this
[23:28] <bschaefer> hmm but I don't think this explain the ati problem :(
[23:28] <bschaefer> explains*
[23:29] <bregma> oh
[23:29] <bregma> :(
[23:30] <bschaefer> cause moving back to uxa from sna fixes this intel problem
[23:30] <bschaefer> but hmm I don't think this is going to fix the daily build problem
[23:31]  * bschaefer looks into it anyway
[23:31] <bschaefer> at lease we know something strange is going on with the packaging...
[23:52]  * bregma thinks SNA is something that requires a MAU for the token ring