/srv/irclogs.ubuntu.com/2013/12/10/#ubuntu-x.txt

RAOFmlankhorst: Time to trade SRU for mesa commits? :)01:09
Sarvattlol01:16
mlankhorstRAOF: Yeah I was blocked on that, I saw that someone replied with keithp's dri3 branch, which supposedly did the same thing07:29
mlankhorstbut looking at it didn't show up any conflicting commits, which puzzled me07:30
mlankhorstat least nothing that conflicted on first sight07:31
RAOFmlankhorst: 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:35
mlankhorstah07:38
mlankhorstbut I didn't see it in that commit list any more for the dri3 branch, hm07:38
RAOFIt 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:40
mlankhorstperhaps07:42
mlankhorstRAOF: I'll try to grab the patches again, see if they apply and compile07:45
RAOFPretty sure they do. I don't *think* I touched them on my recent rebasefest.07:46
mlankhorstthere's 2 v3 of one commit too, what one do I take? :p07:48
mlankhorsthm guess I'll try the newest one07:54
RAOFOh, really? Which patch has 2 v3s?07:55
mlankhorstsupport dri image version 707:57
mlankhorsthm they're identical08:29
mlankhorstjust why would you send it twice :o08:29
RAOFI don't know. They're offset by significant times, too.08:36
RAOFMaybe one got eaten in processing for a while?08:36
mlankhorstprobably08:41
mlankhorstRAOF: 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 :p08:42
RAOF:)08:42
RAOFOh!08:42
RAOFHas {r300,r600,radeonsi}/drm_target.c moved between patch submission and now?08:43
RAOFIs that the failing hunk?08:43
mlankhorstnah08:45
mlankhorstwas some va_size that got removed08:45
RAOFAh, coolio.08:45
mlankhorstok, trying build08:50
mlankhorstok it compiles, I guess that's all I can ask for08:53
RAOFOh. *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
RAOFmlankhorst: There's a piglit test available!08:53
mlankhorsttoo late :p08:53
RAOFmlankhorst: Ta muchly08:56
mlankhorstmir patch didn't apply and it failed at installing to debian/tmp stage somewhere, 09:08
mlankhorstbut shrug09:08
tjaaltonmlankhorst: commit the arm fix to d-exp too09:15
tjaaltonor was that on ubuntu only09:15
mlankhorston ubuntu only for now09:15
mlankhorstour packaging diverges a lot there09:16
tjaaltonah ok09:16
tjaaltonyeah I guess jcristau would have spotted the failure too :)09:16
mlankhorstoh actually it should fail on their packaging too. :P09:16
tjaaltonyeah looks like it09:18
jcristaui won't spot arm failures until they hit the buildds09:20
jcristauno arm kit here :)09:20
tjaaltonI tried to find build logs yesterday but couldn't find any for mesa 1009:21
tjaaltonbut yeah guess they do take some time..09:21
mlankhorstjcristau: http://paste.debian.net/70096/ does this look good?09:22
RAOFmlankhorst: I've almost got the mir bit done; I've just realised why i965 dies on it.09:22
mlankhorsthm I guess I should merge it and have it inside confflags_GALLIUM below..09:23
jcristautjaalton: mesa 10 is in debian NEW09:23
jcristauso no logs yet09:24
tjaaltonoh right09:24
mlankhorstjcristau: http://paste.debian.net/70097/ v209:25
jcristaumlankhorst: not quite sure if building radeon stuff on arm makes much sense09:25
mlankhorstjcristau: well .. we already do it anyway :P09:25
mlankhorstand lynxeye already had nouveau working on a tegra board with pci-e09:26
mlankhorstgranted, the leak current of the nvidia card was probably higher than the entire tegra board itself, but still!09:26
jcristauneed more context to understand v2.  too many conditionals in that makefile.09:29
* jcristau tries to find a mesa checkout09:29
mlankhorstoh  wait, i915/i965 is used outside linux right?09:31
jcristauyes09:40
jcristaui was just about to say that09:40
jcristauneed to still build them on kbsd09:40
RAOFI win!09:42
mlankhorstcongratulations, you win a mir display09:43
jcristauthat sounds like losing09:47
mlankhorstjcristau: http://paste.debian.net/70098/ hm this better?09:54
jcristauyou lose the extra_sed thing, is that on purpose?09:57
mlankhorstyeah09:57
mlankhorstlibllvmradeon.so no longer exists09:57
mlankhorstso it was a leftover in debian/rules09:57
tjaaltonconfusing to remove it on the same commit09:57
mlankhorstthis is the diff I have. :P09:58
mlankhorstdidn't commit anything yet09:58
jcristauin that case also remove the use of EXTRA_SED :)09:58
mlankhorstah right09:59
mlankhorstRAOF: hm mir was broken with mesa 10?10:19
RAOFmlankhorst: When switching to using gbm for the nested stuff, I think.10:22
mlankhorstoh :p10:23
mlankhorstdidn't check nested10:23
=== debfx_ is now known as debfx
mlankhorstRAOF: 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 work11:23
mlankhorstguess I will11:50
RAOFmlankhorst: Yeah, we do like to keep upgrades working :)12:25
mlankhorstok 12:25
mlankhorsttestbuild in ppa seems to work12:25
mlankhorstpixman_0.30.2-1ubuntu0.0.0.0.1_source.changes12:37
mlankhorstweee12:37
tjaaltonjollas available tomorrow.. bah. no benefit in preordering it other than getting a free cap13:51
tjaaltonwhich should arrive some time next week13:51
mdeslaurmlankhorst: you just overwrote my previous xorg-server changes14:20
mlankhorstoh :P14:21
mlankhorstsorry14:21
mdeslaurmlankhorst: np, can you fix it?14:21
mlankhorstsure14:22
mdeslaurmlankhorst: cool, thanks!14:22
=== jono is now known as Guest63303
mdeslaurso...looking at http://nvidia.custhelp.com/app/answers/detail/a_id/337721:34
mdeslaurseems there are new 331 319 and 304 drivers21:34
mdeslaurbut, I'm looking at the zillion packages we have to update in the archive21:34
mdeslaurwhat do we do with the 310 and 313 packages?21:34
mdeslaurupdate them to 319?21:34
mdeslaurleave as-is without telling the user they have a security issue?21:35
mlankhorstit's fairly theoretical23:02
mlankhorstwell it's still a gaping security hole but not everyone could exploit it ;)23:03
mlankhorstmdeslaur: hm23:04
mlankhorstThe 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 interfac23:04
mlankhorstMarcin Koƛcielnicki 23:05
mlankhorstsounds like it could be fun to figure out :P23:05
mlankhorstmdeslaur: I guess nouveau developers could figure it out, but anyone else is going to have to try a lot harder23:11
mlankhorstmdeslaur: but tseliot knows the nvidia binary drivers better than I do, ask him ;)23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!