[01:40] <Sarvatt> sure, pass it along RAOF :)
[02:03] <RAOF> Sarvatt: It's in xorg-edgers.  Seems to work for me, but my nv40 cards have ceased to be an interesting test :)
[02:07] <Sarvatt> would be nice to know why we have to remove quiet from the boot line on nouveau :D
[02:07] <RAOF> Note: that definition of "we" does not include me :)
[02:08] <RAOF> That particular strangeness got fixed somewhere in the last weeks for me; probably it was mad framebuffer related craziness.
[02:08] <Sarvatt> oh? must be nice!
[02:08] <Sarvatt> maybe if i blacklist vga16fb, still havent done that on that machine
[02:09] <RAOF> I think the -9 kernel fixed stuff, too.  Maybe.
[02:09] <Sarvatt> removed my firmware files, upgrading now
[02:22] <Sarvatt> got a ton of dmesg spam for 5 seconds about 20 seconds in but seems to be working ok, firmwares there and got loaded
[02:27] <RAOF> Superlative.
[12:11]  * Ng sulks. I was copying a bunch of data to a USB disk and it took out X
[12:36] <mac_v> Ng: karmic?
[12:56] <hyperair> took out meaning X lagged like hell or something else?
[12:57] <hyperair> imo we've got some big issues with IO and interactivity
[13:11]  * mac_v had somewhat similar X crashes when system was doing heavy read/write operations... but using lucid kernel 32.* solved it ..
[13:11] <mac_v> x restarts*
[13:35] <Ng> mac_v: lucid. looks like the kernel oopsed becuse of something relating to the USB disk and the xlog suggests it then segfaulted, but I could still see it, which was a bit odd. ssh'd in and rebooted
[13:46] <hyperair> hmm  i wouldn't know, i didn't use .31 for long. had a great number of ext4 issues
[13:50] <Ng> (I couldn't interact with it in any way though, so I can well believe that X had died and the framebuffer just stayed as it was)
[13:51] <Ng> quite annoying though, I bought the USB disk so I'd be able to take regular rdiff-backup snapshots of my laptop while I'm running lucid on it ;)
[16:01] <tjaalton> tseliot1: I noticed you updated the halsectomy-spec. there's no working wacom driver atm, so you sed evdev which doesn't work properly with it
[16:02] <tseliot1> tjaalton: yes, I also tried to contact pitti and you but I was disconnected from IRC
[16:02] <tseliot1> tjaalton: aah, it's evdev then
[16:06] <tjaalton> there will be a new xf86-input-wacom RSN, and I hope ron finds it good enough to package for experimental
[16:07] <tseliot1> tjaalton: well, I think it would be better than using evdev anyway
[16:08] <tjaalton> I tried to find an intuos4 M/L, but they were out of stock..
[16:08] <tjaalton> tseliot1: it sure would
[16:09] <tseliot1> tjaalton: (just FYI) this is the only change that I would need to apply to X in order to get the alternatives system to work: http://pastebin.ubuntu.com/345406/
[16:10] <tseliot1> I don't even have to touch mesa
[16:22] <tjaalton> tseliot1: do libdri/libglx need to be moved to another path for it to work?
[16:23] <tseliot1> tjaalton: they live in /usr/lib/xorg/modules/extensions/standard/ and, when you use open drivers, you will have links to them in /usr/lib/xorg/modules/extensions/
[16:24] <tseliot1> in the case of nvidia you use libdri.so from /usr/lib/xorg/modules/extensions/standard/ and libglx.so from /usr/lib/nvidia-current/xorg/libglx.so
[16:25] <tseliot1> then a simple update-alternatives --set gl_conf $master link and you can switch between them
[16:26] <tseliot1> where $master_link is /etc/standard-x11/standard.conf in the case of X11 and open drivers
[16:26] <tseliot1> therefore, in order to switch to open drivers (the default):
[16:26] <tseliot1> update-alternatives --set gl_conf /etc/standard-x11/standard.conf
[16:26] <tseliot1> while, for example, for nvidia-current:
[16:27] <tseliot1> update-alternatives --set gl_conf /etc/nvidia-current/ld.so.conf
[16:27] <tseliot1> of course jockey will deal with this
[16:28] <tseliot1> oh and of course "ldconfig" is required after these commands
[16:29] <tjaalton> ok
[16:30] <tjaalton> why not just installlibdri/glx directly to the correct path instead of moving them around?
[16:31] <tjaalton> and if the confs aren't meant to be admin-configurable, shouldn't them be under /usr somewhere?
[16:31] <tjaalton> *they
[16:33] <tseliot1> tjaalton: update-alternatives doesn't create links if the file already exists
[16:34] <tseliot1> tjaalton: what do you mean by admin-configurable? You can do it manually if you want
[16:34] <tseliot1> i.e. install the packages, update alternatives, set the driver in xorg.conf and reboot
[16:35] <tjaalton> I mean the file content probably will never change
[16:35] <tseliot1> tjaalton: what file?
[16:35] <tjaalton> and cleaning conffiles from /etc is more troublesome
[16:36] <jcristau> /etc/nvidia-current/ld.so.conf < that file
[16:36] <tseliot1> aah
[16:36] <tseliot1> those files are not a problem unless something links to them
[16:37] <tseliot1> and when you uninstall the packages the alternative is removed and so are the links
[16:37] <jcristau> but the file isn't
[16:38] <tseliot1> why not?
[16:38] <jcristau> because conffiles aren't removed on package removal
[16:38] <jcristau> they're removed on purge, except when they become obsolete and you forget about them
[16:38] <tjaalton> exactly :)
[16:39] <tseliot1> aah, now I see your point
[16:39] <jcristau> so for something that's not supposed to be configurable, installing it in /etc leads to pain down the road
[16:39] <jcristau> or cruft, or whatever
[16:40] <tseliot1> I can either make the postrm deal with that or simply install them in /usr/...
[16:41] <tseliot1> I remove the alternative in the postrm, therefore I think it's better if I remove the file there
[16:42] <tjaalton> better in /usr, otherwise it would also "pollute" the namespace in /etc
[16:42] <jcristau> you should remove the alternative in prerm
[16:43] <tseliot1> that would be a solution too
[16:43] <tseliot1> good idea
[16:46] <tseliot1> shall I use /usr/share/nvidia-current etc, or /usr/lib/nvidia-current (that I already use). The former makes more sense to me
[16:46] <jcristau> lib imo
[16:47] <tseliot1> right, after all is an ld.so.conf file, which is relevant to that directory
[16:52] <tseliot1> also, is there a point in adding a prerm.in instead of a prerm in X?
[16:52] <tseliot1> it's not a template
[16:55] <tseliot1> oh, there's the #INCLUDE_SHELL_LIB# thing
[16:55] <jcristau> prerm gets removed by xsfclean
[16:55] <tseliot1> ok, I'll use a .in file
[16:55] <tseliot1> that's why I asked
[17:01] <tseliot1> jcristau: are templates (i.e. .in files) automatically detected?
[17:03] <tseliot1> or shall I add the prerm.in file somewhere?
[17:07] <jcristau> see the genscripts rule in xsfbs.mk
[17:13] <tseliot1> ah, nice, thanks
[17:27] <tseliot1> jcristau, tjaalton: better? http://pastebin.ubuntu.com/345439/
[17:28] <jcristau> not sure what the point of /usr/lib/standard-x11/standard.conf
[17:28] <jcristau> is
[17:29] <jcristau> oh. default alternative.  /dev/null would work as well :)
[17:30] <tseliot1> it's an empty file since we're going to use the libraries that come with X/mesa
[17:30] <tseliot1> e.g. libGL.*.so, etc.
[17:31] <tseliot1> while fglrx and nvidia use their own libraries
[17:31] <tseliot1> and yes, that's for alternatives, as you said
[18:02] <superm1> tseliot1, rather than relying on jockey to update the alternatives, why not do it right in the postinst?
[18:02] <superm1> the less custom work that jockey has to do, the better (imo)
[18:04] <jcristau> i guess because alternatives have static priorities, which can't take into account the actual hardware on the machine, so can't decide between nvidia-current or nvidia-last-year or fglrx-current or fglrx-legacy, or or..
[18:10] <superm1> well if you run update alternatives and they do have static priorities, then that will be a no-op
[18:10] <superm1> eg current should always be newer than last year which should always be newer than last-last-year
[18:10] <superm1> but if you run jockey it can override such priorities?
[18:12] <jcristau> what will be a no-op?  if you have multiple nvidia driver packages for different generations of chips which one gets higher priority?
[18:12] <tjaalton> or fglrx over nvidia?
[18:14] <tjaalton> that's why I didn't think alternatives would work, but making the user choose via jockey is the only way
[18:18] <jcristau> tseliot1: maintainer scripts have update-alternatives in $PATH no need to use the full path
[18:22] <jcristau> also no need to use $(CURDIR) when you don't need an absolute path
[18:22] <jcristau> and echo \n is not portable :)
[18:26] <superm1> if they all need to have the same priority set, then maybe a debconf to select among the priorities
[18:26] <superm1> *debconf question
[18:33] <jcristau> tjaalton: not sure if you saw, the testsuite failure on sparc/ppc should be fixed in master now
[18:41] <tjaalton> jcristau: ah, good. didn't see that
[18:42] <tjaalton> superm1: that just moves the question to a different layer
[18:42] <superm1> tjaalton, but then you can interactively ask
[18:43] <superm1> if there is only one option available, then you wouldnt have to, but if there are a few, then you can present them to the user
[18:43] <tjaalton> superm1: if you only have one blob installed manually, it'll have a higher priority than the default
[18:44] <tjaalton> so no need to ask anything there
[18:44] <superm1> right, and then if you have two blobs, then you ask the question
[18:45] <tjaalton> well there should be a way to not ask it if the choice is already made by jockey
[18:46] <tjaalton> or rather, by using jockey
[18:46] <superm1> jockey uses debconf noninteractively currently
[18:46] <superm1> so it would have to preset that value
[18:47] <superm1> this can just be for a second iteration of changes though, because it will require work on the jockey end that may be non-trivial
[18:52] <tjaalton> sure
[19:14]  * bryce_ waves
[19:36] <tseliot1> superm1: priorities work when in automatic mode
[19:36] <tseliot1> in jockey I would switch to manual mode by using update-alternatives --set
[19:37] <tseliot1> do we really want to use debconf for this?
[19:37] <tseliot1> hey bryce_
[19:42] <tseliot1> jcristau: ah, thanks, I'll just use update-alternatives without the full path then
[19:45] <bryce_> heya tseliot1