[00:14] <afv> hi
[00:15] <afv> RAOF, i'm having no problem with nouveau-kernel-source, this time
[00:16] <afv> but i still do have that font issue
[00:16] <afv> and by the way, did anyone tried to compile mesa today?
[00:16] <afv> i'm getting a "nv20_context.c:326: error: ‘NV20TCL_FOG_MODE_EXP_SIGNED’ undeclared (first use in this function)"
[00:17] <RAOF> Hm.  I'd guess that nouveau's been messing with the #defines again.
[00:17] <RAOF> That'd require a new libdrm, probably.
[00:17] <afv> (nv20_context.c: In function ‘nv20_init_hwctx’)
[00:17] <afv> hmm ok
[00:18] <RAOF> afv: Possibly it's time to bounce it up to nouveau's bugtracker?
[00:18] <afv> do you have a link at hand?
[00:19] <RAOF> https://bugs.freedesktop.org/
[00:19] <afv> thanks
[00:35] <afv> http://bugs.freedesktop.org/show_bug.cgi?id=25974
[00:36] <afv> i hope the information provided is enough
[00:39] <Sarvatt> afv you need an updated libdrm..
[00:41] <Sarvatt> dont have time to update it right now on edgers, will try to get it up in the morning
[00:41] <afv> so.. should i close the bug?
[00:41] <RAOF> afv: Whoops.  I meant bounce the font issue bug up to the nouveau bugtracker :/
[00:41] <afv> RAOF, ah. ok then
[00:42] <afv> marked the bug as invalid..
[00:42] <afv> lol. sorry
[00:42] <Sarvatt> can you compile your own libdrm from the debian package?
[00:43] <afv> i can try
[00:44] <Sarvatt> actually, that commit is self contained, i'll just throw it in as a patch for now and upload it real quick
[00:45] <afv> thanks
[00:46] <Sarvatt> lucid right?
[00:46] <Sarvatt> (dont want to bother with whatever you arent using because i'll just do a git update tomorrow)
[00:47] <afv> right
[00:50] <Sarvatt> uploaded
[00:51] <afv> to the ppa?
[00:51] <Sarvatt> yeah
[00:51] <afv> ok. many thanks :)
[00:52] <Sarvatt> just added http://cgit.freedesktop.org/mesa/drm/patch/?id=5963c023b84daaacb91ae0aa4cf841acff63fd1f
[00:53] <sistpoty> finallly, fixed mesa uploaded, thanks againg albert23
[00:53] <sistpoty> !
[01:19] <afv> Sarvatt, thanks. mesa compiled fine :)
[01:20] <afv> but this is what happens when trying to run compiz: http://dl.dropbox.com/u/659315/screenshots/compiz_20100110.png
[01:20] <afv> and i have a "nv40_screen_get_param:56 -  Unknown PIPE_CAP 31" when trying glxgears or compiz
[01:32] <ScottK> mesa's got further than it did before on i386 ....
[01:39] <RAOF> afv: Yeah, everyone gets that warning; it doesn't stop compiz from working for me.
[01:40] <afv> okay
[01:54] <ScottK> Congratulations albert23.  Thanks for making mesa build.
[02:33] <afv> RAOF, how many frames do you get running glxgears?
[02:36] <afv> i'm getting around 490 using gallium and around 700 without it. but.. iirc, not sure, i was getting like 6000 using nvidia blob..
[02:37] <bjsnider> what memory manager is the nouveau blob using?
[02:37] <bjsnider> i should sayd hte nouveau driver
[03:15] <RAOF> bjsnider: ttm.
[03:15] <RAOF> afv: Something in the order of 500ish, I think.  It's not a good benchmark.
[03:16] <bjsnider> it uses a pure ttm?
[03:17] <bjsnider> not a gem-ified ttm?
[03:17] <bjsnider> i didn't knpow ttm had gone into the kernel
[03:18] <RAOF> It has; I'm pretty sure it was in 2.6.32, and probably earlier.
[03:18] <RAOF> radeon has been using it for a while.
[03:18] <RAOF> Because gem doesn't really cover “my graphics card has onboard memory” :)
[03:19] <bjsnider> radeon uses a comination of gem and ttm
[03:19] <RAOF> Yes; as does nouveau.
[03:19] <ScottK> tjaalton: mesa's not there yet: https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135/+files/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:21] <bjsnider> gem doesn't understand dedicated vram, only shared?
[03:21] <ScottK> That's with the new one too.
[03:21] <ScottK> Get:5 http://ftpmaster.internal lucid/main libglu1-mesa-dev 7.7-0ubuntu3 [211kB]
[03:23] <afv> ok, thanks RAOF
[04:02] <Sarvatt> theres a dangling symlink left behind in /usr/lib now
[04:02] <Sarvatt> lrwxrwxrwx 1 root root     10 2010-01-08 23:06 /usr/lib/libGL.so -> libGL.so.1
[04:05] <Sarvatt> ah i see why
[04:05] <ScottK> Why?
[04:06] <Sarvatt> well i see a problem maybe, kdebase-workspace is using libglu1-mesa-dev, glu.pc is pointing to /usr/lib but the libglu1-mesa-dev package installs it to /usr/lib/mesa/ 
[04:07] <Sarvatt> oh bah nevermind
[04:07] <Sarvatt> libdir=/usr/lib/mesa
[04:07] <Sarvatt> working on 2 machines with different mesa versions on them because one isnt seeing the update
[04:07] <ScottK> Fun
[04:10] <ScottK> Sarvatt: If you can figure out something that doesn't look too crazy, I can upload it.
[10:03] <tjaalton> ScottK: oh bugger
[10:06] <tjaalton> I think it should be libgl1-mesa-glx that ships the GL.conf and not the xserver..
[10:16] <jcristau> that would mean the server has to depend on libgl1-mesa-glx
[10:17] <jcristau> which is better than the other way around, but still
[10:17] <tjaalton> fck
[10:17] <jcristau> this whole thing is screwed up
[10:17] <tjaalton> you don't say :)
[10:20] <tjaalton> I like how the stuff is named; /etc/ld.so.conf/GL.conf -> /etc/alternatives/gl_conf -> /usr/lib/standard-x11/ld.so.conf
[10:29] <tjaalton> somehow I don't want to do anything until tseliot shows up
[10:41] <tjaalton> s/want to/feel like/
[10:41] <tjaalton> s/do/doing/
[10:42] <jcristau> :)
[10:45] <tjaalton> just moving that conf will be messy
[10:46] <albert23> can't xserver-xorg-core and libgl1-mesa-glx both provide an alternative for GL.conf?
[10:46] <tjaalton> why?
[10:46] <albert23> to prevent the new dependency
[10:47] <tjaalton> it just lists /usr/lib/mesa, so why should they both do the same
[10:47] <jcristau> they'd provide dangling symlinks?
[10:47] <albert23> They can both setup a full alternative for GL.conf?
[10:48] <tjaalton> I think the ugliness factor has been fulfilled already :)
[10:49] <jcristau> albert23: the alternative has symlinks to libglx.so and libdri.so as slaves
[10:51] <albert23> Ah, I see
[16:19] <albert23> yay: kdebase-workspace-bin_4.3.90-0ubuntu1albert1_amd64.deb built with new mesa
[16:19] <albert23> that took 2 changes
[16:20] <albert23> First I added xserver-xorg-core as build-dependency, to get GL.conf installed (would be covered by the change suggested by Tjaalton)
[16:21] <albert23> Then I had to add export CMAKE_LIBRARY_PATH=/usr/lib/mesa in debian/rules
[16:21] <albert23> Without that, I got -- Looking for glXChooseVisual in GL - not found
[16:22] <albert23> and part of the package was not buit, resulting in a dh_install error
[16:22] <jcristau> changing every GL client to use -L/usr/lib/mesa is not a reasonable
[16:22] <jcristau> option
[16:23] <jcristau> moving libGL.so back to /usr/lib would be better imo
[16:24] <albert23> jcristau: unless there is a way to tell cmake to use pkg-config
[16:24] <albert23> pkg-config in the build showed the right -L option, but it was not used
[16:25] <jcristau> no, not unless
[16:26] <jcristau> not all GL clients use cmake, and not all GL clients are packaged by ubuntu.  that would be asking everyone to change their software because ubuntu decided to break stuff
[16:28] <jcristau> making 'gcc -lGL foo.c -o foo' not work out of the box is stupid imo
[16:46]  * ScottK agrees with jcristau
[16:52] <wind-rider> ScottK: when will it be safe to upgrade mesa? it is available as an update now
[16:53] <ScottK> wind-rider: The update doesn't fix the problem.
[16:54] <wind-rider> ScottK: I updated, and now my x-server won't start
[16:54] <wind-rider> only afterwards i saw the note that it was better not to upgrade
[16:55] <ScottK> wind-rider: I've no idea.  I'm waiting with you for a proper solution.
[16:55] <wind-rider> ok
[16:56] <wind-rider> should i file a bug?
[16:57] <sebner> wind-rider: I'm sure tseliot is aware of it
[16:57] <wind-rider> all right
[16:57]  * sebner has a working Xserver with newest mesa though. The first boot resulted in a segfaulting Xserver indeed
[16:57] <JontheEchidna> there's bug 505359 already filed anyways
[16:57] <wind-rider> sebner: so i should try to reboot?
[16:58] <sebner> wind-rider: dunno, as I said /here it didn't work the first boot and no problems since then
[16:58] <wind-rider> i'll try :)
[16:59] <wind-rider> see you later
[17:03] <wind-rider> sebner: you were right, rebooting helped, so i don't need my Live-usbstick anymore :) thx for the hint
[17:05] <sebner> wind-rider: heh, the windows-way of life 
[17:05] <wind-rider> sebner: looks like that indeed :P
[17:19] <hyperair> windows-way?
[17:21] <woozy_> "reboot until it works"
[17:28] <wind-rider> i must go
[17:28] <wind-rider> bye
[17:28] <sebner> hola hyperair :)
[17:29] <hyperair> hola sebner =)
[17:32] <sebner> hyperair: are you already on the agenda for the meeting (speaking about your applications)?
[17:32] <hyperair> not yet
[17:33] <hyperair> i'm still thinking which meeting i should choose
[17:33] <hyperair> one of them will occur at 3am on a friday morning
[17:33] <sebner> hyperair: heh, so you are ready for the weekend then :P
[17:33] <hyperair> that'll be the meeting after the next
[17:33] <hyperair> sebner: so i still have time to think which one i feel like going for =p
[17:34] <hyperair> sebner: and also to reap more endorsements
[17:34] <hyperair> =D
[17:34] <sebner> hyperair: heh, you should mention your interest in non cli packages/sponsoring too though
[17:34] <hyperair> sebner: didn't i?
[17:35] <sebner> hyperair: ah right, :) just not good to only have on area standing above all
[17:36] <jcristau> really?
[17:37] <sebner> jcristau: depends but in most cases not
[17:37] <sebner> hyperair: speaking of, where is banshee 1.5.2 ;P
[17:38] <sebner> hyperair: stopped by transition I suppose?
[17:38] <hyperair> sebner: yes, that it is.
[17:38] <sebner> kk
[17:39] <hyperair> sebner: also, i think you focused too much on the bulleted list of PPAs.
[17:39] <ripps> Does anybody have any clue how the xf86-input-wacom driver for lucid is coming?
[17:39] <jcristau> by train
[17:40] <sebner> hyperair: yeah right
[17:40] <sebner> hyperair: It's also my personal experience with you though :)
[17:40] <hyperair> =p
[17:40] <hyperair> right
[17:44] <ripps> I believe the new udev xf86-input-wacom driver was released in debian just the other day. So how long until it gets in Ubuntu?
[18:05] <ripps> Okay, I just pulled the xf86-input-wacom source package from debian and built it with pbuilder. It seems to fix my immediate problems I had with my tablet, unfortunetly, it seem the xsetwacom utility doesn't really work. The names it lists for the stylus/eraser/cursor devices don't actually work when you try to set them.
[18:07] <ripps> Oh, okay, I figured it out. I has to have the quotes in the actual name sting. Kinda dumb
[18:07] <jcristau> ripps: blame udev :)
[18:08] <ripps> Can't it just remove the quotes? What do I have to have the devices called '"Wacom Graphire3"'? Notice the two sets of quotation?
[18:12] <jcristau> because X gets the device name from udev, and there are quotes
[18:14] <ripps> hmm... it seems that KeepShape doesn't work anymore, good thing I kept an old script with some manual BottomX BottomY to accomplish the same thing with my screen
[18:24] <ripps> Huh, TPCButton value is inverted. It's on when I set it to off... now that's a bug
[18:25] <ripps> Where do I file bugs? or should I wait until it gets into Ubuntu?
[18:45] <wind-rider> ripps: if you know the package, run: ubuntu-bug <packagename>
[18:45] <wind-rider> ripps: else, go to bugs.launchpad.net
[21:50] <al> https://help.ubuntu.com/community/RadeonDriver#Tweaking%20The%20Driver could use a review maybe
[21:51] <al> i just edited to reflect the default AccelMode change from XAA to EXA, which had a severe negative performance impact on my R350 card
[21:51] <al> don't know about the other options though
[23:01] <tjaalton> maybe a time to fix the mesa mess, if only my DNS worked
[23:33] <tjaalton> still broken, I'll leave mesa for tomorrow..
[23:51] <bjsnider> there is no fix is there?