[10:24] <bryce_> jcristau, tjaalton:  I just got a response from intel that they're no longer going to support 81x any longer
[10:24] <bryce_> http://bugs.freedesktop.org/show_bug.cgi?id=16729
[10:42] <tseliot> bryce: what is the file that does the hardware detection when no driver is specified in the Device section of the xorg.conf?
[10:45] <tseliot> ﻿ bryce:  if no driver is specified I should detect which driver is loaded for the xorg-options editor
[10:46] <bryce_> you'll need to parse that from the Xorg.0.log
[10:46] <bryce_> I don't know of any reliable way to determine that otherwise
[10:47] <bryce_> hm, or maybe you could look up the pci id in /usr/share/xserver-xorg/pci/
[10:57] <tseliot> ﻿bryce_: ok, thanks I'll look up the pci id then
[11:16] <tjaalton> bryce_: bah, thypical
[11:16] <tjaalton> -h
[11:21] <bryce_> heya tjaalton
[11:32] <tseliot> ﻿bryce_: hardware detection works well now ;)
[11:33] <bryce_> tseliot: nice
[11:33] <jcristau> looking in /usr/share/xserver-xorg/pci/ is probably not future proof
[11:34] <bryce_> tseliot: btw, I added a brief blurb about the status of -nvidia to https://wiki.ubuntu.com/X/Drivers .  When you get a chance it would be nice if you could flesh it out a bit more (not too detailed, but a paragraph or two would be sufficient, and links to more info would be great)
[11:34] <tseliot> ﻿bryce_: ok, I'll do it
[11:35] <tseliot> ﻿jcristau: what do you suggest then?
[11:35] <jcristau> i don't know why you need that info for
[11:36] <jcristau> also, what's with the BOMs
[11:37] <tseliot> ﻿jcristau: I'm writing xorg-options-editor and if no device section is available (or if the device section is available but the driver is not specified) I have to rely on xorg's autodetection
[11:37] <jcristau> right
[11:38] <tseliot> ﻿BOMs???
[11:38] <tseliot> and why isn't it future-proof?
[11:39] <jcristau> yes, U+FEFF. there's one at the beginning of every one of your lines.
[11:39] <jcristau> or, almost every one
[11:39] <jcristau> it's not future proof because it'll probably go away at some point
[11:40] <tseliot> jcristau: ﻿U+FEFF??? I'm a bit confused by acronyms
[11:41] <jcristau> it's an unicode codepoint
[11:41] <jcristau> so whatever you use for irc is broken and puts that everywhere
[11:42] <tseliot> I can't notice the problem here, using pidgin on Hardy
[11:42] <tseliot> tjaalton reported a similar problem though
[12:33] <tseliot> ﻿bryce_: I have updated the wiki. I might do something more later
[12:44] <bryce_> tseliot: excellent thanks
[13:33] <bryce_> tseliot: http://www.phoronix.com/scan.php?page=article&item=xorg_driver_persistent&num=1
[14:04] <tseliot> ﻿bryce_: yes, I had also read the discussion in the X mailing list. When (or "if") they come to an agreement I can modify xorg-options-editor accordingly
[14:05] <jcristau> err. maybe we haven't read the same discussion then. what more agreement do you need?
[14:07] <tseliot> "To make it persistent, Dan Nicholson had chimed in asking whether GConf or HAL fdi should be used for storing these device property values."
[14:08] <jcristau> and the answer was hal for system-wide defaults, gconf for user-specific, iirc?
[14:09] <bryce_> tseliot: great, sounds good.  Since it sounds like an xserver 1.6 thing, I guess we can look into that for Intrepid+1
[14:12] <tseliot> ﻿bryce_: ok, I'll think about it when it's (almost) ready then
[18:35] <BUGabundo> his Alberto Milone arround?
[18:37] <BUGabundo> his = is lol
[19:58] <mario_limonciell> tseliot, other than the fact that "debian has it", is there a reason that we have an init script for /etc/init.d/nvidia-kernel?
[19:58] <mario_limonciell> i'm very surprised that something like this wouldn't be handled directly by the kernel module when loaded
[19:59] <mario_limonciell> yeah actually it looks like it is done by the kernel module.  try stopping X, then "rm /dev/nvidia*" and then sudo X
[19:59] <mario_limonciell> you'll see that those modules are created for you
[19:59] <mario_limonciell> or devnodes i should say
[20:04] <mario_limonciell> well i filed a bug for now, bug 249565
[20:30] <tseliot> ﻿mario_limonciell: thanks, I'll have a look at it later
[20:30] <mario_limonciell> tseliot, i filed another bug about the init script for nvidia-glx too
[20:30] <tseliot> link?
[20:30] <mario_limonciell> tseliot, and it's existence makes me uneasy (in addition to the bug) since it just goes mucking around /usr/ like that
[20:30] <mario_limonciell> but that's not what i filed the bug about
[20:31] <mario_limonciell> sec
[20:31] <mario_limonciell> https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/249566
[20:32] <mario_limonciell> the reason i'm uneasy about that second init script existing, what if someone mounts /usr over NFS read only?  You can't assume that you are able to go and change things in there
[20:35] <tseliot> ﻿mario_limonciell: whatever it is (my connection seems to have some problem now) I will fix it. Don't worry ;)
[20:42] <tseliot> mario_limonciell: what version and revision of the driver are you using?
[20:42] <tseliot> I removed ﻿/etc/init.d/nvidia-glx a few releases ago
[20:43] <mario_limonciell> tseliot, then it must have come from dist-upgrading then
[20:43] <mario_limonciell> let me purge all versions and do a fresher install
[20:43] <tseliot> ﻿mario_limonciell: ok
[20:44] <mario_limonciell> tseliot, it wasn't around in hardy right?  so people who do hardy_>intrepid jump won't end up with it
[20:44] <mario_limonciell> i probably just have it from an earlier use of your packages updated to a newer version
[20:46] <mario_limonciell> tseliot, ah yeah neither of those appear to be present in the final ones :)
[20:47] <mario_limonciell> you don't need /etc/default/nvidia-glx-### though anymore then either
[20:47] <mario_limonciell> which is still present after i purged and reinstalled
[20:47] <tseliot> ﻿/etc/default/nvidia-glx-### ???
[20:48] <tseliot> it's not in my packages
[20:48] <mario_limonciell> i have an /etc/default/nvidia-glx-177 somehow?
[20:48] <mario_limonciell> i purged all nvidia-* and reinstalled and saw it there
[20:48] <mario_limonciell> i'll purge once more to ensure though
[20:49] <tseliot> remove it manually
[20:49] <tseliot> that was from TLS
[20:49] <tseliot> which I removed
[20:50] <mario_limonciell> no it definitely came in from nvidia-glx-177
[20:50] <mario_limonciell> when i installed that
[20:50] <mario_limonciell> it's in it's package listing (dpkg -L nvidia-glx-177)
[20:51] <tseliot> which revision?
[20:51] <tseliot> ubuntu5?
[20:53] <mario_limonciell> ubuntu6
[20:58] <tseliot> mario_limonciell: do a "dpkg --contents name_of_the_package" please
[20:58] <tseliot> don't rely too much on dpkg -L
[21:00] <mario_limonciell> http://paste.ubuntu.com/28113/
[21:00] <mario_limonciell> yeah it's in there
[21:02] <tseliot> ﻿mario_limonciell: 173 is not affected though. Weird. Let me check the code
[21:11] <tseliot> ﻿mario_limonciell: there's no trace of such files in the rules, however I have noticed that I had left nvidia-glx-VER.default files in the debian folder of each driver apart from 173. I have removed such files and I'm rebuilding the packages
[21:12] <mario_limonciell> ah 
[21:12] <mario_limonciell> yeah that's most likely how it ended up there
[21:13] <mario_limonciell> tseliot, i was thinking of something useful that you might consider putting into EnvyNG at some point
[21:13] <tseliot> shoot
[21:13] <mario_limonciell> the ability to grab the source of the nvidia-drivers-$LATEST, and for the user to provide the .run file from the nvidia website
[21:13] <mario_limonciell> and let it spit out a package in case they aren't out and ready yet in backports etc
[21:14] <mario_limonciell> so really it would just craft the orig.tar.gz from the run file and then bump the changelog and version inside the debian packaging temporarily
[21:16] <tseliot> ﻿mario_limonciell: I could do that but I don't think the other devs/motus would be extremely happy about this
[21:17] <tseliot> since they wanted EnvyNG to install only packages from the official repos
[21:17] <mario_limonciell> well i mean as long as it always used the source from the archive to build these newer packages
[21:17] <mario_limonciell> it could be a temporarily solution
[21:17] <mario_limonciell> think of it as the same model that is in the AMD drivers now
[21:17] <mario_limonciell> that the source of the debian/ directory is contained and you get the same drivers if you install from AMD's website as you do if you install from the archive
[21:18] <mario_limonciell> just since NVIDIA doesn't provide such a system, you fill the gap with envyng
[21:19] <mario_limonciell> it's just an idea to think about at least
[21:23] <tseliot> ﻿mario_limonciell: I'm not saying that it's a bad idea. I would like to keep both users and devs happy, that's all.
[21:23] <tseliot> I'll think about it
[21:23] <mario_limonciell> tseliot, remember too that you'll never make all the devs happy.  it's a closed driver ;)
[21:25] <tseliot> heh
[21:26] <tseliot> mario_limonciell: it is also true that if a firm such as Dell needed this feature, I would give it more than a thought :-P
[21:26] <mario_limonciell> haha
[21:26] <mario_limonciell> well when we receive beta drivers from nvidia, it's easy enough to manually do these sorts of things
[21:27] <tseliot> too bad ;)
[21:40] <tseliot> ﻿mario_limonciell: ok, problem solved with the packages. The files in /etc/default couldn't do anything bad but there was no need to keep them there.
[21:41] <mario_limonciell> yeah
[21:41] <mario_limonciell> well they were doing bad when i had init scripts sitting around still
[21:42] <mario_limonciell> but since those are gone, they didn't do anything anymore