[01:53] <bryce> tjaalton: I notice that a lot of the proto libs on http://people.ubuntu.com/~bryce/Xorg/versions_current.html aren't syncing to debian, but aren't listed on MoM either...  any ideas what's up with them?  
[01:53] <bryce> I suspect the ubuntu changes can just be dropped
[01:58] <pwnguin> bryce: i think those were stupid epoch changes?
[02:00] <bryce> yeah possibly, although some aren't epoched
[02:00] <pwnguin> i know epoch's a pita for wacom
[02:44] <bryce> wtf, will bug reporters never learn to attach their Xorg.0.log file??
[02:48] <pwnguin> i didnt do it
[02:54] <pwnguin> exit
[02:54] <pwnguin> doh
[03:01] <pwnguin> i should go through and clean up wacom bugs a bit
[03:30] <bryce> that'd be a big help.  I hardly ever look at those myself
[04:23] <pwnguin> hmm
[04:23] <pwnguin> on #179453, one person says its fixed and the other says it's broke
[04:25] <pwnguin> if the original reporter says it's broke, should i mark it incomplete?
[05:53] <tjaalton> bryce: different tarballs
[05:53] <tjaalton> so nothing we can do unless upstream releases new versions
[06:00] <tjaalton> there should be no epoch changes in XSF maintained packages (which wacom-tools is not)
[06:01] <tjaalton> I mean epochs in our versions..
[06:02] <pwnguin> ah thats right
[06:02] <pwnguin> packaging is so confusing somehow ;)
[06:02] <tjaalton> bah, straightforward and easy :)
[06:03] <tjaalton> ..if you know the policy manual inside-out (which I don't)
[06:12] <tjaalton> bryce: so, if the tarball is different, the package should be fakesynced; unpack the debian version, change the maintainer, add a changelog entry, and before building the new source package move our tarball in place so it uses that one
[09:09] <bryce> tjaalton: ah ok; what's the easiest way of detecting that it's a tarball difference?
[09:11] <tjaalton> bryce: reading the changelog :)
[09:11] <tjaalton> if it says "fake sync"
[10:22] <tjaalton> tseliot: btw, were you building a xorg.conf parser? fedora already has a library for that, called libxf86config
[10:23] <tseliot> ﻿tjaalton: yes, I did it
[10:24] <tseliot> I'll have a look at their parser
[10:27] <tseliot> tjaalton: they hardcoded resolutions???
[10:27] <tjaalton> tseliot: hm?
[10:28] <tjaalton> you only need to look at gutsy and see that we did the same
[10:28] <tseliot> in their parser, I mean
[10:28] <tjaalton> don't know, never looked at it
[10:29] <tseliot> it looks like that parser relies on ixf86config, which I can't find...
[10:34] <tseliot> ok, found
[10:35] <tseliot> no, not really
[11:45] <tjaalton> so that Ademan-guy is trying to write a program to configure mice..
[11:45] <tjaalton> there should be one already, but can't remember the name
[14:41] <tselio1> tjaalton: I'm glad to have warned you against updating the fglrx driver for Ubuntu's .1 release. I'm working on the -envy package and I'm facing a black screen
[16:12] <tjaalton> tselio1: joy..
[16:14] <tselio1> ﻿tjaalton: I have tried removing all the patches in lrm (even though they were applied without problems), I have tried the installer from AMD without solving the problem.
[16:14] <tselio1> the new beta driver works
[16:14] <tselio1> but I can't include it since it experimental and secret
[16:14] <tselio1> :-/
[16:15] <tselio1> I will update only the NVIDIA driver
[16:18] <tjaalton> ok
[17:51] <tjaalton> pwnguin: I've merged wacom-tools, but let's see if it builds on ppa
[18:45] <pwnguin> tjaalton: excellent!
[18:46] <pwnguin> i should probably upgrade my laptop
[18:53] <bryce> heya
[19:05] <pwnguin> bryce: is there a decent way to distinguish between a kernel freeze and an X freeze?
[19:09] <pwnguin> i recall mjg saying the capslock key was helpful for determining whether a laptop had failed to resume or simply failed to bring up video
[19:42] <bryce> pwnguin: ssh seems to be a good distinguisher
[19:43] <bryce> if you can't ssh into the box, it's likely something's wrong with the kernel, not just X
[19:45] <tseliot> ﻿bryce: did you have a look at my changes to the wiki?
[19:46] <tjaalton> GPU lockups tend to freeze the machine
[19:47] <tjaalton> sorry, that's not correct
[19:50] <tjaalton> the kernel should be alive then
[19:51] <bryce> tseliot: not yet, going to do so today (I ended up spending yesterday mostly sponsoring uploads)
[19:52] <tseliot> ﻿bryce: no problem, I know that you're all very busy ;)
[22:11] <unggnu> hi all
[22:11] <bryce> heya
[22:11] <unggnu> https://wiki.ubuntu.com/X/Backtracing - Debug symbol information
[22:11] <unggnu> hi bryce
[22:12] <bryce> cool thanks
[22:12] <unggnu> It is a little to complicated atm imho. The dbgsym packages aren't needed anymore for Gutsy an later afaik so what do you think about cleaning it up?
[22:13] <unggnu> And it seems that libgl1-mesa-dri-dbg is also needed.
[22:13] <unggnu> I thought about
[22:13] <unggnu> You will need to install the package {{{xserver-xorg-core-dbg}}}, {{{libgl1-mesa-dri-dbg}}} and if available the one for your graphic driver {{{xserver-xorg-video-<name>-dbg/sym}}}.
[22:15] <unggnu> Is it ok?
[22:16] <tjaalton> bryce: re: the brainstorm blog entry; radeon is not blacklisted :)
[22:16] <bryce> tjaalton: in hardy?  are you sure?
[22:16] <bryce> unggnu: I think cleaning it up is a brilliant idea.  Go for it if you're up for it.  :-)
[22:16] <tjaalton> less =compiz
[22:16] <unggnu> thx :)
[22:17] <tjaalton> the version in proposed blacklists i815, but nothing else
[22:17] <bryce> oh they took it out recently?
[22:18] <tjaalton> unless there's another blacklist somewhere
[22:18] <tjaalton> well, the released version didn't blacklist any chips
[22:18] <tjaalton> so i815 was added recently
[22:19] <tjaalton> I thought that the mobile chips were blacklisted, but apparently not
[22:22] <tormod> tjaalton, bryce: you talking about compiz blacklisting?
[22:22]  * bryce nods
[22:23] <tormod> radeon on laptops is blacklisted AFAIK
[22:23] <tjaalton> tormod: but where? the compiz wrapper doesn't show it
[22:23] <bryce> tjaalton: well, anyway radeon was blacklisted at the point I looked into it
[22:23] <tjaalton> yeah
[22:24] <tormod> line 268 of /usr/bin/compix
[22:24] <tormod> *compiz
[22:24] <bryce> hmm, yeah still there
[22:24] <tormod> OTOH the PCIID blacklist is commented out
[22:24] <bryce> radeon is blacklisted for laptops only -- I might have not made that clear in my post
[22:25] <tjaalton> aha! :)
[22:25] <tjaalton> didn't look far enough
[22:25] <tjaalton> anyway, night ->
[22:25] <bryce> cya
[22:33] <tormod> bryce, for sponsoring, do you have special tools, or do you have to do all the unpacking, patching, building dance - so in the end you could have fixed smaller things more efficiently yourself instead of using someone's debdiff?
[22:34] <bryce> well, even in those cases, having the debdiff to reference does help speed the process
[22:36] <bryce> the main "tool" I use, 'debsponsor' is an alias
[22:36] <bryce> alias debsponsor='debsign -ke0e67611'
[22:36] <bryce> where that hex code is my pgp key
[22:36] <tormod> I guess I should ask dholbach (again) since the sponsoring seems inefficient and has a huge backlog
[22:37] <tormod> apropos your pgp key, you saw the comment in -devel earlier about your signed .changes files :)
[22:37] <bryce> tormod, you ought to work towards getting motu and core dev
[22:38] <tormod> I think there should be easy for people like me (non-devs) to contribute efficiently anyway
[22:39] <tormod> it's already great in Ubuntu, but could be better
[22:39] <bryce> agreed
[22:39] <bryce> yes agreed
[22:39] <tormod> personally I am not interested in Universe, and not enough time to think about core-dev
[22:40] <tormod> I just want to get my stuff fixed fast :)
[22:40] <bryce> yeah I saw the comment about the .changes.  In this case I don't think it matters.  I almost uploaded the package myself, just wanted to get a validation
[22:41] <bryce> fwiw, the easiest situation from a sponsoring point of view, is if you do the packaging to produce a .dsc and .changes, and put that somewhere I can pull
[22:41] <tormod> well I thought it was funny because I didn't think about that possibility, although someone already tried to upload my ppa packages to hardy proper :)
[22:42] <bryce> (then I can review, and then just debsponsor it up)
[22:43] <tormod> I am surprised if daniel doesn't have a script to pull down a debdiff and generate all that :)
[22:43] <bryce> possibly
[22:44] <tormod> was sponsoring discussed at UDS?
[22:44] <bryce> I'm relatively new to sponsoring stuff (I got the powers after feature freeze, so only recently have had many opportunities to use them)
[22:44] <bryce> hmm, if so it was in a session I didn't attend
[22:46] <tormod> well I should let you to time to look at that laptop-mode-tools patch instead of asking all these questions ;)
[22:46] <bryce> hehe
[22:52] <bryce> weird:
[22:52] <bryce> $ apt-cache madison laptop-mode-tools
[22:52] <bryce> laptop-mode-tools | 1.42-1ubuntu1 | http://us.archive.ubuntu.com intrepid/main Packages
[22:52] <bryce> laptop-mode-tools | 1.35-1ubuntu1 | http://us.archive.ubuntu.com intrepid/main Sources
[23:02] <tormod> bryce, thanks! I guess I just ran "dch -i" and forgot to change the release
[23:02] <bryce> no prob