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