[06:05] <tjaalton> pwnguin: wacom-tools built fine, now uploaded to intrepid
[06:14] <pwnguin> neat
[06:15] <tjaalton> there's at least one big regression reported on debian
[06:15] <tjaalton> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482826
[06:16] <tjaalton> but maybe that's already on launchpad
[06:37] <pwnguin> i saw that before when i was checking for crazy bugs, but i only skimmed it and thought it was some goofy joystick thing
[06:37] <pwnguin> perhaps not
[06:37] <pwnguin> guess i need to upgrade to intrepid
[06:39] <tjaalton> i can crash the server if using input-hotplug and plugging in a joystick and move it :)
[06:39] <tjaalton> maybe 1.5 is better
[06:39] <tjaalton> it'd better be :)
[06:42] <pwnguin> so on a scale from 1 to 10, how likely is an ibid upgrade to work?
[07:22] <tjaalton> don't know, i'm not running intrepid yet
[08:10] <bryce> I put intrepid on one of my boxes early on, and have been updating it irregularly; no problems so far
[08:10] <bryce> I use it more as a build server than as a desktop though
[08:12] <pwnguin> my laptop has two installed ubuntus
[08:12] <pwnguin> i normally keep a stable and a dev with a shared /home
[08:14] <tjaalton> how do you handle grub?
[08:14] <pwnguin> very carefully
[08:15] <pwnguin> if i were smarter
[08:15] <tjaalton> you don't have a shared /boot?-)
[08:15] <pwnguin> id have grub installed to the partions and basically a dual stage grub
[08:15] <pwnguin> or a /boot
[08:15] <tjaalton> right
[08:15] <pwnguin> but the dual stage would actually work
[08:15] <pwnguin> a shared /boot wont
[08:19] <tjaalton> bryce: btw, you can drop fonttosfnt from the status page. also lrm, mesa-utils, and probably compiz should be dropped as well (compiz not maintained by us)
[08:20] <tjaalton> and I'm wondering about dropping unichrome from the archive..
[08:20] <tjaalton> upstream is hostile and not willing to make releases :)
[08:21] <tjaalton> and too busy updating it
[08:23] <bryce> tjaalton: the script just pulls from what's on https://bugs.launchpad.net/~ubuntu-x-swat/+packagebugs
[08:23] <tjaalton> bryce: oh :)
[08:24] <bryce> plus a handful of extra packages (like mesa) that I added
[08:24] <tjaalton> mesa and mesa-utils have the same source (mesa)
[08:25] <bryce> hmm
[08:25] <bryce> I don't specifically add mesa-utils... it must magically come in somehow
[08:26] <bryce> anyway, in general what's included in the report can be controlled by subscribing/unsubscribing ubuntu-x-swat
[08:27] <tjaalton> fonttosfnt is not on that page, and why aren't the other lrm's listed?
[08:28] <bryce> yeah I don't know how fonttosfnt is sneaking in...  looking into that
[08:28] <bryce> for lrm, hmm...  maybe the version number is getting parsed out or something... not sure
[08:29] <tjaalton> also x11-common is unnecessary on that page
[08:29] <tjaalton> source is xorg
[08:30] <bryce> ok, nuked
[08:30] <bryce> btw, here's the current "extra" packages:
[08:30] <bryce>        x11-apps x11-utils x11-xfs-utils
[08:30] <bryce>        x11-xkb-utils x11-xserver-utils
[08:30] <bryce>        xserver-xorg-video-avivo
[08:30] <bryce> 	xserver-xorg-video-psb
[08:30] <bryce>        xserver-xorg-video-openchrome
[08:30] <bryce>        xserver-xorg-video-radeonhd
[08:30] <bryce>        libdrm2
[08:30] <bryce>        libxcb
[08:30] <bryce>        mdetect
[08:30] <bryce>        libpixman
[08:30] <bryce>        xserver-xgl
[08:31] <bryce> probably would be better for us to sub -swat to those
[08:31] <tjaalton> already is
[08:31] <tjaalton> not mdetect though
[08:31] <tjaalton> libdrm2 source is libdrm
[08:32] <tjaalton> all the x11* are subscribed
[08:32] <tjaalton> avivo is not in the archive anymore
[08:33] <tjaalton> libxcb is missing, subscribing
[08:35] <bryce> ah, the reason lrm-2.6.24 is the only one listed is because the script only checks hardy and intrepid, and older lrms aren't seen by apt-cache madison
[08:36] <bryce> when there is a lrm-2.6.25, and when it's subbed by -swat, in theory it should just show up
[08:36] <tjaalton> but what does it give us?-) debian doesn't have that
[08:36] <tjaalton> and probably it won't even include any video drivers anyway
[08:37] <bryce> then if we don't sub -swat to it, we'll not see it
[08:37] <bryce> and lrm-2.6.24 will drop off when we move to intrepid+1
[08:38] <tjaalton> ok.. let's wait for the split
[08:39] <bryce> hmm, I'm a little mystified by fonttosfnt.  By chance did you unsub us from that recently (within the last 24 hrs?)
[08:39] <tjaalton> and yes, mesa-utils is subscribed because there was a source package named mesa-utils. but since there are no bugs assigned to it, I'll unsub from it
[08:39] <tjaalton> no, must've been before
[08:39] <tjaalton> when it was dropped from intrepid
[08:40] <tjaalton> it had no bugs
[08:41] <bryce> I'll regen the page and we can see where we're at
[08:41] <bryce> maybe fonttosfnt will just drop off
[08:42] <tjaalton> yeah
[08:44] <bryce> ok reload
[08:44] <bryce> hrm still there
[08:45] <tjaalton> stubborn lil' bastard
[08:49] <bryce> ahhh I know
[08:49] <bryce> the way the script works, I guess it's a little backwards than we'd expect
[08:49] <bryce> first it looks at the xorg releases page and gets a list of packages from that
[08:50] <bryce> then it looks at hardy and intrepid to see if they carry any of those packages listed according to apt-cache madison, and if so, it includes them
[08:50] <tjaalton> heh :)
[08:50] <bryce> then it also overlays additional packages listed on the -swat report 
[08:51] <bryce> so fonttosfnt gets grandfathered in since xorg still carries it, and because it's present in hardy
[08:58] <tjaalton> ok, unless it's easy to blacklist it from the script, let's live with it :)
[09:07] <bryce> if it really bugs you I can blacklist it, but it doesn't bother me (it doesn't affect the ultimate stats, and I like having the 'history' showing what we dropped)
[14:17] <tjaalton> bryce: no it's fine
[20:28] <mnemo> i need to rebuild my X.org DRI module but autoconf says "cant find dri2proto"... what package do I need to install?
[20:31] <jcristau> there isn't one for dri2proto yet
[20:31] <jcristau> so --disable-dri2
[20:32] <mnemo> ah, it's a new feature which is not used in ubuntu yet?
[20:33] <mnemo> hmm, it didn't work.. seems like the driver still checked for dri2proto
[20:33] <jcristau> what driver is that?
[20:33] <mnemo> intel
[20:33] <mnemo> im trying to build i965 dri module
[20:33] <jcristau> oh
[20:35] <jcristau> well you can build a package from git://git.debian.org/git/pkg-xorg/proto/x11proto-dri2
[20:35] <mnemo> thanks I'll give it a try
[20:37] <mnemo> that one says "make: nothing to be done"
[20:38] <jcristau> it shouldn't
[20:39] <mnemo> when I run ./autogen.sh it creates dri2proto.pc
[20:39] <mnemo> and then exits
[20:40] <jcristau> right
[20:41] <mnemo> is that how it's supposed to work?
[20:43] <jcristau> it's a bunch of headers, so there's nothing to build. if you want a package, run 'dpkg-buildpackage -b'
[20:44] <mnemo> ahh I see.. I've never seen such a thing before
[20:44] <jcristau> a debian package?
[20:45] <mnemo> well I've seen .deb files before but never some source code from git that was supposed to converted directly into a .deb
[20:45] <jcristau> ok
[20:46] <mnemo> i usually just try "./configure ; make ; make install" or maybe ./autogen.sh if it exists
[20:46] <mnemo> there is some many different instructions for different packages
[20:46] <mnemo> very hard to get started learning about these things
[20:47] <mnemo> i mean, a simple INSTALL or README file for the x11proto-dri2 would have come a long way
[20:47] <jcristau> './autogen.sh; make; make install' would have worked
[20:48] <mnemo> ah, I got stuck on "make" because it said it did nothing but I suppose that was "by design" sort of
[20:48] <jcristau> right
[20:49] <mnemo> another problem getting started contributing to x.org in ubuntu is that it's so hard to get an overview of all the packages and how they interact with each other... like what is DRI, DRM, MESA and so on.. i want to help but I get totallt confused by all these packages that depend on each other ;/
[20:49] <jcristau> we all are
[20:49] <mnemo> ;)
[20:49] <bryce> yeah me too
[20:49] <mnemo> haha =)
[20:50] <jcristau> i suppose i should get the dri2proto packages in debian at some point
[20:50] <bryce> mnemo: I've found phoronix sometimes has really good articles explaining what the acronyms and such mean
[20:50] <mnemo> cool
[20:50] <bryce> it'd sure be nice to have an "X.org glossary"
[20:51] <bryce> and I definitely agree an overview document explaining how all the various gears interact would be handy
[20:52] <bryce> you can sort of piece things together via the X.org website and wikipedia
[20:52] <bryce> but the dependencies are still confusing
[20:52] <mnemo> yeah, it's like a puzzle and just when you think you got it they invent ttm or something like that, heh
[20:53] <bryce> and just as you come to terms with ttm, they change their mind and switch to using gem
[20:53] <bryce> and then gem isn't available yet X-P
[20:53] <mnemo> ;>
[21:02] <jcristau> i thought the problem was that nobody had come to terms with ttm, really
[21:05] <bryce> jcristau: the article on phoronix about it and gem makes it sound like keithp and co. have no intent to support seeing ttm upstreamed, and prefer to wait until gem is ready to go
[21:06] <jcristau> i don't read phoronix. i read the thread on dri-devel and the article about it on lwn though
[21:06] <bryce> tjaalton: I'm going to try dropping the greedy patch from -intel 2.3.1.  I *think* we no longer need it, but I'll just comment it out in case folks find it's still needed.
[21:06] <bryce> tjaalton: the patch still applies and builds, so if we need it, it should be easy to switch back on
[21:07] <jcristau> but, yeah, the intel guys don't seem too happy about ttm, hence gem
[21:08] <bryce> from what I know of the kernel guys, it'd surprise me if they took ttm when there isn't a consensus, esp. without keithp's backing.  And if the kernel is iffy on taking it, I wouldn't imagine many driver developers putting time into it
[21:09] <bryce> but who knows; if red hat strongly favors it and is pushing hard for it... 
[21:10] <jcristau> the only ttm user is poulsbo, afaik
[21:12] <bryce> doesn't redhat also have patches enabling it for -intel in fedora9?
[21:13] <jcristau> yeah, probably, for the modesetting stuff. but that just needs a memory manager, not necessarily ttm
[23:08] <Q-FUNK> ok, I have new -nsc and -geode packages in my PPA with the GX2 support pulled back into geode and removed from nsc.
[23:18] <tjaalton> bryce: ok, sounds fine. there's time to experiment