[00:20] <bryce> whoohoo  [ANNOUNCE] xf86-video-ati 6.10.0
[13:09] <seb128> hey there
[13:10] <seb128> we did try to drop the forced 96 dpi settings in gutsy but that didn't work that great, do you think we should try again this cycle?
[13:17] <tjaalton> what happened then?
[13:17] <tjaalton> I mean what problems came up?
[13:19] <seb128> tjaalton: sort of bug flood about users having incorrect values being used
[13:19] <seb128> their font not looking right, that sort of things
[13:19] <seb128> ie, too many case where xorg doesn't get it right
[13:22] <jcristau> (or where monitors lie)
[13:22] <tjaalton> was just going to say that..
[13:24] <seb128> bug #118745)
[13:24] <seb128> that's the bug we got back then
[13:25] <seb128> there is one guy on #ubuntu-desktop arguing that nowadays it's better to let xorg does its job rather than force 96dpi because the number of case where 96 dpi is wrong is higher than the number of cases where xorg is wrong
[13:25] <seb128> do you have any opinion on the topic?
[13:25] <seb128> I guess we could just try for a while in jaunty and see the users reactions
[13:26] <tjaalton> where is it forced?
[13:26] <jcristau> tjaalton: gdm starts X with -dpi 96
[13:26] <jcristau> iirc
[13:27] <tjaalton> grep doesn't show any results here, on hardy
[13:27] <tjaalton> ah, libgnome
[13:28] <jcristau> oh.
[13:28] <tjaalton> /desktop/gnome/font_rendering/dpi       96.0
[13:30] <tjaalton> seb128: I'd be ok with it, but maybe ask bryce too :)
[13:33] <seb128> tjaalton: right, libgnome, see the bug I listed before, we decided to change gnome-settings-daemon to set it to 96 by default
[13:33] <seb128> or rather to change the gconf key used by gnome-settings-daemon
[13:35] <tjaalton> right
[16:50] <Ng> seb128: I'm quite keen to see the DPI thing looked at, mainly because GDM is entirely unusable on my TV at home - 1920x1080 and the fonts render so small that they can't even be read if you're 10cm from the TV ;)
[16:52] <seb128> Ng: gdm doesn't use gconf so you get the xorg dpi used there
[16:53]  * mvo almost wanted to say something about glasses but he does not
[16:59] <Ng> seb128: ah, damn
[16:59] <Ng> mvo: I have perfect vision! there literally aren't enough pixels in the fonts to be able to read them
[16:59] <Ng> it makes the failsafe X thing impossible to use too, which is a shame since I regularly break my X config on that machine ;)
[17:02] <mvo> haha
[17:25] <superm1> tseliot, i'm going to need to upload nvidia 180 again because vdpau stuff needs to be pulled out of the regular -dev package and regular glx package for stuff to build depend against it properly.  did you have any other pending changes to get in it?  I also need to rev it to the new version so that mythtv can build against it
[17:26] <superm1> also is there any particular reason that the modaliases is arch dependent?
[17:30] <tseliot> superm1: feel free to update it. I would like to have a look at the new source if you don't mind.
[17:30] <tseliot> superm1: a user suggested this patch as he said that the modaliases are broken in the latest release: http://launchpadlibrarian.net/20917045/nvidia-180-modaliases-fix.patch
[17:30] <superm1> tseliot, well there are a variety of ppa's that people have made changes with, so i'll probably base it off of one of those.
[17:30] <superm1> yeah that's the one i was grabbing
[17:31] <superm1> i need to make sure that the mythtv build actually works before i do any of this, but just checking if you had any other stuff in the pipe on this upload
[17:31] <tseliot> superm1: as regards modaliases, they have to be arch-specific
[17:31] <superm1> tseliot, why is that?
[17:32] <tseliot> otherwise they will break a few things (as cjwatson reported)
[17:32] <superm1> hum interesting. is there a bug on this?
[17:32] <superm1> or just side chatter that was reported in irc at some point?
[17:32] <tseliot> let me check
[17:32] <jcristau> so they're not available on !x86, i guess?
[17:33] <superm1> oh that would probably make sense - which would also mean i can't let the nvidia-180-libvdpau-dev package i was going to make be arch all can i..
[17:35] <tseliot> superm1: maybe I confused it with nvidia-common. But anyway it makes sense to have them arch specific since they really support only x86 x86_64
[17:36] <superm1> hmm.  ok..
[17:36] <tseliot> superm1: let me know when the package is ready
[17:36] <superm1> i've got it readyish right now, but i'll show you after i verify the test builds with mythtv in case i need to touch anything else in it
[17:45] <tseliot> ok
[19:00] <superm1> tseliot, still there?
[19:03] <superm1> tseliot, here's the diff i'm planning to upload if you'd like to take a look: http://pastebin.com/f6e8ce16f
[19:03] <superm1> main thing i'm concerned about is the way i named those vdpau packages, i'm thinking ahead to try to prevent conflicts with the next series of drivers (188 or what not)
[19:04] <superm1> but otherwise this diff works to build myth against vdpau
[19:08] <superm1> in tseliot's absence, can I get another set of eyes on those packaging changes before I upload?  bryce or tjaalton ?
[19:18] <bryce_> superm1: hmm
[19:19] <bryce_> superm1: you could more explicitly reference the nvidia_supported change in the changelog; it's not obvious which changelog entry belongs to that change
[19:19] <superm1> bryce, ok will do.  
[19:19] <superm1> bryce, i'm particularly referring to the vdpau packaging changes - those package names in the control file seem appropriate?
[19:20] <bryce_> otherwise looks like it's mostly doing a s/180.11/180.18/g, which all looks fine
[19:20] <bryce_> superm1: I don't have a problem with them, but I'd defer to others opinions
[19:21] <tseliot> superm1: here I am
[19:21] <superm1> tseliot, hi
[19:22] <bryce_> superm1: libvdpau-180 could be another alternative for naming, however I like how it puts this into the nvidia namespace
[19:23] <superm1> bryce, i thought about that, but in theory another vendor could put together a vdpau api compatible package, which is why i didn't want to hardcode it
[19:23]  * tseliot has a look at the diff
[19:23] <bryce_> superm1: ah true
[19:25] <tseliot> superm1: nvidia-180-libvdpau-dev can't be arch = all as it depends on nvidia-180-libvdpau (which is i386 or amd64)
[19:26] <superm1> is that against debian policy though?
[19:26] <superm1> usually -dev packages with headers only are arch all
[19:27] <tseliot> superm1: I was worried about having broken dependencies on architectures other than i386 and amd64
[19:27] <superm1> bryce, what do you think on that?
[19:30] <bryce> -nvidia is only relevant on i386 and amd64 anyway, right?
[19:30] <bryce> but yeah I thought most -dev packages were arch all, since they're usually just headers and stuff
[19:35] <tseliot> superm1: the diff looks good but keep in mind that I'm tired and so are my eyes ;)
[19:35] <superm1> well if anything when an archive admin NEW's this, they'll make the final call on it
[19:35] <tseliot> right
[19:36] <superm1> tseliot, okay well if anything comes up, i'll be glad to help get another upload to take care of it. thanks!
[19:36] <tseliot> superm1: thank you ;)
[19:43]  * tseliot > off for a bit
[19:45] <superm1> cya
[19:59] <bryce> anyone else seeing PrintScreen breakage?  (305695)
[20:03] <superm1> bug 305695
[20:04] <superm1> yeah i saw that yesterday and filed a duplicate
[20:04] <crevette> bryce this is fixed by latest metacity
[20:04] <crevette> 2.25.89 afaik
[20:04] <crevette> s/afaik/IIRC/ :)
[20:06] <bryce> crevette: interesting; where did you learn that?
[20:06] <crevette> https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/312522
[20:06] <crevette> I packaged it
[20:06] <crevette> waiting to be sponsored
[20:06] <bryce> ahh ok
[20:06] <crevette> and in my ppa if you want
[20:08] <bryce> ok
[20:09] <bryce> link?  https://edge.launchpad.net/~crevette/+archive doesn't work
[20:09] <crevette> but https://edge.launchpad.net/~bmillemathias/+archive/ will :)
[20:10] <crevette> I should change my nick
[20:10] <crevette> don't pick all my updates
[20:11] <bryce> mm, maybe I should hold off updating this system since I'm using it for day to day testing
[20:11] <crevette> ah :)
[20:11] <crevette> sure
[20:11] <bryce> but thanks, I'll add all this info to the bug for other testers (seems we have plenty)
[20:12] <crevette> perhaps I should update the changelog to include one bug and duplicate all others ?
[20:15] <bryce> no, should leave the bugs separate, unless they literally are exactly the same bug
[22:34] <bryce> superm1: hey do you know anything about color depth issues with the new -nvidia?
[23:09] <superm1> bryce, no i haven't heard anything of the sort
[23:09] <superm1> bryce, encountering them?
[23:10] <bryce> superm1: rickspencer is, although he's fiddling with nvidia-xconfig to correct it (he's ran into some configuration troubles)
[23:10] <superm1> on jaunty?
[23:11] <bryce> yep
[23:12] <bryce> I'll help him file a bug if he's still having problems tomorrow.
[23:13] <superm1> is ignoreabi still necessary for 180 drivers with the upload i put in?  I was only testing it with intrepid (no ignoreabi necessary still)
[23:14] <bryce> dunno
[23:14] <superm1> ill take a look tomorrow and see
[23:14] <bryce> ok
[23:22] <andersk> I’ve been running 180.18 for a while, and it still needs IgnoreABI, unless the new package does something really magical. 
[23:24] <superm1> andersk, no it doesn't.  it was based on a variety of the PPA packages.  it's mostly uploaded to get the vdpau libraries and headers in the right places
[23:39] <andersk> dpkg: dependency problems prevent configuration of nvidia-glx-180:  nvidia-glx-180 depends on nvidia-180-libvdpau (= 180.18); however:   Version of nvidia-180-libvdpau on system is 180.18-0ubuntu1. 
[23:42] <andersk> Yeah, the Depends: nvidia-180-libvdpau (= #VERSION#) in control.in is wrong. 
[23:42] <andersk> It should be (>= #VERSION#) or (= ${binary:Version}) or something.