[01:09] <stgraber> bryce: did you try fglrx on amd64 ?
[01:21] <stgraber> bryce: X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
[01:24] <stgraber> hmm, might just be not working autodetection ... my bad I forgot the device section when writing the xorg.conf (installing by hand so no jockey there)
[01:39] <stgraber> bryce: Yeahh, looks like the best driver from ATI I've ever seen :) Dual-head with 1920x1080 and 1680x1050 working with Compiz and everything.
[01:39] <stgraber> Working RandR really rocks
[01:40] <bryce> stgraber: :-)
[01:41] <bryce> stgraber: yeah remember to update xorg.conf and reboot.  I found it still needed the DefaultDepth parameter too
[01:42] <stgraber> that screen is just too big :) what can I do with 3600x1080 :)
[01:42] <bryce> Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 3840 x 1200
[01:42] <bryce>  ;-)
[01:43] <bryce> new large desktops are like new large hard drives.  The first time they seem impossibly huge, but then you get used to it and everything else seems dinky after that
[01:44] <stgraber> well, the issue is that the second screen is too far, I just can't read it :)
[01:44] <bryce> tell you what, you *don't* play most full screen games on such a setup...
[01:45] <stgraber> I've ET:QW around, will give it a try, I guess it's the first time I'll really use that beast. Basically the first time it works, I've been using mostly my netbook till now because it's an Intel and works fine with dual-head :)
[01:51] <bryce> wow http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-fullyear-open.png
[01:52] <bryce> another nice one http://people.ubuntu.com/~brian/complete-graphs/xserver-xorg-video-ati/plots/xserver-xorg-video-ati-fullyear-open.png
[01:53] <jldugger> do one for invalid bugs ;)
[01:54] <bryce> heh
[01:55] <bryce> http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-fullyear-invalid.png
[01:55] <jldugger> actually, it might help to do one of those graphs where all the categories stack up
[01:55] <jldugger> im clearly going to have to google the actual name for them
[01:55] <bryce> file:///home/bryce/xorg-packagebugs/totals.svg
[01:56] <jldugger> fail
[01:56] <bryce> hehe, oops
[01:56] <bryce> http://people.ubuntu.com/~bryce/totals.svg there we go
[01:57] <bryce> that's total open across all packages under ubuntu-x
[01:57] <jldugger> well, i was thinking more the state of the bugs than which package
[01:57] <jldugger> the idea being you might get a sense of where bugs are flowing to
[01:58] <jldugger> but im not sure that style really helps
[01:58] <jldugger> so nvm
[01:59] <jldugger> like, there's a big bump in nvidia, for example
[01:59] <jldugger> it winds up creating a spike in everything above it
[02:02]  * bryce nods
[02:02] <bryce> yeah, the rate of -nvidia bugs being reported is fairly surprising
[02:02] <bryce> particularly so since there's not much we can do to fix them
[02:03] <jldugger> alternatively, its not surprising, because theres nothing else users can do to fix it
[02:03] <bryce> true
[02:04] <jldugger> and given that upstream has piss poor upstream support, the nvidia package bug page on LP probably rates highly on the google
[02:04] <bryce> ah that'd be a good point
[02:05] <jldugger> (it would be a good point, but it mostly explains me toos, not initial reports)
[02:06] <bryce> it'd be interesting to sum up nvidia -96, 173, 177, 180, fglrx-installer, lrm-2.6.22 and lrm-2.6.24 to see what % of our bugs are proprietary code's fault
[02:06] <jldugger> heh
[02:06] <jldugger> thats a challenge
[02:06] <jldugger> depends on how you define fault
[02:06] <bryce> I think I can do it
[02:06] <jldugger> lemme bring up a hilarious example
[02:07] <bryce> I define it as the ug reporter's fault since they insist on using the drivers in the first place ;-)
[02:07] <jldugger> https://bugs.launchpad.net/bugs/156133
[02:07] <bryce> +b
[02:09] <jldugger> the open source stuff is apparently looking for ALL CAPS, while the package offered lowercase
[02:09] <jldugger> who's fault is that?
[02:12] <bryce> heh
[02:16] <stgraber> hmm, I just have one problem with my dual-head setup, when maximizing a window it takes all the space on both screen instead of only the current one (as I think it used to do), any idea of what's wrong there ?
[02:20] <bryce> what window manager are you using?
[02:20] <bryce> stgraber: you're using -fglrx?
[02:21] <stgraber> bryce: yes
[02:21] <stgraber> same result with metacity and compiz
[02:22] <stgraber> I configured the dual-head using xrandr and a Virtual of the right size, haven't used ati's tool
[02:23] <bryce> not sure, maybe fglrx is bugged
[02:38] <stgraber> bryce: http://paste.ubuntu.com/132801/
[02:38] <stgraber> I guess it's not the expected behavior ? (works though except that window placing/resize issue)
[02:40] <bryce> stgraber: yeah I was getting that on all my xrandr calls too
[02:41] <bryce> however they seemed to work otherwise
[03:35] <bryce> jldugger:  - http://people.ubuntu.com/~bryce/totals-proprietary.svg - proprietary stuff on the bottom now :-)
[03:58] <bryce> hmm, someone's been doing some massive triaging on lrm-*
[04:58] <tjaalton> RAOF: it's been synced already, but FTBFS
[04:59] <RAOF> It'll also need an updated kernel module, I think.
[05:03] <tjaalton> ok
[05:46] <superm1> bryce, well that list of EPR's is likely updated at the time this release turns public and what not
[05:46] <superm1> since they'll publish a PDF then
[09:59] <jcristau> lool: fwiw, Xt apps (xclock) seem to run just fine on agricola.d.o
[10:06] <lool> jcristau: read that, and I have no clue how to debug this
[13:06] <marijus> hello, im using 2.6.29-rc8 with kms but starting compiz seems to freeze X... where do i look for error messeges... couldnt find any in xsession-errors or xorg.log?
[13:09] <tjaalton> doubt people here are that far in the future yet.. try #dri-devel
[13:09] <marijus> ok... tx
[14:24] <seb128> tjaalton: there?
[14:45] <tjaalton> seb128: yes, but not at work to be able to debug the launcher issue :)
[14:45] <tjaalton> just got home
[14:46] <seb128> tjaalton: ok, too bad alex had some debug clue on #nautilus
[14:46] <tjaalton> ok, should I join and write it down?
[14:46] <seb128> well you can join tomorrow from work if you want
[14:46] <seb128> that will probably be easier
[14:46] <tjaalton> ok, I'll poke him then
[14:46] <seb128> he's usually around during european work hours
[14:47] <tjaalton> he's swedish, so -1h from finland :)
[18:38] <mnemo> im on xorg-edgers PPA right now, how can I revert back to ubuntu proper??
[18:46] <maxb> Remove the PPA from your sources.list, use apt-show-versions to locate packages which have a newer version than available in your enabled sources
[19:02] <mnemo> "apt-show-versions | grep -v uptodate" did the trick
[19:02] <mnemo> thanks
[20:08] <bryce> tjaalton: you around?
[20:08] <tjaalton> bryce: yup
[20:09] <bryce> tjaalton: I've done some testing on the xorg update I'm going to upload today
[20:09] <bryce> unfortunately the fix to 60x11-localhost doesn't seem to work
[20:09] <tjaalton> oh right
[20:09] <bryce> X runs fine, but the file is not removed
[20:09] <bryce> but I don't grok the code well enough to spot what the flaw is
[20:09] <jcristau> the 'remove obsolete conffile' thing seemed incomplete
[20:10] <jcristau> as far as i could tell from the commit mail
[20:10] <bryce> jcristau: what else is required?
[20:10] <jcristau> you need to call remove_conffile_prepare in preinst, and _rollback in postrm abort-upgrade
[20:11] <jcristau> as far as i can tell you only had remove_conffile_commit, right?
[20:11] <bryce> right
[20:11] <tjaalton> hmm
[20:11] <tjaalton> so it was more complex than I thought
[20:12] <tjaalton> well, once xserver 1.7 is in karmic or karmic+1, we probably don't need the file at all, since it looks like the default will be changed
[20:12] <bryce> jcristau: thanks, I'll give that a shot
[20:12] <tjaalton> AIUI
[20:12] <jcristau> preinst moves foo to foo.x11-common-tmp; postinst removes it if successful, and postrm moves it back in the rollback case
[20:13] <bryce> oh, I should add to preinst too?
[20:14] <jcristau> the more common approach is to just remove the conffile in preinst, but we have inherited these functions from branden, and he was pretty anal about his maintainer scripts so they handle failed upgrades :)
[20:15] <tjaalton> bryce: yes, I can see that the xorg-common -scripts are in all three files (preinst, postinst, postrm), duh
[20:15] <tjaalton> which I added a while back
[20:15] <tjaalton> (removals)
[20:15] <bryce> ok, giving it a go
[20:18] <jcristau> xutils uses them too, if you need an example usage
[20:19] <tjaalton> that's what I used too, IIRC
[20:22] <bryce> hrm, still not working
[20:26] <bryce> what does the $2 mean here?
[20:26] <bryce>   if dpkg --compare-versions "$2" lt-nl "1:7.4~5ubuntu16"; then
[20:27] <jcristau> $2 is the version you're upgrading from
[20:27] <jcristau> (or empty for initial install)
[20:27] <tjaalton> so it won't work if you reinstall the same version
[20:28] <bryce> I've been downgrading x11-common back to 5u15 for testing
[20:28] <tjaalton> ah
[20:28] <bryce> is that the right package or ...?
[20:28] <jcristau> yeah
[20:28] <bryce> hrm
[20:33] <bryce> shall I just commit what I have so far to git, for you guys to review?
[20:34] <bryce> otherwise I'm tempted to just leave this fix out of this 5u16 and work on it later
[20:36] <bryce> this is what I have for committing -> http://people.ubuntu.com/~bryce/localhost_2.patch
[20:37] <jcristau> bryce: s/xinit/x11-common/?
[20:37] <tjaalton> heh :)
[20:37] <bryce> well, the other Xsession.d scripts say xinit
[20:38] <tjaalton> because they used to be in xinit
[20:38] <tjaalton> IIRC
[20:38] <bryce> oh
[20:39] <tjaalton> but removed in x11-common for some reason I can't remember
[20:39] <jcristau> the package name there is used to look up the conffile's checksum in dpkg's status db
[20:40] <bryce> finally, that did it
[20:40] <bryce> ok thanks
[20:41] <bryce> ok, everything is pushed
[20:43] <bryce> xorg-7.4~5ubuntu16/debian/apport/server-0.xkb ???
[20:45] <tjaalton> hm?
[20:46] <bryce> just a stray file I guess.  Not sure where that came from
[20:46] <bryce> http://people.ubuntu.com/~bryce/xorg_7.4~5ubuntu16.debdiff
[20:48]  * bryce adds x11-common.preinst.in, x11-common.postrm.in to changelog
[20:55] <bryce> final changes pushed; 5u16 uploaded to jaunty.  thanks again.
[20:58] <bryce> tjaalton: did you see http://lwn.net/Articles/323668/ ?
[20:59] <bryce> seems there are as many people thinking we should have stuck with 2.5 as there are pushing us for going to 2.7.  heh
[21:08] <tjaalton> bryce: hehe
[21:32] <andersk> It seems that current fontconfig-config in Jaunty forces the creation of /etc/fonts/conf.d/10-no-sub-pixel.conf and is no longer configurable? 
[21:32] <tjaalton> talk to asac
[21:33] <tjaalton> but first update to ubuntu10
[21:34] <andersk> I have 2.6.0-1ubuntu10. 
[21:34] <tjaalton> ok
[21:35] <andersk> `dpkg -c fontconfig-config_2.6.0-1ubuntu10_all.deb` indicates that it really does contain /etc/fonts/conf.d/10-no-sub-pixel.conf. 
[21:36] <tjaalton> so talk to asac
[21:36] <tjaalton> and file a bug
[21:37] <jcristau> andersk: 'sudo rm /etc/fonts/conf.d/10-no-sub-pixel.conf' doesn't make you happy?
[21:44] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/ --> down to 5 bugs
[22:45] <andersk> jcristau: It does, but only until the next fontconfig-config upgrade. 
[22:45] <andersk> Anyway, reported as bug 345123. 
[22:45] <jcristau> andersk: no
[22:46] <jcristau> it shouldn't come back on upgrade
[22:46] <andersk> Well, it has disappeared during the last few upgrades, and I also tested it with `aptitude reinstall`. 
[22:49] <andersk> I tested again by downgrading to -ubuntu9, removing the symlink, and upgrading to -ubuntu10; the symlink came back. 
[22:51] <jcristau> weird.
[22:52] <bryce> jcristau: should the /usr/bin/X11 symlink still exist?
[22:52] <bryce> root@dorset:/etc/X11# ls -ld /usr/bin/X11
[22:52] <bryce> lrwxrwxrwx 1 root root 1 Mar 19  2008 /usr/bin/X11 -> .
[22:52] <bryce> oh nevermind, I got it.
[22:53] <andersk> Even if I create an empty file 10-no-sub-pixel.conf, it is deleted and the symlink is recreated on reinstall. 
[22:53] <jcristau> bryce: yes, that's ok
[22:54] <andersk> According to /var/lib/dpkg/info/fontconfig-config.conffiles, /etc/fonts/conf.avail/10-no-sub-pixel.conf is listed as a conffile but /etc/fonts/conf.d/10-no-sub-pixel.conf is not. 
[22:56] <andersk> Debian #421344 and #421345 might be relevant. 
[22:57] <andersk> And Debian #421346 
[22:59] <bryce> sweet, 'xorg' bugs are all done.
[23:13] <bryce> I pity the fools who insist on installing the latest drivers (e.g. -fglrx) yet don't know anything about xorg.conf configuration and get screwed up as a result... 
[23:14] <marijus> bryce: well, learning by doing... isnt it?
[23:17] <bryce> guess it'll have to be ;-)
[23:17] <bryce> I put a more kindly worded variant of the above onto bug #313027
[23:21] <marijus> :)