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