[06:02] morning [06:03] Yo yo! [06:03] no luck yet, did manage to scan for all storage modes yesterday and rediscovered some missing in the enumeration :P [06:04] need something else to do for today, any suggestions? [06:04] nouveau bugs? :) [06:05] I mean, something not nouveau so I can focus my mind on something else then try with fresh view in a few days [06:05] server bugs then [06:06] Yeah, server bugs are often good. [06:06] hm, do we have that evdev and synaptics memory corruption sru'd yet? [06:07] it's not in quantal even [06:07] i think [06:07] yikes [06:07] no wait [06:07] different thing maybe [06:14] What was the synaptics memory corruption? [06:14] Dear mesa: kindly build, love, Chris.\ [06:15] RAOF: 8.0.3? builds here [06:15] or built [06:15] 8.1 [06:15] ahh [06:15] no comments [06:15] RAOF: the one where X dies a slow death, or sudden death on unplug :) [06:16] I think the -evdev one which was that got accepted, didn't it? [06:16] was it the silent abi change? [06:16] yeah might, but basically all patches from xf86-input-synaptics 1.6.2 [06:16] or where it looked like one [06:17] I *think* it ended up being miscompiled code on i386 under certain circumstances? [06:17] yeah that [06:18] tjaalton: Incidentally, do you have any idea what 101_mesa_hidden_glname.patch is *for* ? [06:20] RAOF: do we have plans to sru synaptics 1.6.3 yet? haven't seen any reports of regressions in quantal with it [06:21] It's not on my TODO list; this is something that you could usefully do today, if you wanted :) [06:24] i want to move synaptics to 1.6.2 first, since it basically is. Only thing lacking is the 2 version changing commits. [06:25] RAOF: looks like we've lost all the history before 8.0-rc2.. [06:26] oh it goes way back [06:26] tjaalton: The earliest reference I can find to it is in your changelog from 7.1~rc1 [06:27] Although you don't seem to have known what it did then :) [06:27] neither did kyle mcmartin five years ago [06:27] in 6.5.3-1u1 [06:29] so, DEP-3 has a true purpose :P [06:29] drop it for quantal ? :> [06:30] As far as I can tell that would break ABI by hiding a symbol that was previously unhidden. [06:31] On the other hand, I have absolutely no idea what anyone would *do* with that symbol. [06:36] http://old-releases.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_6.5.1~20060817-0ubuntu3.diff.gz [06:36] back in the golden days there was no patch-system.. [06:36] being used [06:37] ah, not true. but that change was done directly to the source it seems.. [06:37] later than in dapper? [06:40] looks like I put that in a patch Feb 21st '07 [06:41] and no comment about why it was there [06:42] mlankhorst: right, it was introduced in edgy [06:42] but reading between the changelog lines.. [06:42] might just as well been a temporary hack that remained in the package [06:47] It doesn't do anything to x86-64. I think we can probably drop it in quantal and see if anything explodes. I don't think it will. [06:48] yeah [07:02] well, i ran dapper fine without it ;) [07:19] You know what would be *totally awesome*? If make wasn't saying “no target to make depend”. [07:28] didn't it use 'makedepend' ? :P [07:34] Ah, no. [07:35] It turns out that if makedepend doesn't work, it says “No rule to make target depend” [07:35] Because it's GODDAMNED RIDICULOUS, that's why. [07:39] RAOF: btw I'm still RE'ing even if to the casual observer it may look like I'm preparing synaptics 1.6.2 (just a version bump, we already have all the patches) [07:39] If we've already got all the patches why are we getting the version bump? [07:41] RAOF: shrug, there will probably be a new release at one point, i need to get my mind off reverse engineering for a bit so I can subconsciously process information and think of things you cant when staring too long :) [07:41] Fair enough :) [07:43] plus it was just merging debian and dropping the patches-that-were-commits series [07:49] Fair enough. [07:52] Mmm. Hardlinks. [07:52] JUST TO MAKE IT MORE DIFFICULT. [07:54] 'thou shalt not built from tmpfs with package on a real fs'? [07:55] No, in this case “be careful when editing files in ./build/dri, because they're hardlinks to files in ., and different editors will break those hardlinks. [08:00] GrrrrAAAAARCGH! [08:01] I build intree with git anyhow :) [08:02] mesa make clean is broken enough to justify using git clean instead [08:02] Well, you're *required* to build mesa in-tree; out of tree builds are broken. [08:09] ...that's retarded. [08:09] there's another build system you can use too [08:09] scons iirc [08:10] Yeah, but we don't use that. And I'd be surprised if it isn't a bit broken. [08:11] So, make can't seem to determine that a rule for main/api_exec_es1.c can be used to make ../../src/mesa/main/api_exec_es1.c [08:12] I'm pretty sure out of tree shouldn't even be attempted atm unless you want to fix things [08:13] That's what I'm doing now; attempting to fix things. [08:13] Because we'll probably want 8.1, and that means we'll want out-of-tree to work. [08:16] hm, where can I see the stable queue for 3.2.21? [08:17] stable-queue.git doesn't list it [08:19] probably not started yet [08:34] Oh, man. Out-of-tree builds are so utterly broken. [08:55] mlankhorst: git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git [08:55] but nothing there yet [08:55] I'll add some commits though [09:10] multi arch is funny, took a bit to figure out how to install libdrm2 amd64 [09:18] RAOF: that problem is because of galliumcore [09:19] RAOF: dget -u -x http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/m/mesa/mesa_8.1~git20120529.f92b2e5e-0ubuntu0sarvatt.dsc , that was the last time mesa built [09:21] llvmcore was broken because of https://bugs.freedesktop.org/show_bug.cgi?id=49504 , now it fails with https://bugs.freedesktop.org/show_bug.cgi?id=50604 [09:21] Freedesktop bug 49504 in Mesa core "[Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs" [Normal,New: ] [09:21] Freedesktop bug 50604 in Mesa core "[compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory" [Critical,New: ] [10:07] Sarvatt: is there a reason your cedarview ppa is private ? [10:08] aissen: i got asked to delete it, the packages are going straight into precise in the next few days though [10:09] Sarvatt: alright ! [11:56] Sarvatt: I tried it on two different hardware (D2500 and N2600), and I only have a black screen on X startup. [11:56] Sarvatt: will there be an updated version from the latest code drops ? [12:05] aissen: if you're using ubuntu you need to remove vt.handoff=7 from the kernel command line to get around that, can do GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub and update-grub to do it [12:07] sysrq-v works too, or vt switch and stop/start the dm [12:24] Sarvatt: thanks [12:26] Sarvatt: the screen is filled with garbage. Even the "kms" side doesn't work, it doesn't seem to find the right refresh rate. [12:26] Sarvatt: yes, I'm on ubuntu, running precise [12:39] aissen: unity 2d or gnome fallback session instead of unity or gnome-shell [12:40] aissen: arent these drivers fun? :P [12:40] Sarvatt: yeah I love that :-) [12:41] 2d deceleration, broken GL support, but video acceleration works ok [12:42] Sarvatt: how can I enable unity 2d ? Isn't the problem at the modesetting level, since the display is already scrambled before X starts ? [12:42] its scrambled on the lightdm login screen? [12:43] yes [12:43] err, thats a new one [12:43] I could "find" unity 2d choice in lightdm, but I'm guessing this won't help much [12:44] let me try on the other hardware (D2500) the grub options, I'll tell you if it helps. [12:45] aissen: are you using your own kernel? you dont have psb_gfx loaded right? [12:46] Sarvatt: nope, clean precise install. [12:46] Sarvatt: let me check. [12:46] did you dkms the kernel patch or something? [12:47] hum, I installed the dkms package from your ppa - wrong move ? [12:47] cedarview-drm [12:47] oh yeah [12:47] that wont work [12:47] oh, ok. [14:03] hello.. anyone here from the x-swat x-updates ppa team? [14:05] yes? [14:07] mlankhorst: I was wondering about the 295.59 nvidia driver -- has it been deliberately kept to the 259.3x version due to some issue? [14:08] 259? [14:08] sorry, 295.3x [14:08] think there were some regressions indeed :) [14:09] ah.. looks that way, because even the page here http://www.nvidia.com/object/unix.html lists 295.53 as the latest [14:10] i hope it's resolved soon because the .53 version doesn't support my card [14:10] which is.. ? [14:11] PCI ID 0fd3 [14:11] GT 640M LE [14:11] it's up to nvidia to provide that [14:12] yes, I realise :) I know it's not something x-swat / x-updates can fix :) [14:15] It looks like 295.59 was supposed to be a "long-lived branch release".. i can't imagine how they could release it with regressions! [14:16] there was a security fix that broke stuff [14:17] I see, thank you, tjaalton , mlankhorst [14:17] I will wait for the next iteration [14:17] nvidia-current is at 295.40, nvidia-current-updates at 295.49 [14:18] plus it didn't fix the gaping hole :( [14:18] ah that [14:19] mlankhorst: which gaping hole? [just curious] [14:19] oh now there should be 295.59 [14:19] rohan: from what i read from the patch, it seems whole io space is open to user [14:19] with support for 640m le [14:19] now whole io space minus 100kb is [14:20] http://www.nvidia.com/object/linux-display-amd64-295.59-driver.html?ClickID=d2mtm2tsoxksbkobmcnznsx20bn22ytbcymy [14:20] [10:17] nvidia-current is at 295.40, nvidia-current-updates at 295.49 ==> are we looking at different repos? I am looking at the x-updates PPA and the version of nvidia-graphics-drivers is 295.53 [14:21] ah [14:21] ftp://download.nvidia.com/XFree86/patches/security/CVE-2012-0946/nvidia-blacklist-register-mapping-290-295.diff [14:21] The NVIDIA UNIX driver before 295.40 allows local users to access arbitrary memory locations by leveraging GPU device-node read/write privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0946) [14:21] yes, but isn't 295.59 the one with the security hole? [14:21] it's the latest of the series.. [14:21] look at that patch.. there is no reason for userspace to map ANY register from the device in that range.. [14:22] if (IS_REG_OFFSET(nv, NV_VMA_OFFSET(vma), NV_VMA_SIZE(vma))) [14:22] so if they all are affected then yes [14:22] that whole branch needs to be removed if nvidia cared about security [14:22] is it fixed in 302?-) [14:22] nope [14:22] heh [14:23] [10:19] now whole io space minus 100kb is ... ? [14:23] oh you were referring to the patch you linked? [14:23] yeah that was their 'fix' turns out userspace needed it so it broke on a few [14:25] oh this 'fix' is what's holding 295.59 up? [14:25] I guess that's also why they removed it from the main download page [14:25] no [14:25] the hole is old [14:25] yes, but the fix is breaking userspace, like mlankhorst said, right? or am I just not following? [14:25] it's in all nvidia drivers ever released up to 295.40, and even there still open. :S [14:40] so does 295.59 fix it, and by fixing it, cause issues? or were the regressions you mentioned separate? [14:54] i cant say since i dont look into nvidia drivers [14:54] they tried to fix it in .40, which caused issues, and at least some got fixed later [14:54] aiui [14:55] ah i see [14:55] guess my best option atm is just wait, then :) [14:55] there's no point in just updating for the sake of updating [14:57] right, but .59 adds support for 640mle.. [14:57] and a bunch of other cards [14:59] that's a valid point :) [15:18] so should i file a request or just wait? [15:19] tseliot probably has it on his todo-list already [15:20] yep [15:20] :) [15:35] great, thank you :) === yofel_ is now known as yofel