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