[03:50] <LaserJock> any compiz types around?
[04:24] <bluesmoke> LaserJock: why?
[04:28] <LaserJock> I'm wondering if there are any good pointers on OpenGL apps behaving badly with compiz
[04:29] <LaserJock> or rather, how to correct screen artifacts in OpenGL apps
[04:36] <bluesmoke> LaserJock: Redirected Direct Rendering
[04:36] <bluesmoke> Unfortunately we don't actually have that yet
[04:38] <LaserJock> bluesmoke: so is that a compiz thing or at the app level?
[04:38] <bluesmoke> That's a driver thing
[04:38] <LaserJock> ah
[04:43] <racarr> Assosciated buzzwords include DRI2.
[04:46] <bluesmoke> Doesn't implementing DRI2 get RDR for free?
[04:58] <racarr> Yes.
[04:58] <racarr> bluesmoke: ^
[04:58] <racarr> It's basically the point of DRI2
[04:59] <racarr> anyway. It works on intel upstream mostly at this point. and is progressing on ATI...
[04:59] <racarr> but the i915_drm module changes aren't landing until 2.6.28, so it wont be in Jaunty.
[05:03] <bluesmoke> hmm, i thought we had 2.6.26 in hardy
[05:03] <bluesmoke> and we usually jump two between releases
[05:03] <racarr> The timing just doesn't work out this time
[05:03] <ebroder> Hardy is 2.6.24, Intrepid is 2.6.27
[05:03] <bluesmoke> err, yeah, intrepid
[05:04] <bluesmoke> wait, now i'm all confused
[05:04] <bluesmoke> racarr: did you mean 2.6.29?
[05:04] <racarr> This is kind of confusing. Now I'm trying to decide whether I meant 2.6.29
[05:05] <racarr> we definitely determined that the kernel with the stuff needed wouldn't be in jaunty, because it wouldn't be out in time
[05:05] <racarr> and I could have sworn that was .28...but that wouldn't really make much sense
[05:08] <crimsun> 28 will be out in time for jaunty
[05:08] <racarr> Yeah. 2.6.28 is in Jaunty. So I must be confused on when i915 stuff is landing.
[05:08] <racarr> which must then be .29
[05:09] <racarr> alternatively none of us in the plymouth session at UDS could count, and it actually is landing in .28 in time for jaunty
[05:09] <racarr> but I don't think so.
[05:13] <bluesmoke> backport? :)
[05:16] <racarr> So. It's all getting put in a ppa
[05:16] <racarr> to test plymouth, for boot stuff
[05:17] <racarr> but it just happens to conveniently be
[05:17] <racarr> all in the same package
[05:17] <racarr> (kernel modesetting and DRI2)
[05:57] <bluefoxicy> guys I have a question
[05:57] <bluefoxicy> why the fuck is my OpenOffice.org listing fonts as "Normal" "Cursiva" "Negreta" "Negretaa cursiva"
[06:19] <slangasek> surely that question works just as well without the obscenity?
[06:19] <slangasek> bug #105900
[07:07] <tjaalton> racarr: DRI2 doesn't need KMS, so 2.6.28 is enough. just that the current version of -intel in jaunty doesn't support DRI2
[07:07] <tjaalton> there's a new beta available, but it needs a new libdrm which in turn crashes X, so.. :)
[07:07] <racarr> tjaalton: Right. It doesn't need KMS, I was just under the impression that they happened to be in the same release
[07:08] <tjaalton> racarr: nope, KMS for intel is 2.6.29, for ati maybe 2.6.30
[07:11] <racarr> tjaalton: Ah. Ok. That explains my confusion. Thanks.
[10:05] <Keybuk> https://lists.launchpad.net/ubuntu-boot/msg00003.html
[10:06] <Keybuk> ...interesting, but probably not a metric ;)
[10:07] <Keybuk> 72% of the time in initramfs is udev (though probably also waiting for the root fs), and 42% of the time booting the rest of the system is in udevsettle
[10:08] <Koon> Keybuk: interesting, yes :)
[10:09] <NCommander> Keybuk, that's 114% percent O_o?
[10:10] <Koon> NCommander: the two % don't refer to the same thing, so no.
[10:10] <NCommander> oh
[10:10]  * NCommander inserts his foot into his mouth
[10:15]  * RainCT watches NCommander inserting his foot into his mouth
[10:15]  * NCommander turns his foot left
[10:51] <lool> cjwatson: (Pushed pygobject/hardy-proposed)
[10:52]  * lool lunch &
[11:37] <cjwatson> lool: thanks
[16:50]  * lool waves a merry christmas!
[16:51] <iulian> Happy Christmas!
[17:35] <kees> doko_: any chance you're around?  I have a patch to glibc to "fix" bug 305901
[18:27] <gverig> this likely is a dumb question but I can't seem to resolve it on my own. I'm on ubuntu 8.10. What package contains libGL.a?
[18:27] <macd> 'apt-file search libGL.a'
[18:28] <Pici> or use packages.ubuntu.com if you dont have apt-file installed.
[18:28] <macd> what he said too.
[18:28] <macd> ;)
[18:33] <gverig> Searched packages.ubuntu.com. Found one entry: libgl1-mesa-swx11-dev. this is a "This library provides a pure software rasteriser" and it conflicts with half of the system (including "ubuntu-desktop")
[18:33] <gverig> any thoughts?
[18:34] <gverig> there is libGL.so... should i link against some other library?
[18:35] <azeem> gverig: if you're trying to package some software, better ask in #ubuntu-motu; otherwise, ask in #ubuntu
[18:35] <Nafallo> mtr 12.44.117.104
[18:37] <gverig> azeem: I am trying to build something. Something I am trying to write. I asked in #ubuntu they sent me here...
[18:38] <gverig> I want to play with OpenGL a bit. and I can't find a GL library to link to...
[18:38] <ebroder> Find what package is providing your libGL.so, then add -dev to the package name, and see if that gives you the .a
[18:39] <gverig> ebroder: yeah, tried that. libGL.so is provided by libgl1-mesa-dev. No libgl1-mesa-dev-dev :-\
[18:39] <ebroder> Why not just link against the dynamic library?
[18:40] <gverig> ebroder: don't I need an .a file to define how to link against a dynamic library? I have not done much C++ in a loooong while
[18:41] <ebroder> No. .a is the static library, .so is the dynamic library. You don't need one to link against the other
[18:42] <gverig> ebroder: OK, how do I link against dynamic library?
[18:43] <ebroder> No idea - I avoid linkers at all costs :)
[18:43] <gverig> o_O how do you build stuffs?
[18:43] <ebroder> I write everything in Python
[18:43] <gverig> ahh, ok
[18:44] <ebroder> Anyway, azeem is right - this isn't really an #ubuntu-devel question anymore
[19:22] <Treenaks> I just upgraded to jaunty, but now resolv.conf is empty, and I don't have a default route
[19:23] <ion_> It’s a feature. Without proper network access, the computer is now secure.
[19:23] <Treenaks> ion_: except against local attackers :)
[19:23] <Treenaks> ion_: but I wonder where the bug is.. dhcp client? network-manager? resolvconf?
[19:23] <ion_> Computers are never secure against local attackers. :-)
[19:24] <ion_> Dunno. I’ve been considering upgrading as well, perhaps i’ll stumble upon the same problem. :-)
[19:24]  * Nafallo should poke his eeepc
[19:24] <ebroder> Treenaks: Do you have something like NetworkManager installed?
[19:25] <Treenaks> ebroder: I just upgraded a mostly-standard intrepid
[19:25] <Treenaks> ebroder: so yes, I have network-manager
[19:25] <Treenaks> and I've already found something in its log
[19:26] <ebroder> Treenaks: I've never used network-manager, but doesn't it create the resolv.conf file and routes and stuff like that? I'd check its config
[19:26] <Treenaks> ebroder: I know how it should work, it's just not working as it should
[19:26] <Treenaks> ebroder: actually, it worked until a few minutes ago (upgrade to jaunty)
[19:27]  * ebroder shrugs
[19:27] <ebroder> You've officially surpassed my expertise on network-manager :)
[22:00] <ebroder> Hmm...I think the Perl security update broke the Errno module: http://pastebin.com/m6d2b5b9d
[22:00] <ebroder> Is this an actual regression, or just my system being stupid?
[22:02] <ebroder> Oh, never mind - I didn't notice it was in /usr/local
[23:30] <nhandler> nellery: I owe you a thank you. Your merges got me in the Hall of Fame for Sponsoring the Uploads