[08:55] hi to all [08:55] how can i add the repo to my ubuntu? [08:56] it give me error readerng https://launchpad.net/api/1.0/..... HTTP error 404 === evilvish is now known as vish === evilvish is now known as vish [22:39] RAOF: hey, opinions on bug 652467 before I decline it? [22:39] Launchpad bug 652467 in xorg (Ubuntu) "xerver-xorg-video-ati dependancies need changing (affects: 1) (heat: 28)" [Undecided,New] https://launchpad.net/bugs/652467 [22:39] 1) is not possible, -ati is just a wrapper [22:40] 2) would mean (AIUI) bigger static mappings to the server, which is pointless [22:40] 3) then reveals the true nature of the bug (micro-management), so it's just silly [22:40] mach and r128 add 400kB to the install [22:41] in total [22:41] Yeah. I don't think that's worth doing. [22:41] thanks, I'll close it as wontfix [22:43] That micro-management *is* possible, too - it just requries an xorg.conf [22:43] yeah [22:45] Hm. Is there any reason we shouldn't follow Debian in removing a bunch of unmaintained drivers from the archive? [22:45] no [22:45] there was some talk about it on #debian-x earlier today [22:46] I've yet to re-joing the ml so haven't been following what's going on there [22:48] The list of removed drivers is: xserver-xorg-video-v4l, xserver-xorg-video-radeonhd, xserver-xorg-video-nv, xserver-xorg-input-hyperpen, xserver-xorg-input-fpit, xserver-xorg-input-evtouch, xserver-xorg-input-citron [22:49] all good to go [22:49] I think the only one we might possibly want out of that is -nv. [22:49] :) [22:49] Heh. We're well ahead on -citron. [22:49] right, I'm not quite uptodate on that, at some point nouveau didn't support all of -nv [22:50] but I guess the devices in question are either very rare or old, or both [22:50] I think TNT and riva128 cards aren't supported by nouveau, and nv supports at least one of them. [22:50] Of course, so does -vesa :) [22:50] heh, right [22:50] We should also remove -gevdev, since the gestures stuff is in evdev now. [22:51] Also, it's uninstallable :) [22:51] I've so much to catch on.. [22:51] +up [22:51] :) [22:52] Managed to get all the adminy stuff out of the way yet? [22:52] most of it yeah [22:52] i hope [22:53] There'll be some lingering tentacles :) [22:53] I bet.. [23:37] tjaalton: Incidentally, are you subscribed to mesa-dev? If so, have you seen my dricore patches appear there? [23:38] They seem to have made it to the mailing list archives, but I'd just like to be sure, given the lack of response. [23:41] RAOF: when did you send them? [23:42] I only have the archive since Jan 31st [23:42] ah got it [23:42] v3 [23:43] Yeah, there it is. [23:43] Actually, that seems to have only been Thursday. I thought it was longer. [23:43] doesn't fedora have something similar? you could try poking ajax/airlied to review and ack [23:44] Fedora had something similar in the dim distant past. I might start prodding soon, yeah. [23:45] are gallium drivers smaller than the classic ones (one could assume so..)? [23:45] They're actually of comparable size. [23:45] ah, ok [23:46] But it's more of a pain to make a dricore for gallium. [23:46] Quite a lot more of a pain, and we only install 2 gallium drivers. [23:47] yeah now that I think of it the shared parts are probably built in the drivers? [23:48] just like before, only that the code is more modular [23:48] or the functionality [23:48] bah, too late to function myself :) [23:48] mesa, and gallium even more, create a whole bunch of static libraries which the dri drivers link in. That's why each DRI driver goes from ~3MiB to ~400KiB when you factor out dricore. [23:50] yeah [23:50] If I wanted to be really invasive I could do better, but the patch as written is, I think, the sweetspot for time spent/size opimisation.