[04:16] <Sarvatt> cnd: is there any way i can help with the input backport? would it make it easier to have an updated ubuntu+1 branch in git thats updated with later 1.11 stuff and actually builds? do you think it's a realistic goal still? I feel like its getting too late atm because peoples worlds could possibly be broken and they expect precise to have no problems but it might be totally unfounded :)
[04:19] <Sarvatt> RAOF: we need a non-virtualized ppa to pocket copy to the archive dont we? how does that happen? it needs to builds on arm/armhtf/powerpc on top of what ppas build for im sure dto do the binary copy
[04:20] <Sarvatt> to do the abi transition in a ppa so things arent broken
[04:25] <Sarvatt> doing the whole transition in a ppa and copying to the archive will break armhf/armel/powerpc because the xserver-xorg-dev requirements wont be bumped to let it depwait then rebuild for most stuff and will be rebuilt against the wrong abi i imagine on those arches
[05:52] <RAOFer> Sarvatt: Yeah, I guess we will need a non-virtualised PPA.
[05:52] <Sarvatt> RAOFer: got a ppa in mind?
[05:53] <Sarvatt> can see if i can get one non-virtualized so stuff builds on all arches
[05:54]  * Sarvatt will file an rt ticket
[05:54] <RAOFer> Ta muchly.
[05:55] <Sarvatt> point me at a ppa, dont think ubuntu-x-xswat/x-updates makes much sense because we put other stuff there
[05:55] <Sarvatt> x-testing?
[05:57] <RAOFer> We should probably make a new one; x-staging
[05:58] <RAOFer> Hm.  But I seem to have forgotten how to actually create a new PPA :)
[05:58] <Sarvatt> done, cool beams
[05:59] <Sarvatt> beans too
[05:59] <Sarvatt> https://launchpad.net/~ubuntu-x-swat/+archive/x-staging :)
[05:59]  * RAOFer was imagining a cooling laser.
[05:59] <RAOFer> Sarvatt: Have you found i915/GM45 unstable on Precise recently?
[05:59] <Sarvatt> on precise? no
[06:00] <Sarvatt> on intel 2.17.0/libdrm 2.4.28 which i held off updating because of the bugs yeah :)
[06:00] <Sarvatt> 3.2 problem?
[06:00] <RAOFer> Maybe.
[06:00] <RAOFer> It seems to like kernel oopsing.
[06:02] <Sarvatt> gotta admit i havent paid attention to my only machine in those specs with precise userspace so im not sure
[06:03] <RAOFer> :)
[06:04] <Sarvatt> i've been hitting an oom problem on everything else with git userspace
[06:04] <Sarvatt> sandybridge/ivybridge
[06:04] <RAOFer> Hm.  Did that cause it to oops somewhere in drm_mm_foo?
[06:05] <Sarvatt> no no oops it always triggered corruption and gigabyte+ /var/log/Xorg.0.logs full of repeating messages of oom errors
[06:06] <RAOFer> Bah!
[06:06] <RAOFer> Stupid oopses, making writing to disc silently fail!
[06:07] <RAOFer> I'm all like "Hah!  I shall dmesg > the-damn-thing-OOPSed.log and come back to it later".
[06:07] <RAOFer> And then later it's all like "I don't know what you're talking about officer"
[06:22] <RAOF> cnd: Yeah, if you'd like an updated ubuntu+1 branch give a hoy.  It should build as it stands, though :)
[06:23] <Sarvatt> i dont think it builds, patch 221?
[06:23] <Sarvatt> or 220
[06:24] <Sarvatt>         drop 210_pixman_null_ptr_check.patch fails
[06:24] <Sarvatt>         drop 220_xi21_always_deliver_raw_events.diff fails
[06:24] <Sarvatt> 220 still enabled and doesnt work, 210 fails with later x 1.11 checkouts
[06:24] <RAOF> Hm.
[06:26] <Sarvatt> RAOF: sooo, https://launchpad.net/~ubuntu-x-swat/+archive/x-staging *should* build all arches now :)
[06:26] <RAOF> Nice.
[06:26] <Sarvatt> that was surprisingly easy
[06:27] <Sarvatt> easy enough where if we upload something and it doesn't trashing it and making another would be trivial
[06:28]  * Sarvatt didn't file any rt tickets
[06:29] <Sarvatt> boss disabled the "virtual builders" requirement on the ppa, i'm not sure if that does what we want but sounds right
[06:29] <RAOFer> It does, doesn't it.
[06:42] <Sarvatt> roll around on fire er?
[06:43] <RAOF> *Run* around on fire, thank you! :)
[06:43] <Sarvatt> wait RAOF is on a canonical IP, ya using a canonical server as a bouncer?
[06:44] <RAOF> Yup.
[06:44] <Sarvatt> WHAT!
[06:44] <Sarvatt> which? :)
[06:44] <RAOF> A canonistack instance.
[06:44] <Sarvatt> ohh gotcha
[06:45] <RAOF> Running a shiny new smuxi instance.
[06:46] <RAOFer> Bah.
[06:46] <RAOFer> Bye bye, GM45.
[06:46] <RAOFer> This, by the way, is why there's a RAOFer.
[06:47] <RAOFer> It won't even have dropped any useful debugging info to disc.
[06:47] <RAOFer> Stupid thing!
[06:48] <Sarvatt> sorry in advance becuase it was the libdrm 2.4.27 upgrade that caused it
[06:48]  * Sarvatt TIL
[06:48] <RAOFer> Oh, 2.4.27 is to blame?
[06:49] <Sarvatt> that was like the only change outside of the kernel between precise and oneiric
[06:49] <RAOFer> Yeah, but the kernel freezing hard is ultimately a kernel problem :)
[06:50] <Sarvatt> 3.0 is so darn good for drm at this point, i'm still living on it
[06:51] <Sarvatt> sent 6 commits to stable in the past 2 weeks, all the good stuff without the pain :)
[06:51] <Sarvatt> ivybridge is great on 3.0 now, 3.2 is all kinds of screwed up
[06:51] <RAOFer> Heh.
[06:56] <Sarvatt> intel guys are living in 3.3 and dont send stuff to stable, 3.2 is kinda in limbo until it releases from what i see but thats very opinionated
[06:58] <Sarvatt> stuff cced to stable now is whats supposed to go into 3.2 even if 3.2 isnt a stable release
[07:21] <tjaalton> hmm, fedora17 will drop dri1 drivers
[07:22] <tjaalton> not a huge surprise, just an observation
[07:24] <tjaalton> actually, we'll have that for precise too, since upstream has dropped them from 8.0 :)
[07:25] <RAOFer> Yup
[07:27] <Sarvatt> tjaalton: rhel 7 wont though? :P
[07:27] <tjaalton> Sarvatt: that's years off :)
[07:27] <tjaalton> so likely will
[07:28] <Sarvatt> tjaalton: recovered from the concert now? :)
[07:29] <tjaalton> Sarvatt: hehe, yeah.. was great :)
[07:29] <tjaalton> we drove there, so only had one beer there
[07:31] <tjaalton> RAOFer: so is there something packaging wise I could do to help get the new stack in precise?
[07:31] <Sarvatt> which new stack?
[07:31] <RAOFer> 1.11
[07:31] <RAOFer> I presume.
[07:31] <tjaalton> that
[07:31] <Sarvatt> mesa 7.11?
[07:31] <Sarvatt> oh ok
[07:31] <tjaalton> well mesa too
[07:31] <Sarvatt> yea i feel the same way
[07:31] <tjaalton> actually I could test mesa master on the sis crap
[07:32] <tjaalton> if llvmpipe is any faster 
[07:32] <Sarvatt> mesa's gonna need some love with the new source package shipping dri1 drivers from 7.11 crap
[07:32] <RAOFer> Won't the answer be "We killed DRI1, suckas!"
[07:32] <tjaalton> Sarvatt: no way, drop dri1 i say
[07:32] <tjaalton> :)
[07:32] <Sarvatt> they're going out of their way to still support dri1 drivers even though they are dropped from 8.0..
[07:33] <Sarvatt> even if fedora wont rhel will later
[07:33] <RAOFer> Maybe.
[07:33] <tjaalton> in practice though, they haven't really been supported for years
[07:34] <RAOFer> To what extent do the existing DRI1 drivers actually run GNOME3 or Unity?
[07:34] <tjaalton> and seems like fedora/rhel7 will put effort in making llvmpipe more capable
[07:34] <tjaalton> RAOFer: they don't, llvmpipe supports opengl 2.x so it's better
[07:35] <Sarvatt> to what extent do they play openarena or use blender better than swrast? lots..
[07:35] <Sarvatt> if you're using that old crap llvmpipe doesnt really help
[07:35] <RAOFer> The fact that they don't support GNOME3 or Unity means that, at best, they're not well supported.
[07:35] <RAOFer> Yeah, llvmpipe doesn't really scream "make old hardware more usable" to me.
[07:35] <tjaalton> well, if you're using old crap they are still crap no matter which driver you use :)
[07:36] <Sarvatt> who sticks a sis in a system that doesnt support sse2 where llvmpipe is faster
[07:36] <tjaalton> Sarvatt: who runs openarena on one?
[07:36] <Sarvatt> very true :)
[07:36] <tjaalton> the point is likely just "get a session going"
[07:37] <Sarvatt> like mga has been busted on compiz for years
[07:39] <Sarvatt> i dont think it ever passed the unity check though but thats unrelated, having accelerated 3d regardless of using unity-2d would be helpful in some situations
[07:41] <RAOF> Yeah, it's kinda helpful.
[07:42] <RAOF> It's a "we won't do anything to deliberately break it" kinda helpful, though.
[07:42]  * RAOF → birthday dinner.
[07:45] <Sarvatt> so like airlied and ajax were the ones making sure the dri1 interface works still at the time, i really think it'd be work packaging 7.11 dri drivers even if i do it, no worries
[07:45] <Sarvatt> birthday?! happy birthday RAOF!
[07:46] <Sarvatt> or happy birthday to the person you are celebrating for if i misunderstood :)
[07:48] <tjaalton> http://fedoraproject.org/wiki/Features/DRI2DriversOnly
[07:49] <tjaalton> that suggests that having dri1 drivers around would need "very convincing arguments"
[08:11] <LetoThe2nd> good morning! is there a known reason why powering off (e.g. unplugging) the screen will cause the xserver to crash?
[08:12] <jcristau> power off != unplugging.  in any case, if X crashes, that's what they call a bug.
[08:13] <LetoThe2nd> jcristau: i mean hard power off, not pressing the standby button. the x stays alive when i just do that.
[10:16] <RAOFer> Bah.  i915!!!!!!
[10:17]  * RAOFer suddenly realises why other people really hate it when the graphics stack is unstable.
[10:22] <garaman> RAOFer: I'm here hoping to hear news about the random lag I get with Nvidia drivers in Unity (Quadro NVS 290 in TwinView)
[12:48] <sil2100> Hi!
[12:50] <sil2100> I'm a complete X newbie and I would need some help, since I need this for preparing a specific package
[12:50] <sil2100> Is there a way I could get info about the xserver current video ABI on the system?
[12:51] <sil2100> In the past, around natty, there was that videoabiver file which is now deprecated
[12:51] <sil2100> But in the newer versions?
[12:51] <sil2100> I would be grateful for some pointers
[12:51] <jcristau> what are you trying to do?
[12:54] <sil2100> I need my package to install selected binary drivers basing on the ABI version
[12:54] <sil2100> Since there's a different driver version for every ABI
[12:54] <jcristau> ewww.
[12:55] <sil2100> Yep, I was thinking the same thing
[12:55] <sil2100> ;)
[13:36] <inetpro> hi
[13:38] <inetpro> anybody willing to look at my nVidia GT215 bug on launchpad? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436
[13:38] <ubot4> Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 11)" [Undecided,New]
[13:46] <tjaalton> inetpro: try a mainline kernel, for instance this one http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc4-oneiric/
[13:46] <tjaalton> and get rid of nvidia before booting it
[13:46] <tjaalton> the driver, that is
[13:48] <inetpro> tjaalton: you mean that as a temporary solution?
[13:51] <inetpro> or do you mean I should test that to confirm whether this new kernel fixes it?
[13:52] <inetpro> sorry, I may be a bit new to your processes of troubleshooting it
[13:52] <tumbleweed> the latter
[13:52] <inetpro> ahh
[13:53] <inetpro> to be honest I don't have the laptop with me right now but will try that in a few hours time
[13:55] <tjaalton> yes, the driver is in the kernel
[13:55] <inetpro> cool, I'll let you know how it goes later
[13:56] <inetpro> and then I guess I should also try precise alpha / daily CD
[13:57] <tjaalton> it has the same kernel
[13:57] <inetpro> I hope that kernel is in there as well?
[13:57] <inetpro> ahh
[13:57] <inetpro> sounds great
[13:57] <tjaalton> you can just try the live image and report back
[13:57] <inetpro> thanks tjaalton
[14:15] <FernandoMiguel> boa tarde 
[15:27] <cnd> RAOF, I'm currently trying to create a patchset for backporting xserver input subsystem master into 1.11
[15:27] <cnd> just fyi
[22:10] <RAOF> cnd: Sweet.  Anything I can do for you?
[22:12] <cnd> RAOF, let me go through what I'm trying to do
[22:12] <cnd> my idea is: backport everything that is input related from master on top of the 1.11 stable branch
[22:13] <cnd> I started doing that, but found one general API/ABI break: options parsing
[22:13] <cnd> so I left that out
[22:13] <cnd> I now have a branch with a backported server
[22:13] <cnd> I'm going to make sure it compiles and runs
[22:14] <cnd> and then I'll package it up and push it to ppa:utouch-team/xorg-unstable
[22:14] <cnd> I'm going to assimilate things in there
[22:15] <RAOF> And then I'll pull those patches onto ubuntu+1, push it into the staging PPA, and rebuild the world against it.
[22:15] <RAOF> ?
[22:15] <cnd> that's one possibility
[22:15] <cnd> I don't want to be redoing work twice unnecessarily
[22:15] <cnd> but I don't know how I can do everything we need for the input side without being the one who brings up the server for precise
[22:16] <RAOF> Yes!
[22:16] <cnd> RAOF, have you made any changes to the server packaging or added patches in your 1.11 tree?
[22:17] <RAOF> No; just the forward ports of input stuff.
[22:17] <RAOF> Locally, because they don't work properly :)
[22:17] <RAOF> Oh, and I've pulled in a more recent merge from Debian.
[22:18] <cnd> ok
[22:18] <cnd> so I'm going to try to bring up the xserver today and tomorrow
[22:18] <cnd> make sure input modules work
[22:19] <cnd> and try out running with the binary nvidia and fglrx drivers that are already released for 1.11
[22:19] <cnd> I assume they are already released...
[22:19] <RAOF> They are, yes.
[22:19] <RAOF> I'm perfectly happy for you to bring up the server for precise; we'll be staging it in https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
[22:20] <cnd> I'm off from the 15th through the 19th, so hopefully I'll have things in a state where you can work with it
[22:20] <cnd> RAOF, perhaps I'll bring up the server without XInput multitouch first
[22:20] <cnd> and push it to the x-staging ppa
[22:20] <cnd> and keep the multitouch stuff in the utouch-team/xorg-unstable branch for now
[22:21] <cnd> sound good to you?
[22:21] <ricotz> oh :)
[22:21] <RAOF> That seems fine to me; the x-staging server will have the rest of the 1.12 input stack, though?  Just not the multitouch work?
[22:22] <cnd> yeah
[22:22] <ricotz> cnd, hi, are all input patches you are backporting in xserver master already?
[22:22] <cnd> ricotz, everything I have backported so far are, yes
[22:22] <cnd> it doesn't include any of the XI 2.2 multitouch patches
[22:22] <RAOF> cnd: Would you like widespread (ie: pushing to the distro) testing of that, before adding multitouch?  Does Unity work without multitouch yet?
[22:22] <ricotz> cnd, ok
[22:23] <cnd> RAOF, if unity doesn't work without multitouch yet, please ping bregma and/or DBO
[22:24] <cnd> pushing the server to distro without multitouch would be really helpful, but only after it has soaked in x-staging for a bit and we have covered all the main modules
[22:25] <RAOF> We wouldn't push the server from x-staging to the distro until everything's been built against it.  Then we'll pocket-copy.
[22:26] <cnd> ok