=== asac_ is now known as asac [00:34] asac, fta; I just tested it with the new mesa and an intel card. It works amazingly well [00:34] I am very impressed [00:52] new mesa? which one? newer than karmic? [00:53] yes [00:53] fta: mesa 7.6 in xorg edgers [00:53] or I guess you can compile yourself if you want to [00:53] basically mesa 7.6 [00:54] its really nice [01:10] fta: what card do you have and do you have a 64bit system? [01:10] I do [01:10] nvidia [01:10] BUGabundo: have you tried o3d? [01:11] do you use nvidia drivers? [01:11] no [01:11] yes [01:12] EruditeHermit: the plugin crashed my browser on first try ;) [01:12] first it complained that "text is not yet supported on linux" [01:12] yeah [01:12] then it somewhat worked and when i hit back it crashed [01:12] what card? [01:12] 965 [01:12] and 64bit? [01:12] oh [01:12] no [01:12] 32 [01:12] it worked here [01:12] pretty well [01:13] on intel [01:13] well maybe it was just the example i used ;) [01:13] i sued it in ffox 3.5 [01:13] used ;) [01:13] same [01:13] don't do the tropics demo [01:13] that is intense [01:13] try a simpler demo [01:13] tropics demo didn't crash for me but it didn't render everything [01:14] EruditeHermit: anyway. after our talk i really got the ati thing work with compiz ;) - at last [01:14] so i feel a bit more happy ;) [01:15] nice [01:15] how did you do it? [01:15] xorg.conf had some stuff ... removed it completely [01:15] and disbled composition_manager in metacity ;) [01:15] obvious now, but far from obvious for me ;) [01:16] nobody really complained about my xorg.conf before ;) [01:16] ehehe [01:16] you should have asked [01:16] asac: next thing I was going to ask you to do is to give me Xorg.0.log [01:16] I would have told you to have a blank xorg.conf on JJ [01:16] so i am testing ping pong [01:16] and that might have given me clues that your xorg.conf was messed up [01:17] click here ... nothing happens ;) [01:17] hmm [01:17] really? [01:17] I tried it on the same card [01:17] and it worked [01:18] I think its problems with mesa btw [01:18] not with o3d itself [01:18] prince IO works [01:18] hmm ... now it says please wait ... loading ... [01:18] oh the files are large [01:18] the downloads are large [01:19] i can wait a bit, but i think its broken [01:21] hmm [01:21] well [01:21] i am loading the samples.zip now [01:21] when mesa 7.6 is more stable, then we'll know where the problems are [01:21] i am running that [01:21] the edgers stuff [01:22] yeah I know [01:22] but as I said [01:22] its not stable yet [01:22] so I'm not sure if its mesa that is causing crashes or o3d [01:23] it doesnt crash [01:23] it just doesnt work ;) [01:23] at lesat not perfectly for the samles [01:23] the odd thing is that in the samples.zip nothing works [01:23] though the other demos on the site started at least [01:23] the ping pong demo worked flawlessly here [01:23] as did the box [01:24] and the simple demos [01:24] the picking demo [01:24] asac: what timezone are you in? [01:24] +2 [01:24] UTC+2 [01:24] wow its late there [01:24] so i will drop out now ;) [01:24] 2:24 am ;) [01:25] asac: if you want we can debug it tomorrow [01:25] but we are making progress [01:26] well. i might not really have time for that in the next few days. [01:26] =) [01:26] ok [01:26] 1:30 am here [01:26] need to be up at 7:30 for work [01:26] lol [01:26] EruditeHermit: so what libs does it depend on? v8, what else? [01:26] rsync isn't even on 20 % :( [01:27] BUGabundo: did you try o3d with amd64? [01:27] i mean google libs not in the archive ;) [01:27] asac: libCg [01:27] what is that [01:27] EruditeHermit: no [01:27] asac: nvidia shader [01:27] shading library [01:27] EruditeHermit: is that used only by o3d or by something else as well? [01:27] its used by a lot of proprietary game engines [01:27] its used by nvidia to make video drivers [01:28] but its completely abi/api unstable? [01:28] they convert GLSL to nvidia Cg [01:28] or why isnt that in the archive? [01:28] its proprietary [01:28] its proprietary even? ouch [01:28] it IS in the archive [01:28] sort of [01:28] its like flash [01:28] there is a package that downloads and installs it in the archive [01:28] then why cant we use that lib instead of the one that is shipped in the o3d package now? [01:28] hmm [01:28] you can [01:28] just add a dependency [01:29] so that cant even be shipped in ppas to be honest afaik [01:29] yeah I was wondering why you packaged it like that [01:29] is that at least freely redistributable? [01:29] I mean its nice that you did [01:29] or not even that? [01:29] it is freely redistributable [01:29] I think [01:29] but we'd have to check [01:29] nah ... i didnt. and we have to change that i guess [01:29] i just didnt know its non-free [01:29] depends on whether its distribuable and mirrorable [01:30] so i think if it could stay in multiverse it might be ok. but _might_ ;) [01:30] well [01:30] this package is in there [01:30] nvidia-cg-toolkit [01:30] but does that ship the .so? [01:30] cant we use that so directly? [01:31] I think you can redistribute it [01:31] but I don't know if Ubuntu allows that [01:32] well depends on the license of that toolkit [01:32] i will put it on my list. but even if its suitable for multiverse it would require an exception [01:32] so better depend on the cg-toolkit [01:32] EruditeHermit: so is the so needed during build time? [01:32] or do you have a glue or something? [01:33] its needed to build [01:33] which makes it even more complicated :( [01:35] fta said he knew someone in google working on this [01:35] you should ask them to use GLSL shaders [01:35] they support HLSL which is microsoft [01:35] DirectX 10 [01:35] and Nvidia Cg [01:35] they should support GLSL too [01:35] and make it open source able [01:38] GLSL shaders are free software? [01:39] yeah [01:39] its part of the OpenGL spec [01:39] which lib is that? [01:39] GL is a shading language [01:40] the drivers support it [01:40] mesa in the case of open source [01:40] asac: type glxinfo into a terminal [01:40] you'll see it says something like OpenGL 2.1 GLSL 1.20 [01:41] nope ;) [01:41] (on ati) ;) [01:41] oh [01:41] do it with the intel card [01:41] or try this on the radeon [01:41] i believe you [01:41] just want to understand [01:42] LIBGL_ALWAYS_SOFTWARE=true glxinfo [01:42] still nothing ;) [01:42] anyway. thats not the point [01:43] so libCg basically is a middleware so apps dont need to speak GLSL, etc. on their own, right? [01:43] well its another shading language [01:43] * BUGabundo Ta na hora da Caminha, bamos la deitar.... \n bed time. cu tomorrow [01:43] technically it doesn't need GLSL at all [01:43] EruditeHermit: yes. but libCg maps it to GLSL and other [01:44] or is that wrong? [01:44] but in the nvidia drivers what they did was map all GLSL calls to Cg [01:44] hmm [01:44] imagine that they already wrote a windows driver that used Cg [01:44] then for Linux, they just translated GLSL calls to Cg [01:44] so that they supported GLSL on Linux [01:44] thats for their drivers [01:45] but you can program directly in Cg [01:45] if you wanted [01:45] and why did o3d go for libCg ... because its platform independent? [01:45] no [01:45] well thats one reason [01:45] but then so is GLSL [01:45] GLSL is just a spec [01:45] that every vendor implements [01:45] but its opengl [01:45] yeah [01:46] its opengl [01:46] and on windows drivers are better at directx isnt that the case? [01:46] they probably chose Cg because its more advanced [01:46] on windows most drivers do both directx and opengl [01:46] infact most windows drivers have pretty good opengl support [01:46] yes. but from what i understood opengl support is usually inferior (still) [01:46] better than linux open source drivers by miles [01:46] heh [01:46] thats not hard i guess ;) [01:47] well I think they do everything that is possible [01:47] ATI and Nvidia both support OpenGL on all their cards [01:47] to whatever level the hardware supports [01:47] so their newest cards support OpenGL 3.0 [01:47] older cards support 2.1 [01:47] fully [01:48] I didn [01:48] I didn't understand why they chose HLSL and Cg over GLSL [01:49] if they wanted an open source tool [01:49] i think they dont care about distributability and opensource [01:49] so they solely decide based on technical arguments [01:49] which is wrong approach - at least it already blocks most apps they develop from entering the archive that they dont think about it. [01:50] wrong approach (from distro point of view) [01:50] hmm [01:51] yes you can distribute nvidia cg on Linux [01:51] the library [01:51] you just can't change the binary in any way [01:51] https://bugs.launchpad.net/debian/+source/nvidia-cg-toolkit/+bug/284750 [01:51] why is the binary then not shipped in the nvidia-cg- package [01:51] Ubuntu bug 284750 in nvidia-cg-toolkit "License change, time to package it up" [Undecided,Confirmed] [01:51] yeah [01:52] then you can depend on it [01:52] and build stuff [01:52] but its still not ideal [01:52] right. but its hard to attract folks to care for stuff in multiverse [01:53] and its always calling for trouble [01:53] talk to your contact at google [01:54] maybe they will bend [01:54] something breaks -> you are lost [01:54] i dont think so ;) [01:54] they might [01:54] they can just add the option [01:54] question is if they still want to put resources into o3d [01:54] I think they do [01:54] I was using canvas3d until now [01:55] canvas3d is mozillas version [01:55] it uses OpenGL ES [01:55] is that any better? [01:55] the license is free [01:56] http://hg.mozilla.org/users/vladimir_mozilla.com/canvas3d/ [01:56] the plugin itself is ok, but the javascript library it uses is slower [01:56] yeah [01:56] yeah. but thats tracemonkey now and will improve [01:56] it was slow to the point where I could not use it [01:56] v8 doesnt even work on amd64 [01:56] tracemonkey doesn't [01:56] either [01:56] it doesnt? [01:57] nope [01:57] at least it claims to do jit compiling ;) [01:57] on 32bit yes [01:57] atleast it doesn't for firefox 3.5 [01:57] why do you think that? [01:57] they may have started porting it over [01:57] i havent heard of that [01:57] i talked to vlad [01:57] could be that i have overheard that [01:58] the one whos blog you read [01:58] whose* [01:58] I talked to guys at mozilla and they turned it off for 64bit [01:59] turned it off ... i have the switch turned on here at least [01:59] so either the switch doesnt do anything or its on [02:00] anyway. what matters is that it works ;) [02:01] personally i have things to critize about libmozjs as well ;) [02:01] so v8 or mozjs isnt that a big difference. just that you cant run v8 on 64-bit yet properly [02:06] both are currently not suitable for main exposure ;) but i think mozjs will be first if any that can be linked against without feeling dirty [02:08] http://github.com/sandys/tracemonkey-64bit/tree/master [02:11] ok [02:11] but thats recent [02:11] july 8 [02:11] yes [02:16] ok off for real now [02:16] ok [02:16] gngight [06:22] fta - no flock for jaunty in your ppa? :/ [08:46] hi [09:01] hi asac [09:02] hi micahg [09:02] we had someone submit a rant report in firefox-3.5 [09:02] bug 399517 [09:02] Launchpad bug 399517 in firefox-3.5 "Usability: Rename Shiretoko to firefox 3.5" [Undecided,New] https://launchpad.net/bugs/399517 === ripps_ is now known as ripps [09:35] asac: ^^^ [09:36] also, can we move bugs to the firefox-3.6 package yet? [09:56] micahg: no. we dont have any 3.6 package. why? [09:56] are there bugs reported that are only in 3.6? === nareshov is now known as naresh [10:39] asac, when ended up of that o3d discussion with EruditeHermit? [10:40] i read we need mesa 7.6, but what for? intel? ati? [10:42] fta: the discussion ended in the situation where I found out that libCg.so isnt even free software ;) [10:42] it's not? [10:42] fta: he said you are talking with google about moving that to GLSL ? [10:42] eh? [10:42] am i? [10:43] fta: no its a proprietary binary from nvidia ... which might now be suitable for multiverse (previously it wasnt as the nvidia-cg- package is just an installer package) [10:44] bug 284750 [10:44] Launchpad bug 284750 in nvidia-cg-toolkit "License change, time to package it up" [Undecided,Confirmed] https://launchpad.net/bugs/284750 [10:44] http://developer.nvidia.com/object/cg_toolkit.html [10:45] damn, i thought i was dropping all binaries [10:45] fta: we should definitly raise this with the o3d authors. [10:45] if we are not even able to put it in the archive, then all we can do is provude a o3d-plugin-installer package that also downloads the manually built .so files etc. [10:45] messy for sure [10:47] i get the feeling that whatever google does, they do it in a way where they only have "we distribute on our own like on windows" in mind;) [10:49] i think there's no evil plan there, it's just that they don't care about all that, they want to ship something that just works [11:06] fta: right. i didnt say evilplan its just that they only think about distributing on their own ;) [11:06] and only decide based on technical reasoning [11:07] not whether this can go into distros etc. [11:10] http://o3d.googlecode.com/svn/trunk/googleclient/third_party/cg/ [11:12] yes, like the launchpad bug says; at least you can redistribute it. problem is that a) it would be multiverse - so probably needs an exception for PPA and b) usually blobs work fine until at some point there are problems and there is no way to fix them ;) - which is why most maintainers get turned off when it comes to maintaining those [11:13] anyway, erudite... mentioned they might be willing to adapt GLSL directly ... which would be a good solution [11:14] we should at least raise this [11:28] sigh ... ppas are idle, but dont start building my trunk NM stuff :( [11:29] https://edge.launchpad.net/~network-manager/+archive/trunk [11:31] https://code.edge.launchpad.net/~jhaitas/chromium-v8/trunk/+merge/8790 [11:32] fta: is the v8 package dead? [11:32] https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head [11:33] also in state: too quickly progressing to be useful for chromium as system lib? [11:33] asac, i don't know, debian wanted to do it, and i'm not using mine at the moment, now that i have o3d and chromium, it would make sense [11:33] but if o3d is not distributable, and chromium is moving too fast with v8-tip, i don't see the point [11:35] i have the feeling that having it in archive is worthwhile. if you want i can drive this. are there any problems with licensing and blobs in the source that you know of? [11:35] iirc, chromium has a weekly sync of v8 [11:35] fta: i think o3d is distributable ... just in multiverse ... and in ppa we need to get an exception (which i would believe is ok unless someone has concerns with the new license) [11:36] i'm trying to ping the o3d dev [11:36] fta: maybe invite him to join this channel ;) [11:36] or is there a o3d channel? [11:37] anyway, i think having v8 package recovered from the dead might help us to understand how bad the weekly updates are wrt API/ABI ... which is probably the most important point we want to understand now [11:38] if you want i can drive this (as i also have to do something about mozjs as it seems :() [11:38] asac, ok, do it [11:38] i guess get-orig-source and stuff should still work? [11:41] fta: http://paste.ubuntu.com/218793/ ... any clue without looking? [11:41] seems it tries to grep in the code for the version or something [11:41] and ends up picking some c++ code ;) [11:42] gos-pack ... isnt that an upstream target? [11:43] wrong get-orig-source variable somewhere, (grep/sed/whatever) [11:43] gos-pack: VERSION = $(shell grep -A1 v8::V8::GetVersion $(TMP_DIR)/src/src/api.cc | tail -1 | cut -d\" -f2)~svn$(REVISION) [11:43] oh ... thats actually what the guy proposed to change i think [11:43] https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head/+merges [11:44] https://code.edge.launchpad.net/~jhaitas/chromium-v8/trunk/+merge/8790 [11:44] yes, but it's ugly [11:44] looks reasonable [11:44] hmm [11:44] uglier than grepping in api.cc? [11:44] i mean 6 lines to do that [11:46] so rather one line sedding? [11:46] guess that will be pretty hard to read ;) [11:46] lets check the api.cc ;) [11:49] i can do it i guess [11:54] hmm. the Version::GetSONAME doesnt really give me hope [11:54] grep -E '^#define (MAJOR|MINOR|BUILD)_(VERSION|NUMBER)' src/version.cc | awk '{ print $3 }' | tr '\n' '.' | sed -e 's/\.$//' [11:55] #define SONAME "" [11:55] thanks [11:55] #define SONAME "" [11:55] argh [11:55] hold on [11:55] http://paste.ubuntu.com/218801/ [11:56] do you know where scons sets SONAME (and how during build?) [11:56] http://code.google.com/p/v8/issues/detail?id=151 [11:59] ok great [11:59] so we just cannot build trunk [11:59] only branches [11:59] which is ok i guess [11:59] soname=on [11:59] yes. but from the bug it seems they do it now ... only on branches [11:59] which is good news [11:59] lets check if they did it on 1.2 branch too [12:00] they backed it out [12:00] wow [12:00] ah [12:08] ? [12:10] got it [12:10] its available in 1.2 [12:14] so did debian give up? [12:15] i dont know [12:15] i think someone needs to drive it [12:15] and tell them that we rather want to share our branches [12:15] instead of copying stuff to git and stuff ;) [12:18] fta: should we only checkout src/ directory or why is there src/src/ in my tarball but not in your grep? [12:20] fta: any idea how we can figure the soname used without building? [12:21] wonder if we should create the control file on the fly, guessing the soname and appending it to the libv8 name [12:21] my grep is from my chromium branch [12:21] ok [12:21] why do you need the v8 versio nthere? [12:21] ? [12:21] where? [12:21] on your chromium branch [12:22] you probably dont use the v8 version in the source version at least [12:22] nowhere. i just created the cmd line using my chromium branch, which is up-to-date, while my v8 branch is old [12:22] alrighty [12:23] hmm. the thing doesnt seem to append the date for me to the snapshot [12:23] chromium-v8_1.2.14.orig.tar.gz [12:23] gos-pack: VERSION = $(shell grep -A1 v8::V8::GetVersion $(TMP_DIR)/src/src/api.cc | tail -1 | cut -d\" -f2)~svn$(REVISION) [12:24] he i messed it up [12:24] yeah [12:24] just saw that ;) [12:24] * asac is too botty [12:24] * gnomefreak just spent last ~15 minutes talking to my coffee pot [12:26] anyone else using tbird3 notice that the scroll bar for incoming mail starts at the bottom? [12:28] gnomefreak: thats just because you ordered it that way [12:29] if you change the date order to have latest on top it should start on top [12:30] ok lets find out if that works. thanks [12:30] asac, i have #define SONAME "" in chromium, so scons will not add any soname [12:30]