[01:09] <RAOF> mlankhorst: Time to trade SRU for mesa commits? :)
[01:16] <Sarvatt> lol
[07:29] <mlankhorst> RAOF: Yeah I was blocked on that, I saw that someone replied with keithp's dri3 branch, which supposedly did the same thing
[07:30] <mlankhorst> but looking at it didn't show up any conflicting commits, which puzzled me
[07:31] <mlankhorst> at least nothing that conflicted on first sight
[07:35] <RAOF> mlankhorst: IIRC keithp's dri3 branch contains an implementation for nouveau (which might even by *your* implementation for nouveau, can't remember), and will fail on everything else.
[07:38] <mlankhorst> ah
[07:38] <mlankhorst> but I didn't see it in that commit list any more for the dri3 branch, hm
[07:40] <RAOF> It also got pointed out on the list that my patch series was more complete, and had been hanging around since April or so; keithp may have removed the partial work from his branch?
[07:42] <mlankhorst> perhaps
[07:45] <mlankhorst> RAOF: I'll try to grab the patches again, see if they apply and compile
[07:46] <RAOF> Pretty sure they do. I don't *think* I touched them on my recent rebasefest.
[07:48] <mlankhorst> there's 2 v3 of one commit too, what one do I take? :p
[07:54] <mlankhorst> hm guess I'll try the newest one
[07:55] <RAOF> Oh, really? Which patch has 2 v3s?
[07:57] <mlankhorst> support dri image version 7
[08:29] <mlankhorst> hm they're identical
[08:29] <mlankhorst> just why would you send it twice :o
[08:36] <RAOF> I don't know. They're offset by significant times, too.
[08:36] <RAOF> Maybe one got eaten in processing for a while?
[08:41] <mlankhorst> probably
[08:42] <mlankhorst> RAOF: hm, the nouveau patch failed to apply, i fixed it up. the radeon one fails with one hunk too, but it seems that one can be ignored :p
[08:42] <RAOF> :)
[08:42] <RAOF> Oh!
[08:43] <RAOF> Has {r300,r600,radeonsi}/drm_target.c moved between patch submission and now?
[08:43] <RAOF> Is that the failing hunk?
[08:45] <mlankhorst> nah
[08:45] <mlankhorst> was some va_size that got removed
[08:45] <RAOF> Ah, coolio.
[08:50] <mlankhorst> ok, trying build
[08:53] <mlankhorst> ok it compiles, I guess that's all I can ask for
[08:53] <RAOF> Oh. *That's* why the Mir platform bombs when I try to update it - intel preferentially calls image_get_buffers if it's non-null, and gbm always defines image_get_buffers, but returns 0 if the implementation hasn't defined that.
[08:53] <RAOF> mlankhorst: There's a piglit test available!
[08:53] <mlankhorst> too late :p
[08:56] <RAOF> mlankhorst: Ta muchly
[09:08] <mlankhorst> mir patch didn't apply and it failed at installing to debian/tmp stage somewhere, 
[09:08] <mlankhorst> but shrug
[09:15] <tjaalton> mlankhorst: commit the arm fix to d-exp too
[09:15] <tjaalton> or was that on ubuntu only
[09:15] <mlankhorst> on ubuntu only for now
[09:16] <mlankhorst> our packaging diverges a lot there
[09:16] <tjaalton> ah ok
[09:16] <tjaalton> yeah I guess jcristau would have spotted the failure too :)
[09:16] <mlankhorst> oh actually it should fail on their packaging too. :P
[09:18] <tjaalton> yeah looks like it
[09:20] <jcristau> i won't spot arm failures until they hit the buildds
[09:20] <jcristau> no arm kit here :)
[09:21] <tjaalton> I tried to find build logs yesterday but couldn't find any for mesa 10
[09:21] <tjaalton> but yeah guess they do take some time..
[09:22] <mlankhorst> jcristau: http://paste.debian.net/70096/ does this look good?
[09:22] <RAOF> mlankhorst: I've almost got the mir bit done; I've just realised why i965 dies on it.
[09:23] <mlankhorst> hm I guess I should merge it and have it inside confflags_GALLIUM below..
[09:23] <jcristau> tjaalton: mesa 10 is in debian NEW
[09:24] <jcristau> so no logs yet
[09:24] <tjaalton> oh right
[09:25] <mlankhorst> jcristau: http://paste.debian.net/70097/ v2
[09:25] <jcristau> mlankhorst: not quite sure if building radeon stuff on arm makes much sense
[09:25] <mlankhorst> jcristau: well .. we already do it anyway :P
[09:26] <mlankhorst> and lynxeye already had nouveau working on a tegra board with pci-e
[09:26] <mlankhorst> granted, the leak current of the nvidia card was probably higher than the entire tegra board itself, but still!
[09:29] <jcristau> need more context to understand v2.  too many conditionals in that makefile.
[09:29]  * jcristau tries to find a mesa checkout
[09:31] <mlankhorst> oh  wait, i915/i965 is used outside linux right?
[09:40] <jcristau> yes
[09:40] <jcristau> i was just about to say that
[09:40] <jcristau> need to still build them on kbsd
[09:42] <RAOF> I win!
[09:43] <mlankhorst> congratulations, you win a mir display
[09:47] <jcristau> that sounds like losing
[09:54] <mlankhorst> jcristau: http://paste.debian.net/70098/ hm this better?
[09:57] <jcristau> you lose the extra_sed thing, is that on purpose?
[09:57] <mlankhorst> yeah
[09:57] <mlankhorst> libllvmradeon.so no longer exists
[09:57] <mlankhorst> so it was a leftover in debian/rules
[09:57] <tjaalton> confusing to remove it on the same commit
[09:58] <mlankhorst> this is the diff I have. :P
[09:58] <mlankhorst> didn't commit anything yet
[09:58] <jcristau> in that case also remove the use of EXTRA_SED :)
[09:59] <mlankhorst> ah right
[10:19] <mlankhorst> RAOF: hm mir was broken with mesa 10?
[10:22] <RAOF> mlankhorst: When switching to using gbm for the nested stuff, I think.
[10:23] <mlankhorst> oh :p
[10:23] <mlankhorst> didn't check nested
=== debfx_ is now known as debfx
[11:23] <mlankhorst> RAOF: oh btw for libdrm/pixman sru do I need to update quantal and raring or not? To make upgrading from precise to quantal and raring work
[11:50] <mlankhorst> guess I will
[12:25] <RAOF> mlankhorst: Yeah, we do like to keep upgrades working :)
[12:25] <mlankhorst> ok 
[12:25] <mlankhorst> testbuild in ppa seems to work
[12:37] <mlankhorst> pixman_0.30.2-1ubuntu0.0.0.0.1_source.changes
[12:37] <mlankhorst> weee
[13:51] <tjaalton> jollas available tomorrow.. bah. no benefit in preordering it other than getting a free cap
[13:51] <tjaalton> which should arrive some time next week
[14:20] <mdeslaur> mlankhorst: you just overwrote my previous xorg-server changes
[14:21] <mlankhorst> oh :P
[14:21] <mlankhorst> sorry
[14:21] <mdeslaur> mlankhorst: np, can you fix it?
[14:22] <mlankhorst> sure
[14:22] <mdeslaur> mlankhorst: cool, thanks!
=== jono is now known as Guest63303
[21:34] <mdeslaur> so...looking at http://nvidia.custhelp.com/app/answers/detail/a_id/3377
[21:34] <mdeslaur> seems there are new 331 319 and 304 drivers
[21:34] <mdeslaur> but, I'm looking at the zillion packages we have to update in the archive
[21:34] <mdeslaur> what do we do with the 310 and 313 packages?
[21:34] <mdeslaur> update them to 319?
[21:35] <mdeslaur> leave as-is without telling the user they have a security issue?
[23:02] <mlankhorst> it's fairly theoretical
[23:03] <mlankhorst> well it's still a gaping security hole but not everyone could exploit it ;)
[23:04] <mlankhorst> mdeslaur: hm
[23:04] <mlankhorst> The PGRAPH context switch microcode allows user to read/write arbitrary MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory. Why did nVidia include such obviously security-breaking functionality in the firmware images? As I understand it, a user having access to just the FIFO submission interfac
[23:05] <mlankhorst> Marcin Kościelnicki 
[23:05] <mlankhorst> sounds like it could be fun to figure out :P
[23:11] <mlankhorst> mdeslaur: I guess nouveau developers could figure it out, but anyone else is going to have to try a lot harder
[23:40] <mlankhorst> mdeslaur: but tseliot knows the nvidia binary drivers better than I do, ask him ;)