[02:14] Sarvatt: hey o/ [02:15] I remember him saying his rv515 was freezing on .38 [02:17] Sarvatt: i think i'v narrowed the issue down to kernel .35 , either due to drm/radeon/kms: add missing copy from user (or) (drop after 2.6.35) drm/radeon/kms: add ioport register access (or) Add support for the ATIF ACPI method to the radeon driver [02:17] but this random X freeze is really not being easy to catch :s [04:19] Aah, cargo-culting x86-64 assembler. [04:19] It's the way of the future :( [15:05] * tseliot got "Transfer aborted. Data connection closed" when uploading a package to a PPA... [15:07] tseliot: try using upload.ubuntu.com instead of ppa.launchpad.net as the fqdn in ~/.dput.cf? [15:09] Sarvatt: wouldn't this make my package end up in Ubuntu? [15:09] i used to get that a lot from ppa.launchpad.net and switched mine over [15:09] ah [15:09] thanks for the tip :) [15:11] tseliot: launchpad might have just gone read only? [15:12] thought i read a mail about maintenance today [15:12] Starts: 09.00 UTC 10th March 2011 [15:12] Expected back by: 10.30 UTC 10th March 2011 [15:12] yes, I read that email too [15:13] wonder if they meant EST instead of UTC lol [15:13] nah its up [15:13] yeah it was down earlier [16:31] RAOF: forgot to bump debian/videoabiver so all the drivers with old xsfbs in ubuntu-x-swat/ppa think they need abi 9 [16:33] (good thing we staged that in a PPA eh?) [16:34] that was the idea ;) [16:35] changes were not pushed to git, so hard to review them [16:35] ah [16:36] though it's a bit late to complain about that :) [17:15] bjsnider, hi. I'm still getting crashes using the Nouvea drivers [17:16] bjsnider, i get an error in the logs "Detected GPU lockup" [17:29] codemagician, are you starting to believe you made a bad choice of video cards? [17:32] bjsnider, i thought you had the same card? [17:32] i have the same gpu, but a different card [17:33] bjsnider, do you think its hardware related or software? [17:33] or maybe something is corrupt with my install [17:34] yes to all 3 [17:34] what's the best approach to solving this [17:35] Sarvatt: ping? [17:36] soreau: heya, whats up? [17:36] There is a bug in xorg-edgers repo that breaks xv on r3-5xx cards. Installing ddx master manually fixes the issue. [17:36] natty? [17:36] The problem is that there is a colored pattern of green and pink when playing xv video in any player [17:37] No, 10.10 [17:37] I have this issue ob rv350 and someone else has it on x600 [17:37] on* [17:37] dropped maverick in there because I can't keep up with the updates on top of work so it hasn't been updated in quite some time :( [17:37] Aw :/ [17:37] sounds like it was fixed upstream in the ddx though [17:37] Yea upstream is fine [17:38] i'll update it real quick [17:38] Is there any way we could update it at least until natty official release? [17:38] Thank you Sarvatt [17:40] But, I thought all these updates were automated .. [17:41] they can't be automated anymore for maverick and earlier because the packaging has changed so much in natty [17:41] Oh wow [17:42] Yea a lot of stuff is changing [17:42] *cough*unity implemented with compiz*cough* [17:47] hmm, it might not even have built for longer than I thought on maverick, what version are you using? [17:50] Sarvatt: version of what? [17:51] ati [17:51] the last few uploads of it on maverick failed to build [17:51] hm [17:51] I have master currently installed.. [17:51] let me see what's in the repo [17:52] ii xserver-xorg-video-ati 1:6.14.99+git20110214.a9a59717-0ubuntu0sarvatt2~maverick [17:54] soreau: ok new one uploaded, hopefully it works! [17:55] * soreau tries [18:04] Sarvatt: I see no updates with apt-get update/upgrade [18:04] from xorg-edgers [18:04] Does it take awhile? [18:06] yeah probably 45 minutes or so on average [18:06] looking now [18:06] i386 should be published but amd64 just started building [18:09] Sarvatt, is 1.10 in natty yet? [18:10] not the final 1.10 nope [18:10] what's the delay? [18:12] needs a FFe and testing [18:12] it's ~50 packages, not that minor of an upgrade or anything [18:13] well, it's an alpha distro [18:13] RAOF: can you push your xserver 1.10 stuff to git when ya get a chance? [18:14] that doesn't stop the world from ending whenever people can't upgrade for an hour :P [18:31] looks like I need to disable pageflip on my HD 5770 for unity to work too [18:31] oh hmm, it's working after a vt switch and back [18:33] thats only with xorg-edgers, archive is fine [18:37] wow what the heck, https://bugs.launchpad.net/bugs/259219 is affecting software-center now? [18:37] Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 50) (dups: 13) (heat: 148)" [High,Triaged] [18:59] soreau: any luck? i'll try to keep ati in maverick up to date, its mesa and libdrm causing all the headache [18:59] Sarvatt: I take it you haven't been glancing in #radeon [19:00] oh nope, good to hear [19:00] Sarvatt: It's working fine now here too [19:00] (I knew it would, after this update) [19:01] Thanks again :) [19:04] should just backport xserver 1.10 to maverick and pull in all of the changes so it can be updated at the same time, hmm.. it will mess with so many components I have no clue about like utouch though [19:43] software-center uses GL? [21:03] unity backtraces sure are fun to read http://sarvatt.com/downloads/gdb.txt [21:45] err.. https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/732809 [21:45] Launchpad bug 732809 in mesa (Debian) (and 1 other project) "mesa update to 7.10.1-0ubuntu1 breaks ipython matplotlib (affects: 1) (heat: 6)" [Unknown,New] [21:46] this seems insane. [22:00] Sarvatt, jcristau: Not insane; libGL has just been accidentally working for ages. [22:00] I'd wager that's bug #259219 [22:00] Launchpad bug 259219 in software-center (Ubuntu Natty) (and 3 other projects) "Broken TLS support in libGL.so (affects: 111) (dups: 17) (heat: 214)" [High,Triaged] https://launchpad.net/bugs/259219 [22:02] As far as I can tell, anything that's been dlopening libGL since about mesa 7.0 has been working by accident. [22:03] and you're saying not using initial-exec doesn't fix it? [22:04] I can't seem to get gcc to *not* build a TLS_STATIC library. [22:07] man gcc suggests that PIC should do the trick, but it doesn't appear to. [22:07] what's TLS_STATIC? [22:09] There are two TLS models; static and dynamic. Static is for when you can guarantee that all your symbols will be avaliable at program start time, and does all the TLS initilaisation an allocing there. [22:09] Dynamic is more dynamic, and works with (among other things) dynamic loading. [22:09] why now? talloc removal? [22:10] Yup. [22:10] Well, we're _noticing_ it now becaues libGL now links in libstdc++, which also has some TLS. [22:11] As you see from that bug, it's always been broken for people using libstdc++ & libGL dynamically. [22:12] right, ok [22:14] and does TLS_STATIC flag show up? [22:15] add 'where' in that sentence [22:15] Yeah, in the output of readelf. [22:15] Oooh. [22:15] ah, DT_FLAGS [22:15] Loooks like the final mesa build I kicked off actually built with TLS and without TLS_STATIC. [22:15] FLAGS 0x0000000000000012 [22:15] Now, to remember precisely what I did there :/ [22:15] and 0x10 is DF_TLS_STATIC. ok. [22:18] It appears that throwing -fpic in addition to -fPIC at gcc actually causes it to *not* build TLS_STATIC libraries. [22:23] * RAOF verifies this with another build [22:27] Ah, good. And a quick check of the other libraries in /usr/lib finds mesa libraries as the only ones with TLS_STATIC in DT_FLAGS. [23:33] Ok. So, I'm wrong. It's not gcc's fault, I've just missed some assember somewhere.