/srv/irclogs.ubuntu.com/2009/01/07/#ubuntu-x.txt

brycewhoohoo  [ANNOUNCE] xf86-video-ati 6.10.000:20
seb128hey there13:09
seb128we 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:10
tjaaltonwhat happened then?13:17
tjaaltonI mean what problems came up?13:17
seb128tjaalton: sort of bug flood about users having incorrect values being used13:19
seb128their font not looking right, that sort of things13:19
seb128ie, too many case where xorg doesn't get it right13:19
jcristau(or where monitors lie)13:22
tjaaltonwas just going to say that..13:22
seb128bug #118745)13:24
ubottuLaunchpad bug 118745 in xorg-server "Font sizes in Gutsy are affected by bad X.org DPI detection" [Medium,Fix released] https://launchpad.net/bugs/11874513:24
seb128that's the bug we got back then13:24
seb128there 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 wrong13:25
seb128do you have any opinion on the topic?13:25
seb128I guess we could just try for a while in jaunty and see the users reactions13:25
tjaaltonwhere is it forced?13:26
jcristautjaalton: gdm starts X with -dpi 9613:26
jcristauiirc13:26
tjaaltongrep doesn't show any results here, on hardy13:27
tjaaltonah, libgnome13:27
jcristauoh.13:28
tjaalton/desktop/gnome/font_rendering/dpi       96.013:28
tjaaltonseb128: I'd be ok with it, but maybe ask bryce too :)13:30
seb128tjaalton: right, libgnome, see the bug I listed before, we decided to change gnome-settings-daemon to set it to 96 by default13:33
seb128or rather to change the gconf key used by gnome-settings-daemon13:33
tjaaltonright13:35
=== seb128_ is now known as seb128
Ngseb128: 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:50
seb128Ng: gdm doesn't use gconf so you get the xorg dpi used there16:52
* mvo almost wanted to say something about glasses but he does not16:53
Ngseb128: ah, damn16:59
Ngmvo: I have perfect vision! there literally aren't enough pixels in the fonts to be able to read them16:59
Ngit makes the failsafe X thing impossible to use too, which is a shame since I regularly break my X config on that machine ;)16:59
mvohaha17:02
superm1tseliot, 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 it17:25
superm1also is there any particular reason that the modaliases is arch dependent?17:26
tseliotsuperm1: feel free to update it. I would like to have a look at the new source if you don't mind.17:30
tseliotsuperm1: 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.patch17:30
superm1tseliot, 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
superm1yeah that's the one i was grabbing17:30
superm1i 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 upload17:31
tseliotsuperm1: as regards modaliases, they have to be arch-specific17:31
superm1tseliot, why is that?17:31
tseliototherwise they will break a few things (as cjwatson reported)17:32
superm1hum interesting. is there a bug on this?17:32
superm1or just side chatter that was reported in irc at some point?17:32
tseliotlet me check17:32
jcristauso they're not available on !x86, i guess?17:32
superm1oh 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:33
tseliotsuperm1: maybe I confused it with nvidia-common. But anyway it makes sense to have them arch specific since they really support only x86 x86_6417:35
superm1hmm.  ok..17:36
tseliotsuperm1: let me know when the package is ready17:36
superm1i'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 it17:36
tseliotok17:45
superm1tseliot, still there?19:00
superm1tseliot, here's the diff i'm planning to upload if you'd like to take a look: http://pastebin.com/f6e8ce16f19:03
superm1main 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:03
superm1but otherwise this diff works to build myth against vdpau19:04
superm1in tseliot's absence, can I get another set of eyes on those packaging changes before I upload?  bryce or tjaalton ?19:08
bryce_superm1: hmm19:18
bryce_superm1: you could more explicitly reference the nvidia_supported change in the changelog; it's not obvious which changelog entry belongs to that change19:19
superm1bryce, ok will do.  19:19
superm1bryce, i'm particularly referring to the vdpau packaging changes - those package names in the control file seem appropriate?19:19
bryce_otherwise looks like it's mostly doing a s/180.11/180.18/g, which all looks fine19:20
bryce_superm1: I don't have a problem with them, but I'd defer to others opinions19:20
tseliotsuperm1: here I am19:21
superm1tseliot, hi19:21
bryce_superm1: libvdpau-180 could be another alternative for naming, however I like how it puts this into the nvidia namespace19:22
superm1bryce, 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 it19:23
* tseliot has a look at the diff19:23
bryce_superm1: ah true19:23
tseliotsuperm1: nvidia-180-libvdpau-dev can't be arch = all as it depends on nvidia-180-libvdpau (which is i386 or amd64)19:25
superm1is that against debian policy though?19:26
superm1usually -dev packages with headers only are arch all19:26
tseliotsuperm1: I was worried about having broken dependencies on architectures other than i386 and amd6419:27
superm1bryce, what do you think on that?19:27
bryce-nvidia is only relevant on i386 and amd64 anyway, right?19:30
brycebut yeah I thought most -dev packages were arch all, since they're usually just headers and stuff19:30
tseliotsuperm1: the diff looks good but keep in mind that I'm tired and so are my eyes ;)19:35
superm1well if anything when an archive admin NEW's this, they'll make the final call on it19:35
tseliotright19:35
superm1tseliot, okay well if anything comes up, i'll be glad to help get another upload to take care of it. thanks!19:36
tseliotsuperm1: thank you ;)19:36
* tseliot > off for a bit19:43
superm1cya19:45
bryceanyone else seeing PrintScreen breakage?  (305695)19:59
superm1bug 30569520:03
ubottuLaunchpad bug 305695 in metacity "Jaunty doesnt allow screenshots getting "No command 33 has been defined" error with printscreen " [High,Triaged] https://launchpad.net/bugs/30569520:03
superm1yeah i saw that yesterday and filed a duplicate20:04
crevettebryce this is fixed by latest metacity20:04
crevette2.25.89 afaik20:04
crevettes/afaik/IIRC/ :)20:04
brycecrevette: interesting; where did you learn that?20:06
crevettehttps://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/31252220:06
crevetteI packaged it20:06
ubottuError: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/312522/+text)20:06
crevettewaiting to be sponsored20:06
bryceahh ok20:06
crevetteand in my ppa if you want20:06
bryceok20:08
brycelink?  https://edge.launchpad.net/~crevette/+archive doesn't work20:09
crevettebut https://edge.launchpad.net/~bmillemathias/+archive/ will :)20:09
crevetteI should change my nick20:10
crevettedon't pick all my updates20:10
brycemm, maybe I should hold off updating this system since I'm using it for day to day testing20:11
crevetteah :)20:11
crevettesure20:11
brycebut thanks, I'll add all this info to the bug for other testers (seems we have plenty)20:11
crevetteperhaps I should update the changelog to include one bug and duplicate all others ?20:12
bryceno, should leave the bugs separate, unless they literally are exactly the same bug20:15
brycesuperm1: hey do you know anything about color depth issues with the new -nvidia?22:34
superm1bryce, no i haven't heard anything of the sort23:09
superm1bryce, encountering them?23:09
brycesuperm1: rickspencer is, although he's fiddling with nvidia-xconfig to correct it (he's ran into some configuration troubles)23:10
superm1on jaunty?23:10
bryceyep23:11
bryceI'll help him file a bug if he's still having problems tomorrow.23:12
superm1is ignoreabi still necessary for 180 drivers with the upload i put in?  I was only testing it with intrepid (no ignoreabi necessary still)23:13
brycedunno23:14
superm1ill take a look tomorrow and see23:14
bryceok23:14
anderskI’ve been running 180.18 for a while, and it still needs IgnoreABI, unless the new package does something really magical. 23:22
superm1andersk, 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 places23:24
anderskdpkg: 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:39
anderskYeah, the Depends: nvidia-180-libvdpau (= #VERSION#) in control.in is wrong. 23:42
anderskIt should be (>= #VERSION#) or (= ${binary:Version}) or something. 23:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!