[00:22] these weekly binutils really are killer, now linux-tools-2.6.35-4 needs a rebuild and it was just uploaded [00:22] why do people keep linking dynamically against libbfd? [00:28] thats a really good question [01:54] Stupid X. Build faster! [02:04] RAOF: autotools is a big part of the compile time. [02:05] imake was much faster indeed. Unfortunately, no one maintained/improved it for aeons, and the number of people who could deal with imake had gone down to a few handful of people over the years. [02:06] RAOF: we also went too far with modularization, compounding the autotools slowness; I gather that's getting fixed soon. [02:58] well I think I learned my lesson about not trying to debug something that happens in a browser [02:58] * Sarvatt squints at the 60 page backtrace [02:58] Does Chromium play the turing-complete-type-system game? [03:51] ahhhhh lovely, everything i've been printing for hours can just be printed to a log with an option :) [04:19] ... chromium bundles mesa [04:30] Woo! === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo [06:11] oh nice, module-assistant in debian actually works === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo === Bernardo is now known as Bernardo|Away [06:49] It doesn't work in Ubuntu? I guess we don't test it as much. === Bernardo|Away is now known as Bernardo [06:55] in ubuntu we use dkms which is a vastly superior system, don't we? [06:56] someone should port over dkms to debian and get rid of m-a === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo === Bernardo is now known as Bernardo|Away === Bernardo|Away is now known as Bernardo [07:09] Sarvatt: When do we want to move on to Xserver 1.9? How's it doing in xorg-edgers? [07:12] yeah sysprof is just using m-a and i wanted to see if i get better info with the module [07:12] since perf is busted because of binutils [07:12] You're profiling chromium? [07:12] xserver 1.9 is still basically unusable [07:13] Good, good. [07:13] i built it all this morning [07:13] need to figure out what to do about the bgnr patch [07:13] Gah. I need to kill mutter's grab of the key with a sword. [07:14] the one airlied sent to the lists breaks the video abi, need to back that out and refresh it [07:14] gdm and plymouth hate it if your server doesn't support -nr, starts you on :1 and enter sends sigquit again like it did in lucid [07:14] Yay! [07:15] oh and you cant boot it at all if you have plymouth going, forgot that part [07:15] Bonus güngefactor. [07:15] have to press escape to ditch the splash or ditch splash :) [07:16] the nouveau patch needs refreshing, they moved all of that into another file now but thats easy [07:18] intel could use updating but i haven't tried it yet since i havent done a 3 branch merge yet and dont want to mess it up :) [07:18] oh yah and mesa [07:18] 7.8.2 [07:18] i havent built mesa since the osmesa change, not sure if it needs any changes [07:21] i dont know if we can do the bgnr without breaking the abi.. :( [07:23] with 1.7 and 1.8 you could build with the bgnr patches applied to the ddx but not the server, but things fail on 1.9 [07:28] got sysprof and module-assistant here if anyone ever looks for them - https://edge.launchpad.net/~sarvatt/+archive/ppa [07:56] never seen that before, a -refdbg package? This package contains the shared library built with --disable-visibility so that it can be used with refdbg, a GObject refcount debugger. [08:32] sarvatt, why does alpha channel break so often? [08:33] because making things faster involves screwing around with that :) [08:35] whats screwed up for you now? [08:35] lemme guess, chromium tabs? [08:35] websites [08:35] games in wine [08:36] black or white splotches where transparency is expected, [08:36] meh mutter won't run with nouveau. [08:36] * hyperair goes back to the binary blob [08:37] chromim tabs are transparent? [08:37] they draw an animation thats transparent yeah [08:38] and end up disappearing altogether for me right now [08:38] until i close enough to make the favicons on them show back up [08:38] can't tell. they look normal. [08:38] and system-wide rgba looks fine [08:38] open 20 tabs? [08:39] gray tabs. looks normal. [08:39] what gpu? [08:39] blue in classic [08:39] 945gm [08:39] hmm [08:39] is it 945gm or gma950? [08:39] when did you restart last? [08:39] yep [08:40] 10 minutes ago [08:40] * hyperair is noticing xxvi suddenly being very stable. [08:41] i heard dri2 swapbuffers landed in the stack [08:41] fullscreen tearing still present <___< [08:41] intel unstable where? [08:41] 2.11 does suck :) [08:42] LLStarks: do you have any other changes in your gtkrc besides rgba enabled? [08:42] what theme are you using? [08:42] nope [08:42] ambiance [08:42] same, bah [08:43] but this all started when i decided to do my weekly edgers test [08:44] gnome-shell = extreme lagginess on nvidia [08:44] kristian needs push for more 915 gallium [08:45] oh yeah, how is gallium3d 965 going? [08:45] I hear that fails to wedge the GPU. Poor showing! [08:45] hyperair: hasnt been updated in months i dont think [08:45] =\ [08:45] hyperair: 965 status: GPU wedge as soon as something touches it. [08:45] RAOF: lol. that sucks =\ [08:45] Eh. [08:46] 915 gallium is terrible right now. zero compositing support and gnome-panel can't even render properly. [08:46] LLStarks: You have a high bar for terrible :) [08:46] eh? [08:46] * RAOF doesn't care _that_ much about OpenGL 2.0 on my GM45, really. [08:46] odd because it works fine here [08:47] OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20100330 DEVELOPMENT x86/MMX/SSE2 [08:47] OpenGL version string: 2.0 Mesa 7.9-devel [08:47] OpenGL shading language version string: 1.20 [08:47] LLStarks: Well, I mean it doesn't totally freeze your GPU. If mere rendering errors are terrible, how do you describe i965 gallium? :) [08:47] 965 gallium = 915 gallium? [08:47] RAOF: atrocious. [08:47] LLStarks: you activated stuff pretty much guaranteed to crash you and you complain about crashing? :) [08:48] i test edgers once a week. [08:48] * hyperair tests edgers every day [08:48] LLStarks: No; there are two intel gallium DRI drivers (and more classic drivers) - i915 and i965 [08:48] that opengl 2.0 stub stuff is sketchy [08:48] sometimes its stable enough for wide use. [08:48] edgers is my stable fallback when my newer stuff doesn't work.. lol [08:48] what's wrong with fragment shader and occlusion query? [08:49] the gpu's dont support them [08:49] xxvi and mesa (dri-gem) seem pretty stable at the moment [08:49] fragment shaders crash me in cairo-gl [08:49] if you enable it things will try to use it instead of what they do support and screw things up (wine especially) [08:49] by the way, i heard some mention about a lcdfilter patch the other day. what's that? [08:50] hyperair: booted any other distro in the past few years? [08:50] Sarvatt: archlinux. [08:50] Sarvatt: is it font rendering? [08:50] yeah [08:50] i remember installing a cairo-ubuntu thing on archlinux [08:50] from AUR [08:51] after getting a crapload of -ubuntu packages for font rendering, i gave up and came back to ubuntu [08:51] yep that was it, whole series of foo-ubuntu stuff for fonts [08:51] i recall timo and anholt saying the stubs work on i945 [08:51] especially since i was on my p4 which took half a day to compile a kernel, let alone openoffice.org [08:51] and firefox >_> [08:51] driconf says so as well [08:52] its lying because you enabled the option to tell it to lie, if wine sees your card has GLSL support it's going to use that code path instead of what the card actually supports, it doesn't really support everything for those extensions [08:52] ah [08:53] at any rate, what are the benefits of transitioning intel to gallium? [08:53] i keep forgetting [08:53] none? they aren't doing it [08:53] make phoronix happy? [08:53] lol [08:53] tabloid. [08:53] isn't gallium3d supposed to have better performance or something? [08:53] at least, it seemed like radeon was doing better with gallium3d [08:53] phoronix is never happy. [08:54] on ati where they dont already have GLSL support in classic and they got it for free switching over [08:54] thats not the case on intel.. [08:55] get vaapi and windows-equivalent 3d performance on 915 and i'll never give this laptop to my sister when i replace it. [08:56] yeah thats pretty much guaranteed not ever going to happen :) [08:56] the vaapi part [08:56] okay, then reenable xvmc [08:57] option "XvMC" "True" in xorg.conf [08:57] thats been working for over a year [08:57] ah. nice. [08:58] its just not enabled by default on <965, man intel talks about it [08:59] oh its disabled on 965 too now it looks like, it was enabled there and not on these for awhile [08:59] can somebody explain the difference between i915, i945gm, and gma950? ddx/dri, chipset, and market name respectively? [09:01] 915-945 are generation 3 gpu's, theres just no point forking it off to a new kernel driver name for the newer stuff when they had 915 already [09:05] bed. [12:16] RAOF, about? just wondering where we were at with the i8xx patches, last i looked they were still changing have they settled now [13:35] hyperair, there are a couple of outstanding mutter bugs in the nvidia blob that the gnome guys are pushing them to fix. that's why the nvidia issues on gnome-shell exist [14:40] bjsnider: the gnome guys are pushing who to fix? [14:41] pushing nvidia [14:42] huh, do they actually budge? [14:42] sure. it's on their list [14:42] =O [17:04] Sarvatt: can u check https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/587710 ? ive posted there a lot crashes already. at least one should give already info whats wrong.. ive already have 1 more. when ill have 4 more ill upload them too. should i remove ppa:bugsbugsbugs or continue with its debugs? [17:04] and debug without bugsbugsbugs ? [19:32] The version of fglrx in the ubuntu-x-swat/x-updates maveric repo fails here with [atiddxSetup] X version mismatch - detected X.org 7.1.1.901, required X.org 7.5.1.0. Anything i can do? [22:42] ion: nope, its harddcoded to only work with xserver 1.7 [22:42] ion: they did it really crappily too, it actually works with xserver 1.8 but if the server version is >1.7.x then it refuses to load [22:43] i'm in the middle of updating it to 10.6 too, but it still doesnt work with the newer xserver [22:43] if you change the xserver version to 1.7 in configure.ac and rebuild everything it'll work, lol [22:47] Does anybody here know why libvdpau [amd64] depend on ia32-libs. libvdpau is having problems building because it can't get ia32-libs, because ia32-libs isn't included in main (and from I've heard, is unlikely to get inclusion) [22:56] hmm, i dont think it should, only lib32vdpau should? [22:56] what version ripps? [22:56] oh guess i need to look at amd64, duh :) [22:57] maverick has libvdpau 0.4-5 [22:57] go figure packages.ubuntu.com doesnt show maverick now [22:58] ahh they didnt make a lib32vdpau-dev [23:01] ion: they'll support xserver 1.8 as soon as we move to 1.9, dont worry :) [23:02] ati finally fixed 2D performance with 10.6 [23:03] Sarvatt: so it seems :) [23:04] almost done packaging it [23:04] now people are in #kubuntu asking how to install the sources :) [23:04] Sarvatt: w00t [23:04] just writing up the changelog, darn pdf [23:05] :P [23:06] Sarvatt: the packages will be in your PPA ?? [23:06] ubuntu-x-swat/x-updates ppa [23:06] ah ok :) [23:10] lol chromium took 8 hours to build and failed to link webkit because 1gb ram + 2gb swap isnt enough [23:11] uploading the monster fglrx-installer-8.741 now [23:12] Sarvatt: wow... [23:12] if anyone uses it i'd appreciate feedback on if it works, didnt find out the 8.731 was broken for a month :) [23:13] Sarvatt: do you think vdpau will build without ia32-libs? [23:14] im trying it out now... its fetching the deps [23:17] they shoved the 32 bit libvdpau dev stuff in libvdpau-dev, it wont work [23:18] yaeh [23:18] build failed :P [23:18] want the logs? xD [23:18] works in debian because they dont have libvdpau in main i dont think :( [23:19] Sarvatt: works in debian because ia32-libs is in main [23:19] oh! :) [23:19] its in universe here :P [23:20] Sarvatt: so how do we fix this> [23:20] we cant do a MIR.. ia32 wont get into main :D [23:21] can I see your build log? [23:22] sure [23:22] Sarvatt: libvdpau_0.4-5_amd64.build [23:22] i cant see how to fix it off the top of my head outside of just dropping the 32 bit portion [23:24] Sarvatt: http://pastebin.com/tALj4g76 [23:24] hmm maybe the i386 build can just install the wrapper [23:24] and ia32-libs can pull the i386 package in instead [23:26] Sarvatt: so that it provides the required libs> [23:26] could just drop the whole lib32vdpau completely for now :) [23:27] BlackZ: \o [23:29] Sarvatt: hehe [23:29] Sarvatt: want me to drop it and post debdiff or are you on it? [23:30] BlackZ: could just drop the whole lib32vdpau completely for now :) [23:31] yes, that could be a solution [23:31] hmm this does need to be built differently for the wrapper and .pc to be correct, stuffing it in ia32-libs wont work :( [23:31] hey Sarvatt [23:32] shadeslayer: I'm looking at it right now [23:32] BlackZ: ok.. [23:32] im going to sleep now,its 4 AM :P [23:33] shadeslayer: does it FTBFS only on amd64? [23:33] BlackZ: yes [23:33] well, have you seen http://launchpadlibrarian.net/49013154/buildlog_ubuntu-maverick-amd64.libvdpau_0.4-4_MANUALDEPWAIT.txt.gz ? [23:33] not exactly ftbfs... more of dep wait ;) [23:33] looks like fixing the vdpau wrapper to work with multiple VDPAU_MODULEDIR should be possible though [23:33] also, is there a bug filed for that? [23:34] nope [23:34] ripps: just told us about it :) [23:35] I noticed it when my amd64 mplayer-build packages failed in one of my ppas [23:36] BlackZ: anyways im off... and btw the earlier package we talked about? ( qtcreator ) it was a problem with qmake,it was linked against qmake-qt3 whereas it should have been qmake-qt4 :P [23:37] shadeslayer: I'm happy you were able to solve the problem :) [23:38] Sarvatt: btw, I uploaded my wacom-source package to revu. I wanted to know if you thought it was good enough for ubuntu inclusion [23:38] ripps: why don't you include it in debian too? [23:39] BlackZ: I couldn't find any bug reports for it in debian, so I wasn't certain if they even had the bug [23:40] I uploaded the same package to debian-mentors, so If somebody wants it, it's there. [23:42] yeah dropping lib32vdpau for now seems to be the way to go, we didnt even ship it before [23:54] Sarvatt: I noticed 'lib32vdpau1' is not in our repository [23:54] it should be synced from debian [23:55] its built by the libvdpau source package [23:56] which is in depwait on amd64 [23:57] hmmm .. Sarvatt: it build here [23:57] s/build/builds [23:57] I have amd64 and I have no problems [23:57] because you have ia32-libs installed [23:58] hm Sarvatt maybe you're right [23:58] I should try without it [23:59] ripps: however, could you file a bug? [23:59] https://edge.launchpad.net/ubuntu/+source/libvdpau/0.4-5/+build/1790677 [23:59] Sarvatt: yeah, I seen that