[00:00] hmm that guy followed up more with a mesa patch [00:00] Sarvatt: Yeah, sweet. [00:06] there's people reporting server crashes on closing clutter apps fwiw [00:09] wow knarf really rocks, looking forward to testing that stuff [00:10] jcristau, do you think the debian -ati should be updated for fdo 27186 mentioned above? [00:11] tormod: i don't know, brice handles radeon. is updating for the next RC or release not good enough? [00:11] -intel apport freeze hook OFF [00:14] jcristau, ok I can ask brice. this would be a regression from the previous version. [01:23] hmm, seen a few bugs with this problem, wonder if the patch works - https://bugs.freedesktop.org/show_bug.cgi?id=25607 [01:23] Freedesktop bug 25607 in Driver/Radeon "drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before" [Normal,New] [01:35] we need our log scanner :-) [01:53] Lets test these mmiotrace scripts. [03:04] Hm. Not exactly a turnkey solution. [03:04] Stop losing events, damnit. [03:57] Ah, my old friend IPEHR: 0x01800020 [03:59] heh notice anything interesting about this log? http://pastebin.com/bKV4UuPL [04:00] just added a check for KMS to vesa and made it not load if a KMS driver is in use [04:00] Sarvatt: I, too, have done that. [04:00] There's a bug on xserver-xorg-video-vesa & b.fd.o [04:00] oh? [04:01] Shouldn't it fallback to fbdev though? [04:01] good because mine is incredibly hacky, darn autotools [04:01] Ah. Mine might be better, then :) [04:01] thats only because i forced vesa in xorg.conf, it'd fail to load right if it was autoconfiguring [04:01] Mine should do things like allow vesa to be built without libdrm and such. [04:01] would unload vesa and move on to fbdev I mean [04:01] oh? [04:02] bug #531736 btw [04:02] Launchpad bug 531736 in xorg-server "VESA driver should fail to load when KMS is active" [Unknown,Confirmed] https://launchpad.net/bugs/531736 [04:03] drmCheckModesetting makes that pretty easy, though. [04:05] http://sarvatt.com/downloads/patches/vesa.diff [04:05] (ignore the screwy includes) [04:06] checking out that bug [04:06] It's basically a placeholder to say “this should be done, I'm doing it” [04:08] Hm. xf86LoaderCheckSymbol is nicer that what I'm doing, which is to just snprintf a busid string :) [04:17] kay, control+alt+f1, sudo service gdm stop, screen shuts off and power key brings it back up with the plymouth shutdown screen [04:17] That's fun. [04:18] thats new from some update today [04:18] oh yay its after midnight, i can upload mesa with all the fixes now [04:19] ? [04:19] New snapshot date? [04:21] Mesa 7.7.1 Release Notes / March 26, 2010 woohoo [04:21] yeah launchpad handles version numbers weird now [04:22] it wont accept say mesa_7.9.0~git20100323.fffffffff as being newer than mesa_7.9.0~git20100323.00000000 [04:22] so wont let me upload new orig.tar.gz's unless I use + [04:24] 7.9.0+git20100323.ffffffff is > mesa 7.9.0+git20100323.00000000 and accepted but 7.9.0~git20100323.ffffffff is < 7.9.0~git20100323.00000000, i dont get it [04:27] i thought it was dpkg since it started right at a big dpkg upgrade last november but dpkg still evaluates them right [04:27] nv40 should be all fixed up with this mesa upload [04:29] Yay! Compiz for me! [04:29] (Until it dies in gem_cpu_prep) [04:44] the mesa 7.7.1 release notes make it look boring, then you look at the git log and see all the actual fixes :) [04:51] oh whoops, forgot i had a hard dep on the kernel abi version in the nouveau ddx on edgers [04:52] cool [04:52] not cool, broken all day :D [04:53] I see tjaalton has done the xserver 1.7.6 merge, it's in git [04:53] oh sweet! [04:53] Sarvatt, broken in edgers or in lucid? [04:54] just edgers, no biggie :) [05:11] hmm, did bugabundo file a but about the vbox issue? [05:11] hi tjaalton [05:11] hey bryceh [05:12] ubuntu-bug may refuse to do vbox bugs against xorg [05:12] (at least it should for crashes) [05:12] right, but manual ones probably work [05:12] * bryceh nods [05:13] sounds like the vbox video driver is autoloaded but it doesn't support the server abi [05:13] what's new [05:14] heh [05:14] tjaalton, do you mean it's in video-all? [05:14] maybe it should be drummed out then [05:14] bryceh: no, but adding the guest additions will install it [05:14] ah [05:15] there's a bug to split the driver from the vbox package though, to let it install with video-all, but it's not trivial [05:15] I don't think we'd want to accept it anyway [05:15] and then there's the proprietary version too [05:15] of vbox [05:16] so yeah, pointless imo [05:16] I talked with kirkland and he confirmed vbox is not something we need to support [05:16] i'd be nice if it supported usb [05:16] the free one that is [05:16] so I'd say if they want to insert their own X stuff into the xserver, then it's on them to maintain [05:16] right [05:17] (by "them" I mean the vbox proponents in ubuntu) [05:18] I've gotten a pretty hard attitude about it after going through tons and tons of vbox crash bugs due to not supporting the right xserver api in karmic ;-) [05:20] actually those ones were kinda strange, since the additions did support the server, but the server would crash on start (or shutdown) for some strange reason.. never bothered to check that, though I have it installed and confirmed myself [05:20] and that only happened on the first time [05:20] right [05:48] ok the gnome-screensaver-gl-helper bugs for nvidia are all silly, you get that crash report when you activate the nvidia drivers and the screensaver kicks in before you reboot [05:51] i think thats gnome-screensaver's fault personally [05:53] whoa! there's a proper fallback patch for the xorg-conf-available situation [05:53] https://bugs.freedesktop.org/show_bug.cgi?id=27229 [05:53] Freedesktop bug 27229 in Server/general "Video driver autoselection does not work with xorg.conf/xorg.conf.d in place" [Critical,New] [05:53] great [05:53] should we switch to xorg.conf.d now :P [05:53] tjaalton, gonna pull it in? [05:53] tjaalton, sure [05:53] bryceh: not without discussion [05:53] with debian too [05:54] you guys are insane :) [05:54] * bryceh nods [05:54] have to read the thread first [05:54] Sarvatt: this is in 1.8 anyway, and I've got a backported patch already [05:54] about xorg.conf.d [05:55] doh, looks like nvidia-current's blacklist alternative dealie doesn't work from a liveusb with persistant storage either [06:07] http://pastebin.com/raw.php?i=DxS2J1X7 [06:08] wrong glx loading :( [06:13] ahhhhhhhhh I was completely wrong, it's not libglx that's the problem it just requires 24 bit depth being forced in xorg.conf. I made an xorg.conf with just a screen section that had DefaultDepth 24 and it works [07:08] uploaded wacom 0.10.5 to my ppa [07:17] superm1: ^ it has the udev rule fix to match the vendor id too when setting x11_driver, so your laptop should work with this version [07:18] bah, didn't bump the epoch [07:48] xorg gets all narky when you call xf86DMsg () in a probe function. [13:43] tseliot, is nvidia-settings creating a menu entry in lucid? [13:43] bjsnider: yes, why are you asking? [13:43] it didn't in karmic [13:43] i'll have to investigate [13:44] well, nvidia-$flavour does it [13:44] that explains it [13:44] i really only wanted the polkit patch. i went too far [13:45] bjsnider: the polkit patch shouldn't work without lucid's version of screen-resolution-extra [13:46] i changed the dependency so it just asks for screen-resolution0extra without specifying a version [13:47] that won't work [13:47] unless you have that specific version installed [13:47] which has the polkit code [13:47] nvidia-settings calls that [13:48] i don't understand that [13:48] i asumed there would just be a button that says "click here to unlock" or something [13:49] maybe there's another patch somewhere [13:51] the button needs to call something else, right? [13:52] policykit [13:52] that something else is in screen-resolution-extra [13:52] all it needs to do is elevate privileges so the user can save the xorg.conf file [13:53] privileges of what? [13:54] you have a polkit agent and a mechanism [13:54] the mechanism runs with root privileges and the agent (with user privileges) talks to it through dbus [13:56] privileges to edit system files [13:57] it works as I explained, for further information you might want to have a look at the documentation [14:06] /usr/share/screen-resolution-extra/nvidia-polkit.py [14:06] that's why it won't work [14:07] yep [14:07] and if i take that file and add it as a patch to nvidia-settings [14:08] or not even a patch but just install it [14:08] i could do that easily [14:08] yes, I guess that should work (if I remember correctly what I did) [14:23] tjaalton: matching n-trig vendor id too? [14:25] Sarvatt: no, that's missing [14:27] but I've finished the xorg.conf.d/inputclass -backport, pushed it to my personal repo on alioth. will send an email next [14:28] tseliot: ^ it includes the suse patch which makes autoconfig work if there are conffiles around (but no screen sections in them) [14:29] tjaalton: I would like to see that [14:31] git://git.debian.org/users/tjaalton-guest/xorg-server.git [14:31] debian-unstable branch [14:31] haven't merged it in ubuntu yet [14:31] but will do so next [14:31] since unstable doesn't build on lucid (udeb stuff) [14:35] why isn't xf86-input-wacom in pkg-xorg already? can we create it? [14:38] because it's maintained independently [14:41] guess thats a good one to start maintaining the ubuntu changes in bzr then [14:41] Vcs-Git: git://git.debian.org/users/ron/xf86-input-wacom.git [14:42] you could maintain the ubuntu branch in pkg-xorg though [14:42] if you wanted [14:42] tjaalton: thanks, I'll have a look at it [14:42] Sarvatt: I have it on my personal repo atm [14:55] huh, the ubuntu patches applied as-is [15:02] and builds too [15:05] and works [15:06] need to check the fallbacks too [15:07] that's the whole point of this sillyness .. :) [15:08] you removed an input abi bump though, dont forget we're going to need to remove all the input abi 9 ifdefs from input drivers now :( [15:08] which means wacom [15:08] it's the only one [15:09] i should have them all cloned on my hd [15:25] as much as I dislike bzr because it is *really* a pig with big repos, the idea of keeping ubuntu deltas in bzr and setting up bzr-builddeb for everything is really growing on me these days, i just wish I knew a way to go backwards and merge our debian/ bzr branches if we had them into git without a lot of pain. having one ubuntu branch in debian git doesn't seem to be enough and there is a divide between that branch and SRU stuff thats in bzr. [15:25] also there's a split if we do decide to do something like stable mesa version updates in released versions, and there are a number of packages with no ubuntu branch at all because we usually track upstream like intel and ati. [15:27] heck yeah, fallbacks work (at least it loads vesa/fbdev too) [15:41] Sarvatt: well, no-one has bothered to create other branches [15:41] tjaalton: do you think 1 month really is enough time to really convert everything and get enough feedback on issues if we backported that? it's such a major change [15:43] Sarvatt: dunno, we'll see [15:44] and it's just for configuration, the drivers itself won't care [15:45] for the debian upstream-* branches, do they just pull master into that branch and merge a tag from that branch into unstable or experimental? [15:48] if so, can we just update upstream-unstable daily? i'm thinking about the packages where we have a newer version in ubuntu than debian and can't just merge from a debian branch in git [15:49] no, the same tag is pulled to the upstream branch [15:49] the you can get the exact diff by checking against the debian branch [15:55] apart from nouveau I can't find such packages atm [15:55] so thats another hinderance, we can't maintain stuff in git that has newer versions than debian which is why intel and ati don't have ubuntu branches and libdrm gets *really* out of sync when we do git snapshots. how can we alleviate that? if packaging branches were in bzr we could just point it at a different branch to merge, upstream vcs's (including debian's) are imported into bzr automatically multiple times a day and we can automatically cr [15:55] eate tarballs and releases any time we wanted [15:56] i don't understand this [15:57] Sarvatt: that's not the reason why ati/intel are not maintained in git [15:57] the ubuntu branch doesn't have to use upstream-* [15:57] if you've added the upstream remote then feel free to pull from there :) [15:58] ah that works, jcristau I don't either thats why I'm asking :) [16:00] having it all in bzr makes it easier for drive-by-committers to add crappy patches :) [16:00] though it's just as easy now [16:01] speaking of which i think xorg-server -1u4 is not in git :) [16:01] true [16:01] because I told asac to upload it if he was in a hurry :) [16:02] since 1.7.6-1u1 is still shaping up [16:02] (i guess) [16:02] right [16:05] so what would be the workflow to use if I wanted to say, merge xserver 1.8 in git in the ubuntu branch today? [16:05] jcristau: blame me ;) [16:06] we wanted this in so we can verify the feature. some folks are waiting for it downstream [16:06] asac: no blame needed :) [16:07] heh ... thanks for being kind [16:07] Sarvatt: add the remote, git merge ; git mergetool etc [16:07] add fdo as a remote, merge the tag from it and push? [16:07] Sarvatt: yes [16:07] oh and git fetch upstream too [16:08] * Sarvatt nods. [16:14] I thought I'd need to push a new remote branch containing that remote first [16:16] nope, not needed. remotes are local [16:17] tjaalton: I know driveby crappy patches suck, but I just dont see them being able to update the actual package anyway with it because they are core-dev and us having to bring it into git manually as any kind of hinderance towards it happening :D [16:18] Sarvatt: yeah, but if it was enforced (probably won't happen though) :) [16:20] tjaalton, cool thanks [16:22] i think i'm going to go ahead and bzr-ify xorg-edgers at some point though, keeping packaging in bzr and setting up bzr-builddeb to work with it would insanely simplify things. that or move packaging into git somewhere so we only have to update that instead of making an increasingly insane amount of hooks and manual packaging adjustments every time I update [16:23] yeah whatever works for you [16:24] email sent, but I think it'll get on the queue since my address has changed [17:11] Could someone please help me with a keyboard that has stopped working in Lucid? [17:11] Ubuntu is still detecting that I'm using it (the cursor in a Terminal window stops blinking when I type), but no characters come out [17:13] Making things worse, the Onboard on-screen keyboard isn't working either (it just shows a blank grey window), so any debugging that requires text entry may be tricky [17:21] I could install GOK or Kvkbd from Ubuntu Software Center, but that would require typing my password [17:23] so you can't start apps from the terminal? [17:24] tjaalton, correct [17:25] https://wiki.ubuntu.com/X/Troubleshooting/HalBreaksKeyboardAndMouse suggests the problem might be that hal isn't running, but I thought HAL was removed in alpha 2. [17:25] mpt_testpc: could you put the logfile somewhere? or file a bug [17:25] udev is used instead of hal [17:26] tjaalton, System Monitor doesn't list a process called udev. Should it? [17:26] tjaalton, which log file? [17:27] /var/log/Xorg.0.log [17:28] well if udev isn't running you'd have no mouse either [17:30] hooray for USB keys [17:30] you could start xev and see if it lists any events [17:31] tjaalton, http://pastebin.ubuntu.com/400671/ [17:32] Any suggestion for starting xev using a mouse? :-) [17:33] oh I thought you had a usb keyboard [17:34] so if you do, just plug it in :) [17:34] I do, and that has exactly the same problem [17:34] I figured it out though [17:34] oh i see [17:35] I saved "xev" to a text file on this computer [17:35] saved it on the USB key [17:35] plugged it into the sick computer [17:35] opened it up, copied and pasted it into a terminal window [17:35] hehe [17:37] tjaalton, http://pastebin.ubuntu.com/400680/ [17:38] * hyperair grumbles that i915's ACPI-based brightness keys still don't work with KMS. [17:39] mpt_testpc: huh, weird. is it a fresh install or an upgrade? [17:40] mpt_testpc: try changing the model from gnome keyboard options [17:41] tjaalton, upgrade. The keyboard was working fine on Lucid until today. [17:42] ok [17:42] wey-hey! [17:43] i blame gdm [17:43] :) [17:43] I changed it from "Apple" "MacBook/MacBook Pro" (which it is) to "Apple" "Apple", and now most keys work [17:44] oh right, it had to work at least on the login screen, right?- [17:44] ) [17:44] No, it didn't, but Onboard worked at the login screen [17:44] hmm ok [17:45] now to try a restart [17:48] So far, so good [17:48] Thank you very much tjaalton [17:48] still weird that it'd break so badly [17:49] try with a new user, and check what's in /etc/default/console-setup (XKB*) [17:50] bbl, sauna while it's still hot -> [17:51] so now I'm back to bug 319221 [17:51] Launchpad bug 319221 in xkeyboard-config "Option+key combos in "USA Macintosh" keyboard layout don't work" [Undecided,Fix released] https://launchpad.net/bugs/319221 [17:53] I can't log in to a new user account, it says "Authentication failure" when I type the password [17:54] but I was having that problem before the keyboard problem, so it's probably unrelated :-) [17:55] And I'm still experiencing bug 524406. [17:55] Launchpad bug 524406 in libxklavier "Frequent "Error activating XKB configuration"" [Low,New] https://launchpad.net/bugs/524406 === radoe_ is now known as radoe [18:26] mpt_testpc: if you can reproduce the original problem again, please get a dump from 'setxkbmap -print' and 'xkbcomp :0 -' [18:30] tjaalton, ok, I'll copy and save that in preparation :-) [18:32] heh [18:32] tjaalton, I see 1.7.6 xserver is staged in git; is it pending any other changes before it can be uploaded? (Want me to upload?) [18:33] bryceh: the patch that asac uploaded is probably the only one [18:33] so the changes in -1u4 need to be merged [18:34] ok [18:34] shall I take care of that? [18:34] you may [18:35] i'll futz with the backports [18:37] huh, of the 40 openchrome bugs open, 15 have patches [18:37] though I've no idea how many of them are valid [18:37] yeah but that's because there is an upstream guy who asks users to test possible fixes by posting patches to the bug [18:37] yep [18:38] I looked through those a while ago and found most looked not viable for us to pull in [18:38] right [18:39] I think they get kinda fussy if we include patches unique to ubuntu in the packaging [18:40] or I should say, they did get fussy once, so I've kept my hands off since [18:40] hehe [18:51] tjaalton, can you link me to the .orig.tar.gz I should use for this upload? [18:52] bryceh: you can find it here for instance http://packages.debian.org/source/unstable/xorg-server [18:53] linked from http://packages.qa.debian.org/x/xorg-server.html [18:53] where you get from versions_current ;) [18:54] hey, I've messed it up before, I figure best to ask ;-) [18:57] * bryceh pbuilders [18:57] :) [18:58] so we can sync packages ourselves, that's great [18:58] there aren't much to sync atm though [18:59] *isn't [19:00] yeah saw that [19:00] bryceh: did you see my email about the backports? [19:00] tjaalton, yep [19:01] so i'm thinking that it's either both take it or leave it [19:02] yeah sounds like a smart strategy [19:02] the changes sound cool but a bit scary given we've got just a month to go [19:03] it sounded like we'd need to touch a bunch of packages to update their config stuff, is that correct? [19:03] e.g. turn udev rules into xorg.conf snippets etc. [19:03] evdev, synaptics, wacom, joystick [19:03] nice, xserver built w/ no issues. uploading... [19:03] vmmouse maybe [19:04] evtouch too [19:04] but those are trivial [19:05] need to check serial wacom support too [19:05] how to handle it [19:06] probably just a matter of matching the right string or so [19:06] uploaded. [19:06] ah actually the udev rule sets ID_INPUT_TABLET, so the normal rule will match then [19:09] and fedora has 10-wacom.conf already [19:22] is sis synced with tormod's fix? [19:53] * hyperair thinks that the source of his graphical corruption is xserver-xorg-video-intel.. [19:54] * hyperair tickles Sarvatt [19:55] hmm maybe i should just revert to 2.9.0 and see what happens [19:56] hyperair, no it's probably drm stuff [19:56] hyperair, so boot an earlier kernel [19:56] bryceh: oh so it's a kernel thing? [19:57] bryceh: is this a known issue? [19:57] dunno check launchpad [19:57] bryceh: i'm running karmic and xorg-edgers.. i don't think such bugs would appear in launchpad. [19:57] and a 2.6.34 kernel [19:58] wow, pretty jacked out [19:58] heheh [19:58] it's a custom compiled 2.6.34 kernel in fact [19:59] you're a crazy man [19:59] ;-) [19:59] i blame it all on intel. [19:59] after they screwed over the performance of i915, i followed xorg-edgers and never stopped [19:59] i think i began compiling my kernels around then as well [20:00] no wait i think i started compiling them even before that because i needed phc [20:00] * hyperair tries restarting X [20:01] yeah Intel's really bad about pushing everyone to bleeding edge stuff [20:02] but it gets people into weird configurations that are too far from stock for us to deal with [20:02] hyperair, really with your config you should be asking on #intel-gfx [20:05] bryceh: i did. [20:06] great [20:06] with no reply =\ [20:06] well, at least i got a response on the backlight keys issue [20:06] and so i'm compiling a new kernel to check [20:09] bryceh: i think it is xserver-xorg-video-intel after all. i just install 2.9.0 from karmic-updates and i don't see any graphic corruption [20:09] well for the time being [20:09] let's see whether it returns [20:14] hi tormod [20:41] hah, I made it on phoronix \o/ [20:42] jcristau: not yet [20:42] hah, he calls you mad. [20:46] well put [20:48] hi bryceh, I fear I won't get far with -ati today... [20:50] maybe I should create an account to comment on the phoronix thread :) [20:51] but not today -> [20:54] the peanut gallery is having so much fun [20:59] tjaalton: did you throw it up on a PPA? [21:08] More Phoronix Madness [21:10] people who can't spell, giving their advice on how X should be maintained in ubuntu [21:11] it's not advice, really. it's obviously The Truth. [21:12] lol [21:14] I like airlied's reply #17 though [21:15] airlied knows what he's talking about. that should disqualify him for phoronix comments [21:15] hehe [21:15] jcristau, don't worry I'm sure his comment will be ignored into oblivion [21:48] evening [21:50] bryceh: Good morning. I've got a fix for bug #531736 in x-x-v-vesa in the ubuntu branch of pkg-xorg git; could you check it out & sponsor? [21:50] Launchpad bug 531736 in xserver-xorg-video-vesa "VESA driver should fail to load when KMS is active" [High,Fix committed] https://launchpad.net/bugs/531736 [21:51] hi RAOF, certainly [22:23] bryceh: Have you uploaded vesa yet? If not, could you hold off on it - I may have outsmarted myself with the build-time checks :X [22:24] haven't uploaded yet [22:41] bryceh, just because they can't spell and don't know what they're talking about doesn't mean we shouldn't listen to their worthless opinions' [22:44] bryceh: There we go. I *had* outsmarted myself. x-x-v-vesa git now has the correct build-dependencies to actually enable the patch! [22:46] * RAOF reinstalls xserver-xorg-video-all again [22:48] RAOF btw a convention we've been using is to number ubuntu patches starting with 100, so we can more easily distinguish them from debian's patches [22:48] Ok. I'll update git to follow that convention. [22:51] mm I like the patch, looks good [22:57] Ok. git updated to make the patch number start at 100 [22:58] I would like to ask about Poulsbo for the dell netbook, it is not working in lucid, any news or related bugs that I look at ? [23:02] no news on psb [23:04] W: xserver-xorg-video-vesa source: patch-system-but-direct-changes-in-diff ChangeLog and 1 more [23:06] * jcristau ignores that warning [23:07] Yeah; that's unchanged from the debian package. [23:07] yep [23:08] RAOF, uploaded [23:08] Thanks! [23:10] RAOF: what did you end up doing? something like http://sarvatt.com/downloads/patches/vesa.diff ? [23:11] I incorporated some of that; mainly the DRICreatePCIBusID bit rather than hand-creating my own pciid string. [23:11] I stuck it in the PCI probe function, though. [23:12] So X probes the vesa driver, which detects kms, and doesn't create a screen object. [23:12] You can have a look http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-vesa.git;a=blob;f=debian/patches/001_ubuntu_bail_when_kms_active.patch;h=4d2880fdcc6954225303db0cca31b06209c933ee;hb=22017c781ac34e1bbc62908eeccc830709fbe2f3 [23:17] btw if you guys are interested, kees and I set up a bzr tree with some scripts to revert some of the design annoyances... https://code.edge.launchpad.net/~ubuntu-wilson/ubuntu-wilson/main [23:18] * kees recommends reading each and picking the ones you want instead of running the bulk installer. :) [23:18] moves the toolbar buttons back to the right. I got an inkscape friend to fix the buttons so they're all rotated correctly although don't have the packaging to install those [23:19] * RAOF actually rather likes the buttons on the left. [23:25] Gah! vga16fb, I stab at thee! [23:25] oh nice, the only thing that bugged me was the button graphics being dependant on the changed button ordering and all other themes not looking right with that configuration [23:25] thanks for that kees and bryceh :) [23:26] Sarvatt, you have to manually copy them into place for now, I'm not sure how to set up the diversions properly [23:26] but they look great [23:48] "Timo Aaltonen has now published a patch to Ubuntu-X that brings most of the X Server 1.8 features back atop their 1.7 server." [23:52] bjsnider, <3 phoronix [23:55] it's true because i read it in the interwebs [23:58] yeah apparently the ubuntu-x mailing list is a good ad money maker :) can't have a discussion there without it showing up as news and interpreted as exactly whats going to happen [23:58] we should totally get them for apr-1st [23:58] lucid upgrading to xserver 1.8 and mesa 7.8? :) [23:59] or lucid delayed 2 months because X is too broken [23:59] someone else got them last year with xorg 7.5 release :) [23:59] jcristau, :-) [23:59]