[00:34] <EruditeHermit> asac, fta; I just tested it with the new mesa and an intel card. It works amazingly well
[00:34] <EruditeHermit> I am very impressed
[00:52] <fta> new mesa? which one? newer than karmic?
[00:53] <EruditeHermit> yes
[00:53] <EruditeHermit> fta: mesa 7.6 in xorg edgers
[00:53] <EruditeHermit> or I guess you can compile yourself if you want to
[00:53] <EruditeHermit> basically mesa 7.6
[00:54] <EruditeHermit> its really nice
[01:10] <EruditeHermit> fta: what card do you have and do you have a 64bit system?
[01:10] <BUGabundo> I do
[01:10] <BUGabundo> nvidia
[01:10] <EruditeHermit> BUGabundo: have you tried o3d?
[01:11] <EruditeHermit> do you use nvidia drivers?
[01:11] <BUGabundo> no
[01:11] <BUGabundo> yes
[01:12] <asac> EruditeHermit: the plugin crashed my browser on first try ;)
[01:12] <asac> first it complained that "text is not yet supported on linux"
[01:12] <EruditeHermit> yeah
[01:12] <asac> then it somewhat worked and when i hit back it crashed
[01:12] <EruditeHermit> what card?
[01:12] <asac> 965
[01:12] <EruditeHermit> and 64bit?
[01:12] <EruditeHermit> oh
[01:12] <asac> no
[01:12] <asac> 32
[01:12] <EruditeHermit> it worked here
[01:12] <EruditeHermit> pretty well
[01:13] <EruditeHermit> on intel
[01:13] <asac> well maybe it was just the example i used ;)
[01:13] <asac> i sued it in ffox 3.5
[01:13] <asac> used ;)
[01:13] <EruditeHermit> same
[01:13] <EruditeHermit> don't do the tropics demo
[01:13] <EruditeHermit> that is intense
[01:13] <EruditeHermit> try a simpler demo
[01:13] <EruditeHermit> tropics demo didn't crash for me but it didn't render everything
[01:14] <asac> EruditeHermit: anyway. after our talk i really got the ati thing work with compiz ;) - at last
[01:14] <asac> so i feel a bit more happy ;)
[01:15] <EruditeHermit> nice
[01:15] <EruditeHermit> how did you do it?
[01:15] <asac> xorg.conf had some stuff ... removed it completely
[01:15] <asac> and disbled composition_manager in metacity ;)
[01:15] <asac> obvious now, but far from obvious for me ;)
[01:16] <asac> nobody really complained about my xorg.conf before ;)
[01:16] <BUGabundo> ehehe
[01:16] <BUGabundo> you should have asked
[01:16] <EruditeHermit> asac: next thing I was going to ask you to do is to give me Xorg.0.log
[01:16] <BUGabundo> I would have told you to have a blank xorg.conf on JJ
[01:16] <asac> so i am testing ping pong
[01:16] <EruditeHermit> and that might have given me clues that your xorg.conf was messed up
[01:17] <asac> click here ... nothing happens ;)
[01:17] <EruditeHermit> hmm
[01:17] <EruditeHermit> really?
[01:17] <EruditeHermit> I tried it on the same card
[01:17] <EruditeHermit> and it worked
[01:18] <EruditeHermit> I think its problems with mesa btw
[01:18] <EruditeHermit> not with o3d itself
[01:18] <asac> prince IO works
[01:18] <asac> hmm ... now it says please wait ... loading ...
[01:18] <EruditeHermit> oh the files are large
[01:18] <EruditeHermit> the downloads are large
[01:19] <asac> i can wait a bit, but i think its broken
[01:21] <EruditeHermit> hmm
[01:21] <EruditeHermit> well
[01:21] <asac> i am loading the samples.zip now
[01:21] <EruditeHermit> when mesa 7.6 is more stable, then we'll know where the problems are
[01:21] <asac> i am running that
[01:21] <asac> the edgers stuff
[01:22] <EruditeHermit> yeah I know
[01:22] <EruditeHermit> but as I said
[01:22] <EruditeHermit> its not stable yet
[01:22] <EruditeHermit> so I'm not sure if its mesa that is causing crashes or o3d
[01:23] <asac> it doesnt crash
[01:23] <asac> it just doesnt work ;)
[01:23] <asac> at lesat not perfectly for the samles
[01:23] <asac> the odd thing is that in the samples.zip nothing works
[01:23] <asac> though the other demos on the site started at least
[01:23] <EruditeHermit> the ping pong demo worked flawlessly here
[01:23] <EruditeHermit> as did the box
[01:24] <EruditeHermit> and the simple demos
[01:24] <EruditeHermit> the picking demo
[01:24] <EruditeHermit> asac: what timezone are you in?
[01:24] <asac> +2
[01:24] <asac> UTC+2
[01:24] <EruditeHermit> wow its late there
[01:24] <asac> so i will drop out now ;)
[01:24] <asac> 2:24 am ;)
[01:25] <EruditeHermit> asac: if you want we can debug it tomorrow
[01:25] <EruditeHermit> but we are making progress
[01:26] <asac> well. i might not really have time for that in the next few days.
[01:26] <EruditeHermit> =)
[01:26] <EruditeHermit> ok
[01:26] <BUGabundo> 1:30 am here
[01:26] <BUGabundo> need to be up at 7:30 for work
[01:26] <EruditeHermit> lol
[01:26] <asac> EruditeHermit: so what libs does it depend on? v8, what else?
[01:26] <BUGabundo> rsync isn't even on 20 % :(
[01:27] <EruditeHermit> BUGabundo: did you try o3d with amd64?
[01:27] <asac> i mean google libs not in the archive ;)
[01:27] <EruditeHermit> asac: libCg
[01:27] <asac> what is that
[01:27] <BUGabundo> EruditeHermit: no
[01:27] <EruditeHermit> asac: nvidia shader
[01:27] <EruditeHermit> shading library
[01:27] <asac> EruditeHermit: is that used only by o3d or by something else as well?
[01:27] <EruditeHermit> its used by a lot of proprietary game engines
[01:27] <EruditeHermit> its used by nvidia to make video drivers
[01:28] <asac> but its completely abi/api unstable?
[01:28] <EruditeHermit> they convert GLSL to nvidia Cg
[01:28] <asac> or why isnt that in the archive?
[01:28] <EruditeHermit> its proprietary
[01:28] <asac> its proprietary even? ouch
[01:28] <EruditeHermit> it IS in the archive
[01:28] <EruditeHermit> sort of
[01:28] <EruditeHermit> its like flash
[01:28] <EruditeHermit> there is a package that downloads and installs it in the archive
[01:28] <asac> then why cant we use that lib instead of the one that is shipped in the o3d package now?
[01:28] <asac> hmm
[01:28] <EruditeHermit> you can
[01:28] <EruditeHermit> just add a dependency
[01:29] <asac> so that cant even be shipped in ppas to be honest afaik
[01:29] <EruditeHermit> yeah I was wondering why you packaged it like that
[01:29] <asac> is that at least freely redistributable?
[01:29] <EruditeHermit> I mean its nice that you did
[01:29] <asac> or not even that?
[01:29] <EruditeHermit> it is freely redistributable
[01:29] <EruditeHermit> I think
[01:29] <EruditeHermit> but we'd have to check
[01:29] <asac> nah ... i didnt. and we have to change that i guess
[01:29] <asac> i just didnt know its non-free
[01:29] <asac> depends on whether its distribuable and mirrorable
[01:30] <asac> so i think if it could stay in multiverse it might be ok. but _might_ ;)
[01:30] <EruditeHermit> well
[01:30] <EruditeHermit> this package is in there
[01:30] <EruditeHermit> nvidia-cg-toolkit
[01:30] <asac> but does that ship the .so?
[01:30] <asac> cant we use that so directly?
[01:31] <EruditeHermit> I think you can redistribute it
[01:31] <EruditeHermit> but I don't know if Ubuntu allows that
[01:32] <asac> well depends on the license of that toolkit
[01:32] <asac> i will put it on my list. but even if its suitable for multiverse it would require an exception
[01:32] <asac> so better depend on the cg-toolkit
[01:32] <asac> EruditeHermit: so is the so needed during build time?
[01:32] <asac> or do you have a glue or something?
[01:33] <EruditeHermit> its needed to build
[01:33] <asac> which makes it even more complicated :(
[01:35] <EruditeHermit> fta said he knew someone in google working on this
[01:35] <EruditeHermit> you should ask them to use GLSL shaders
[01:35] <EruditeHermit> they support HLSL which is microsoft
[01:35] <EruditeHermit> DirectX 10
[01:35] <EruditeHermit> and Nvidia Cg
[01:35] <EruditeHermit> they should support GLSL too
[01:35] <EruditeHermit> and make it open source able
[01:38] <asac> GLSL shaders are free software?
[01:39] <EruditeHermit> yeah
[01:39] <EruditeHermit> its part of the OpenGL spec
[01:39] <asac> which lib is that?
[01:39] <EruditeHermit> GL is a shading language
[01:40] <EruditeHermit> the drivers support it
[01:40] <EruditeHermit> mesa in the case of open source
[01:40] <EruditeHermit> asac: type glxinfo into a terminal
[01:40] <EruditeHermit> you'll see it says something like OpenGL 2.1 GLSL 1.20
[01:41] <asac> nope ;)
[01:41] <asac> (on ati) ;)
[01:41] <EruditeHermit> oh
[01:41] <EruditeHermit> do it with the intel card
[01:41] <EruditeHermit> or try this on the radeon
[01:41] <asac> i believe you
[01:41] <asac> just want to understand
[01:42] <EruditeHermit> LIBGL_ALWAYS_SOFTWARE=true glxinfo
[01:42] <asac> still nothing ;)
[01:42] <asac> anyway. thats not the point
[01:43] <asac> so libCg basically is a middleware so apps dont need to speak GLSL, etc. on their own, right?
[01:43] <EruditeHermit> well its another shading language
[01:43]  * BUGabundo Ta na hora da Caminha, bamos la deitar.... \n bed time. cu tomorrow
[01:43] <EruditeHermit> technically it doesn't need GLSL at all
[01:43] <asac> EruditeHermit: yes. but libCg maps it to GLSL and other
[01:44] <asac> or is that wrong?
[01:44] <EruditeHermit> but in the nvidia drivers what they did was map all GLSL calls to Cg
[01:44] <asac> hmm
[01:44] <EruditeHermit> imagine that they already wrote a windows driver that used Cg
[01:44] <EruditeHermit> then for Linux, they just translated GLSL calls to Cg
[01:44] <EruditeHermit> so that they supported GLSL on Linux
[01:44] <EruditeHermit> thats for their drivers
[01:45] <EruditeHermit> but you can program directly in Cg
[01:45] <EruditeHermit> if you wanted
[01:45] <asac> and why did o3d go for libCg ... because its platform independent?
[01:45] <EruditeHermit> no
[01:45] <EruditeHermit> well thats one reason
[01:45] <EruditeHermit> but then so is GLSL
[01:45] <EruditeHermit> GLSL is just a spec
[01:45] <EruditeHermit> that every vendor implements
[01:45] <asac> but its opengl
[01:45] <EruditeHermit> yeah
[01:46] <EruditeHermit> its opengl
[01:46] <asac> and on windows drivers are better at directx isnt that the case?
[01:46] <EruditeHermit> they probably chose Cg because its more advanced
[01:46] <EruditeHermit> on windows most drivers do both directx and opengl
[01:46] <EruditeHermit> infact most windows drivers have pretty good opengl support
[01:46] <asac> yes. but from what i understood opengl support is usually inferior (still)
[01:46] <EruditeHermit> better than linux open source drivers by miles
[01:46] <asac> heh
[01:46] <asac> thats not hard i guess ;)
[01:47] <EruditeHermit> well I think they do everything that is possible
[01:47] <EruditeHermit> ATI and Nvidia both support OpenGL on all their cards
[01:47] <EruditeHermit> to whatever level the hardware supports
[01:47] <EruditeHermit> so their newest cards support OpenGL 3.0
[01:47] <EruditeHermit> older cards support 2.1
[01:47] <EruditeHermit> fully
[01:48] <EruditeHermit> I didn
[01:48] <EruditeHermit> I didn't understand why they chose HLSL and Cg over GLSL
[01:49] <EruditeHermit> if they wanted an open source tool
[01:49] <asac> i think they dont care about distributability and opensource
[01:49] <asac> so they solely decide based on technical arguments
[01:49] <asac> 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] <asac> wrong approach (from distro point of view)
[01:50] <EruditeHermit> hmm
[01:51] <EruditeHermit> yes you can distribute nvidia cg on Linux
[01:51] <EruditeHermit> the library
[01:51] <EruditeHermit> you just can't change the binary in any way
[01:51] <EruditeHermit> https://bugs.launchpad.net/debian/+source/nvidia-cg-toolkit/+bug/284750
[01:51] <asac> why is the binary then not shipped in the nvidia-cg- package
[01:51] <asac> yeah
[01:52] <EruditeHermit> then you can depend on it
[01:52] <EruditeHermit> and build stuff
[01:52] <EruditeHermit> but its still not ideal
[01:52] <asac> right. but its hard to attract folks to care for stuff in multiverse
[01:53] <asac> and its always calling for trouble
[01:53] <EruditeHermit> talk to your contact at google
[01:54] <EruditeHermit> maybe they will bend
[01:54] <asac> something breaks -> you are lost
[01:54] <asac> i dont think so ;)
[01:54] <EruditeHermit> they might
[01:54] <EruditeHermit> they can just add the option
[01:54] <asac> question is if they still want to put resources into o3d
[01:54] <EruditeHermit> I think they do
[01:54] <EruditeHermit> I was using canvas3d until now
[01:55] <EruditeHermit> canvas3d is mozillas version
[01:55] <EruditeHermit> it uses OpenGL ES
[01:55] <asac> is that any better?
[01:55] <EruditeHermit> the license is free
[01:56] <asac> http://hg.mozilla.org/users/vladimir_mozilla.com/canvas3d/
[01:56] <EruditeHermit> the plugin itself is ok, but the javascript library it uses is slower
[01:56] <EruditeHermit> yeah
[01:56] <asac> yeah. but thats tracemonkey now and will improve
[01:56] <EruditeHermit> it was slow to the point where I could not use it
[01:56] <asac> v8 doesnt even work on amd64
[01:56] <EruditeHermit> tracemonkey doesn't
[01:56] <EruditeHermit> either
[01:56] <asac> it doesnt?
[01:57] <EruditeHermit> nope
[01:57] <asac> at least it claims to do jit compiling ;)
[01:57] <EruditeHermit> on 32bit yes
[01:57] <EruditeHermit> atleast it doesn't for firefox 3.5
[01:57] <asac> why do you think that?
[01:57] <EruditeHermit> they may have started porting it over
[01:57] <asac> i havent heard of that
[01:57] <EruditeHermit> i talked to vlad
[01:57] <asac> could be that i have overheard that
[01:58] <EruditeHermit> the one whos blog you read
[01:58] <EruditeHermit> whose*
[01:58] <EruditeHermit> I talked to guys at mozilla and they turned it off for 64bit
[01:59] <asac> turned it off ... i have the switch turned on here at least
[01:59] <asac> so either the switch doesnt do anything or its on
[02:00] <asac> anyway. what matters is that it works ;)
[02:01] <asac> personally i have things to critize about libmozjs as well ;)
[02:01] <asac> so v8 or mozjs isnt that a big difference. just that you cant run v8 on 64-bit yet properly
[02:06] <asac> 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] <asac> http://github.com/sandys/tracemonkey-64bit/tree/master
[02:11] <EruditeHermit> ok
[02:11] <EruditeHermit> but thats recent
[02:11] <EruditeHermit> july 8
[02:11] <asac> yes
[02:16] <asac> ok off for real now
[02:16] <EruditeHermit> ok
[02:16] <EruditeHermit> gngight
[06:22] <nareshov> fta - no flock for jaunty in your ppa? :/
[08:46] <asac> hi
[09:01] <micahg> hi asac
[09:02] <asac> hi micahg
[09:02] <micahg> we had someone submit a rant report in firefox-3.5
[09:02] <micahg> bug 399517
[09:35] <micahg> asac: ^^^
[09:36] <micahg> also, can we move bugs to the firefox-3.6 package yet?
[09:56] <asac> micahg: no. we dont have any 3.6 package. why?
[09:56] <asac> are there bugs reported that are only in 3.6?
[10:39] <fta> asac, when ended up of that o3d discussion with EruditeHermit?
[10:40] <fta> i read we need mesa 7.6, but what for? intel? ati?
[10:42] <asac> fta: the discussion ended in the situation where I found out that libCg.so isnt even free software ;)
[10:42] <fta> it's not?
[10:42] <asac> fta: he said you are talking with google about moving that to GLSL ?
[10:42] <fta> eh?
[10:42] <fta> am i?
[10:43] <asac> 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] <asac> bug 284750
[10:44] <asac> http://developer.nvidia.com/object/cg_toolkit.html
[10:45] <fta> damn, i thought i was dropping all binaries
[10:45] <asac> fta: we should definitly raise this with the o3d authors.
[10:45] <asac> 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] <asac> messy for sure
[10:47] <asac> 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] <fta> 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] <asac> fta: right. i didnt say evilplan its just that they only think about distributing on their own ;)
[11:06] <asac> and only decide based on technical reasoning
[11:07] <asac> not whether this can go into distros etc.
[11:10] <fta> http://o3d.googlecode.com/svn/trunk/googleclient/third_party/cg/
[11:12] <asac> 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] <asac> anyway, erudite... mentioned they might be willing to adapt GLSL directly ... which would be a good solution
[11:14] <asac> we should at least raise this
[11:28] <asac> sigh ... ppas are idle, but dont start building my trunk NM stuff :(
[11:29] <asac> https://edge.launchpad.net/~network-manager/+archive/trunk
[11:31] <asac> https://code.edge.launchpad.net/~jhaitas/chromium-v8/trunk/+merge/8790
[11:32] <asac> fta: is the v8 package dead?
[11:32] <asac> https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head
[11:33] <asac> also in state: too quickly progressing to be useful for chromium as system lib?
[11:33] <fta> 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] <fta> but if o3d is not distributable, and chromium is moving too fast with v8-tip, i don't see the point
[11:35] <asac> 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] <fta> iirc, chromium has a weekly sync of v8
[11:35] <asac> 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] <fta> i'm trying to ping the o3d dev
[11:36] <asac> fta: maybe invite him to join this channel ;)
[11:36] <asac> or is there a o3d channel?
[11:37] <asac> 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] <asac> if you want i can drive this (as i also have to do something about mozjs as it seems :()
[11:38] <fta> asac, ok, do it
[11:38] <asac> i guess get-orig-source and stuff should still work?
[11:41] <asac> fta: http://paste.ubuntu.com/218793/ ... any clue without looking?
[11:41] <asac> seems it tries to grep in the code for the version or something
[11:41] <asac> and ends up picking some c++ code ;)
[11:42] <asac> gos-pack ... isnt that an upstream target?
[11:43] <fta> wrong get-orig-source variable somewhere, (grep/sed/whatever)
[11:43] <asac> gos-pack: VERSION  = $(shell grep -A1 v8::V8::GetVersion $(TMP_DIR)/src/src/api.cc | tail -1 | cut -d\" -f2)~svn$(REVISION)
[11:43] <asac> oh ... thats actually what the guy proposed to change i think
[11:43] <asac> https://code.edge.launchpad.net/~chromium-team/chromium-v8/chromium-v8.head/+merges
[11:44] <asac> https://code.edge.launchpad.net/~jhaitas/chromium-v8/trunk/+merge/8790
[11:44] <fta> yes, but it's ugly
[11:44] <asac> looks reasonable
[11:44] <asac> hmm
[11:44] <asac> uglier than grepping in api.cc?
[11:44] <fta> i mean 6 lines to do that
[11:46] <asac> so rather one line sedding?
[11:46] <asac> guess that will be pretty hard to read ;)
[11:46] <asac> lets check the api.cc ;)
[11:49] <fta> i can do it i guess
[11:54] <asac> hmm. the  Version::GetSONAME doesnt really give me hope
[11:54] <fta> grep -E '^#define (MAJOR|MINOR|BUILD)_(VERSION|NUMBER)' src/version.cc | awk '{ print $3 }' | tr '\n' '.' | sed -e 's/\.$//'
[11:55] <asac> #define SONAME            ""
[11:55] <asac> thanks
[11:55] <asac> #define SONAME            ""
[11:55] <asac> argh
[11:55] <fta> hold on
[11:55] <asac> http://paste.ubuntu.com/218801/
[11:56] <asac> do you know where scons sets SONAME (and how during build?)
[11:56] <fta> http://code.google.com/p/v8/issues/detail?id=151
[11:59] <asac> ok great
[11:59] <asac> so we just cannot build trunk
[11:59] <asac> only branches
[11:59] <asac> which is ok i guess
[11:59] <fta> soname=on
[11:59] <asac> yes. but from the bug it seems they do it now ... only on branches
[11:59] <asac> which is good news
[11:59] <asac> lets check if they did it on 1.2 branch too
[12:00] <asac> they backed it out
[12:00] <asac> wow
[12:00] <asac> ah
[12:08] <fta> ?
[12:10] <asac> got it
[12:10] <asac> its available in 1.2
[12:14] <fta> so did debian give up?
[12:15] <asac> i dont know
[12:15] <asac> i think someone needs to drive it
[12:15] <asac> and tell them that we rather want to share our branches
[12:15] <asac> instead of copying stuff to git and stuff ;)
[12:18] <asac> fta: should we only checkout src/ directory or why is there src/src/ in my tarball but not in your grep?
[12:20] <asac> fta: any idea how we can figure the soname used without building?
[12:21] <asac> wonder if we should create the control file on the fly, guessing the soname and appending it to the libv8 name
[12:21] <fta> my grep is from my chromium branch
[12:21] <asac> ok
[12:21] <asac> why do you need the v8 versio nthere?
[12:21] <fta> ?
[12:21] <fta> where?
[12:21] <asac> on your chromium branch
[12:22] <asac> you probably dont use the v8 version in the source version at least
[12:22] <fta> nowhere. i just created the cmd line using my chromium branch, which is up-to-date, while my v8 branch is old
[12:22] <asac> alrighty
[12:23] <asac> hmm. the thing doesnt seem to append the date for me to the snapshot
[12:23] <asac> chromium-v8_1.2.14.orig.tar.gz
 gos-pack: VERSION  = $(shell grep -A1 v8::V8::GetVersion $(TMP_DIR)/src/src/api.cc | tail -1 | cut -d\" -f2)~svn$(REVISION)
[12:24] <asac> he i messed it up
[12:24] <asac> yeah
[12:24] <asac> just saw that ;)
[12:24]  * asac is too botty
[12:24]  * gnomefreak just spent last ~15 minutes talking to my coffee pot
[12:26] <gnomefreak> anyone else using tbird3 notice that the scroll bar for incoming mail starts at the bottom?
[12:28] <asac> gnomefreak: thats just because you ordered it that way
[12:29] <asac> if you change the date order to have latest on top it should start on top
[12:30] <gnomefreak> ok lets find out if that works. thanks
[12:30] <fta> asac, i have #define SONAME "" in chromium, so scons will not add any soname
[12:30] <asac> fta: right. thats probably correct for the in-source built
[12:31] <asac> fta: but that .so should be shipped in pkglibdir (in case its not)
[12:32] <gnomefreak> !info firefox-3.0
[12:34] <asac>       env.Default('sample')
[12:34] <asac> +   if env['install']:
[12:34] <asac> +     env.Default('install')
[12:34] <fta> "safe and easy" lol
[12:34] <asac> fta: any particular reaons why you didnt use elif there?
[12:35] <asac> yeah. updates to package description welcome ;)
[12:35] <asac> ok lets see if the build explodes ;)
[12:36] <asac> src/handles-inl.h:50: error: dereferencing pointer '<anonymous>' does break strict-aliasing rules
[12:36] <asac> got a patch for that in chromium?
[12:37] <fta> disable Werror or build with gcc 4.3 :(
[12:38] <asac> upstream bug filed?
[12:38] <asac> http://code.google.com/p/v8/issues/detail?id=266
[12:39] <fta> yep
[12:39] <fta> if you fix the warning, it crashes
[12:40] <fta> so we ended up hiding it instead :(
[12:40] <fta> i'm still building chromium with gcc 4.3, maybe i should retry 4.4
[12:40] <asac> -fno-strict-aliasing
[12:41] <asac> guess we shoujld use that instea of Wno-error
[12:41] <asac> and only for the file affected if possible :)
[12:41] <asac> does Scons honour CXXFLAGS?
[12:42] <asac> seems it does ... lets hope the order is ok now
[12:42] <fta> i used -Wno-error because gcc likes to catch new stuff every few days, and as it's not the same tree, it blocks chromium for days/weeks, so i have to add patches, which rot quickly
[12:43] <fta> in the jaunty days, i convinced google to setup a builder with gcc 4.3 (as they build with 4.2 by default)
[12:43] <fta> no, we would need another builder with 4.4 :P
[12:43] <fta> -we+they
[12:44] <asac> ok
[12:44] <asac> but i guess the same reasoning doesnt apply here
[12:44] <asac> do you at least only remove error for v8 lib etc.?
[12:46] <fta> http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/patches/gcc44_drop_werror_in_v8.patch
[12:46] <fta> that's what i have
[12:47] <fta> hm, does v8 use gyp at all? i mean outside of chromium
[12:47] <asac> i dont think it does
[12:47] <asac> committed it
[12:47] <asac> to branch
[12:47] <asac> CXXFLAGS + CFLAGS
[12:48] <asac> oh i also need http://paste.ubuntu.com/218853/ if those are not set, right?
[12:48] <asac> or will += work if its not yet set?
[12:48] <gnomefreak> asac: fta do you happen to know what size icon is used for firefox or tbird? 50x50 or 128x128?
[12:49] <asac> gnomefreak: depends
[12:49] <asac> gnomefreak: there are various sizes now in 3.5
[12:49] <asac> 48x48 14x14 28x28 and 256x256 at least ... maybe even 10x10
[12:49] <asac> not so sure
[12:49] <asac> just check the package pngs
[12:50] <gnomefreak> asac: sorry i meant what size we use for firefox*
[12:53] <fta> asac, += works fine if its not set
[12:54] <asac> really? odd. it didnt work for me with fakeroot debian/rules binary
[12:55] <asac> but worked with debuild
[12:55] <fta> ?
[12:56] <asac> well debuild and dpkg-buildpackage set CXX and CFLAGS
[12:56] <asac> faeroot ./debian/rules binary is running the target manually
[12:56] <asac> http://paste.ubuntu.com/218866/
[12:56] <asac> that works
[12:57] <fta> er? just add the export, not that shellish thing
[12:58] <asac> hmm
[12:58] <asac> right i will uncommit that then
[13:14] <bluekuja> hi all
[13:17] <asac> hi... let me check your stuff now
[13:17] <bluekuja> ok, great, thanks alex
[13:20] <asac> bluekuja: how about using a valid email for committing ;)? checkout bzr log
[13:21] <bluekuja> asac, yeah, it uses my login details
[13:21] <bluekuja> asac, like myname@computername
[13:21] <asac> fix that in future
[13:21] <asac> i breaks my heart
[13:21] <bluekuja> lol
[13:21] <asac> you cannot even click on it in launchpad and get to your account
[13:22] <asac> bluekuja: it downloaded the orig from the upstream ftp location for cgmail ... instead of using the upstream branch. is that ok with you?
[13:22] <bluekuja> asac, yeah, it's the same
[13:22] <bluekuja> asac, I didnt touch upstream files at all
[13:22] <bluekuja> asac, so getting them from upstream or my branch is the same
[13:23] <asac> bluekuja: please use debcommit -r to do a release ... that just updates changelog and adds a tag
[13:23] <bluekuja> asac, it uses a watch file that's why
[13:23] <asac> helps to spot which revision was uploaded as which version
[13:23] <bluekuja> asac, debcommit -r to the candicate release for upload?
[13:23] <bluekuja> * candidate
[13:25] <asac> bluekuja: for every package upload
[13:25] <bluekuja> asac, ok
[13:25] <asac> like you commit and commit and for the release you run debcommit -r once
[13:25] <asac> ok both uploaded
[13:25] <asac> enjoy
[13:25] <bluekuja> asac, thanks a lot
[13:25] <bluekuja> asac,
[13:25] <bluekuja> im going to the sea this evening
[13:25] <asac> please fix email in bzr for future
[13:25] <asac> enjoy
[13:26] <bluekuja> I will, thanks
[13:26] <bluekuja> asac, one package is missing, I'll fix it as soon as I get back (it failed to build on gcc 4.4 cause missing includes)
[13:26] <bluekuja> so easy fix
[13:26] <asac> thats why i asked you to submit all ;)
[13:27] <asac> i really have no time ... so doing in a batch is the only thing i can do ;)
[13:27] <bluekuja> asac, yeah, sorry, had a busy time this two days, so I couldnt fix it
[13:27] <asac> its ok. you just have to wait
[13:27] <asac> longer than this time for sure
[13:27] <gnomefreak> ok lets hope this works :)
[13:27] <asac> (i gave you fast track because you)
[13:28] <bluekuja> asac, THANKS a lot
[13:28] <asac> bluekuja: then you shouldnt have send me the other branches. i asked you to give me all ;) ... but well. just dont bug me if it takes a week or so
[13:28] <bluekuja> asac, yeah, anyway next time I gonna send you all stuff
[13:28] <bluekuja> asac, so you can process them all in one time
[13:29] <asac> ok. maybe wait for the next pacakge a bit and see if you need to update any of the other packages
[13:29] <bluekuja> ok
[13:29] <asac> like there might be new bug reports
[13:29] <bluekuja> asac, gonna fix it on the branch only
[13:29] <asac> or people complaining that their bugs are not fixed yet etc.
[13:29] <bluekuja> yep
[13:29] <bluekuja> asac, can I ask you something private? I write u a mail
[13:30] <bluekuja> asac, please answer me there when you have a second
[13:33] <asac> bluekuja: sure. but might take a while if its not trivial
[13:38] <gnomefreak> asac: ok uploaded sunbird with some other fixes to PPA, lets see what happens :)
[13:39] <gnomefreak> ok getting real tiresd of the amount of ubuntuone bugs and i cant remember where to unsubscribe
[13:39] <bluekuja> asac, sent
[13:43] <gnomefreak> very little bug work seems to have been done since yesterday at this time
[13:45] <gnomefreak> i might gottem ~12 bugs in my email in 24 hours not including ubuntuone bugs
[13:48] <asac> good for you ;)
[13:48] <asac> maybe launchpad has a mail problem and you will all at once at some point ;)
[13:52] <gnomefreak> asac: i asked in Ubuntuone but this is really weird and hope to get it fixed but if not ill find it sooner or later :)
[13:54] <gnomefreak> asac: do the arm fixes in sunbird and other bug work meet SRU requirments? at least for the 0.9 releases we pushed
[13:56] <gnomefreak> im not real sure how supported armel is but i dont think its all that important to have the fixes sent <Karmic
[14:13] <gnomefreak> asac: who is working on bluez? it failed to upgrade?
[14:13] <fta> hm, not sure i should dist-upgrade upstart...
[14:13] <fta> The following packages will be REMOVED:
[14:13] <fta>   startup-tasks system-services upstart-compat-sysv upstart-logd
[14:13] <fta> The following packages will be upgraded:
[14:13] <fta>   upstart
[14:13] <fta> 1 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
[14:13] <gnomefreak> fta: dont
[14:14] <fta> bug?
[14:14] <gnomefreak> you can install the other held back packages
[14:14] <gnomefreak> fta: seems depends issues
[14:14] <gnomefreak> fta: i lied you cant install the others.
[14:14] <fta> ok
[14:14] <fta> brb, reboot
[14:15] <gnomefreak> fta: the devicedisks... package you can install if its held back
[14:15] <fta> i just have upstart left
[14:16] <gnomefreak> yeah leave that
[14:17] <gnomefreak> you have to love when this happens:
[14:17] <gnomefreak> invoke-rc.d: initscript bluetooth, action "stop" failed.
[14:18] <fta> because bluetoothd is not running
[14:18] <fta> edit /etc/init.d/bluetooth and remove set -e
[14:20] <gnomefreak> fta: thanks
[14:22] <gnomefreak> how do i test armel builds before pushing to repos
[14:23] <fta> lol, that was not a reboot, just a restart of X
[14:26] <fta> asac, what's the plan for v8 now?
[14:28] <asac> fta: fix it, make the packaging great, extinguish debian :)
[14:29] <asac> how is it called. extend/embrace/extinguish :-P
[14:30] <asac> fta: build branches rather then trunk
[14:30] <asac> so we can track ABI/API while staying on top.
[14:31] <asac> i have to think how to best deal with trunk packaging wise
[14:35] <fta> gasp, my gnome menu has been sorted alphabetically, give me my order back!
[14:38] <fta> and my desktop too :(
[14:42] <fta> asac, should not be difficult to track a branch
[14:42] <fta> should be trivial
[14:43] <asac> yeah i had that inserted
[14:43] <asac> but have to think a bit for a while if we can still track trunk somehow in a way that works good for packaging
[14:59] <fta> asac, inserted?
[15:01] <fta> damn, a new dbus, and i just rebooted :P
[15:02] <asac> fta: inserted: changed debian/rules to smartly get the right branch from current upstream version in changelog etc.
[15:02] <asac> which wasnt really that smart :)
[15:02] <asac> but good enough for that purpose i think
[15:22]  * gnomefreak not sunctioning very well today :(
[15:23] <gnomefreak> been building source for sunbird/jaunty for last hour or 2 and i think i finally got it to work
[15:27] <gnomefreak> did my menu redo its self? things i removed from it came back
[15:33] <fta> me too, tell them in -dekstop
[15:36] <gnomefreak> good not just me than :)
[15:44] <fta> for once :)
[15:47] <gnomefreak> :) but only a few of us saw it from what i gather from @ubuntu-desktop
[15:47] <gnomefreak> s/@/#
[15:57] <gnomefreak> yay once i get a confirm that the icon bug is fixed ill push to branch and im done with sunbird for the month :)
[16:19] <gnomefreak> this has to suck http://www.abc.net.au/news/stories/2009/07/16/2627129.htm
[16:24] <bluekuja> asac, did you get my mail?
[16:28] <gnomefreak> testing  _test-underline_
[16:28] <gnomefreak> nope guess you cant have - in there
[16:31] <bluekuja> andrew_sayers, you there?
[16:31] <andrew_sayers> bluekuja: hey.
[16:34] <gnomefreak> cant comprimise of a hunnymoon location in september, she wants hot i want cold
[16:37] <asac> bluekuja: i saw a mail from you .yes.
[16:37] <bluekuja> asac, ok, perfect
[17:07] <fta> ppa crowded again: 77/71/58 with 6/8/5 builders
[17:08] <Nafallo> ehrm
[17:08] <Nafallo> that's not right
[17:08] <Nafallo> 8/11/7
[17:09] <fta> it's dynamic, i just poll every 30min ;)
[17:09] <gnomefreak> that explains why its taken over an hour to build
[17:09] <Nafallo> of course it is
[17:10] <fta> or i should say, my script gets different results from the browser..
[17:10] <fta> polling the same page
[17:12] <fta> faking a user agent doesn't help
[17:12] <fta> maybe because the script is not logged in
[17:15] <fta> http://www.sofaraway.org/ubuntu/tmp/ppa-builders.sh.txt
[17:15] <fta> the joy of screen scrapping ;)
[17:48] <kristina> hi
[17:48] <kristina> i'm making an ubuntu package that needs spidermonkey to have utf8 support
[17:48] <kristina> but the xulrunner package has spidermonkey 1.7, which has to be compiled with a certain flag to support utf8
[17:48] <kristina> is there someone i can talk to about upgrading the spidermonkey to 1.8 or compiling it with the utf8 flag?
[17:48] <kristina> xulrunner-1.9 uses spidermonkey 1.8 and the debian xulrunner package has upgraded to 1.8
[17:49] <kristina> i can to help out with whatever needs to be done
[18:03] <kristina> does xulrunner-1.9 provide libmozjs.so?
[18:11] <micahg> kristina: it's provided in 1.9 and 1.9.1
[18:13] <kristina> oh, i see, it's in dev, that makes sense
[18:13] <kristina> thank you
[18:14] <micahg> it should just be in /usr/lib/xulrunner-ver
[18:14] <micahg> *1.9 or 1.9.1
[18:14] <kristina> hmm
[18:15] <kristina> oh yeah, i didn't see it there before :-/
[18:15] <kristina> sorry
[19:02] <asac> micahg: bug 107247
[19:02] <asac> could you check if that happens in upstream trunk builds too?
[19:02] <asac> and then we must forward it i guess
[19:03] <asac> seems its a rather old bug we triaged when we still used tags to signal that something is ready for upstreaming (e.g. mt-postupstream)
[19:33] <asac> kristina: libmozjs.so in its current form is dead
[19:33] <asac> and will be removed from the archive
[19:33] <asac> (the one shipped by the old libmozjs package)
[19:33] <kristina> ok, but i can still use the one in xulrunner-1.9, right?
[19:34] <asac> kristina: you can use it with some things in mind:
[19:34] <asac> a) its not officially guaranteed that there is any abi/api breakage in a security update (though in practice this doesnt happen)
[19:34] <asac> b) thats why we dont ship it in /usr/lib atm, e.g. we dont encourage packages to link against it
[19:35] <asac> c) you need to take care that your app find its by setting LD_LIBRARY_PATH in your start script
[19:35] <kristina> so is there a better way to get the spidermonkey libraries?
[19:37] <asac> no. its an upstream problem that they have no real releaess
[19:37] <asac> its a political thing as well
[19:37] <asac> for now use the way i described if you really need to use a js engine
[19:37] <kristina> ok, thanks
[19:38] <asac> use pkg-config --cflags --libs mozilla-js to build and set LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-`xulrunner --gre-version`
[19:38] <asac> during runtime
[19:38] <asac> err
[19:38] <asac> sorry
[19:38] <asac> se pkg-config --cflags --libs mozilla-js to build and set LD_LIBRARY_PATH=/usr/lib/xulrunner-`xulrunner --gre-version`
[19:38] <asac> kristina: ^^
[19:39] <kristina> ok
[19:39] <kristina> i'm working on a mongodb package, it looks like we're hitting the same issues couchdb did with this
[19:39] <asac> kristina: why does that package need spidermonkey for utf-8 support? what does it use if it doesnt do that?
[19:40] <kristina> it uses spidermonkey to execute javascript on the server side of the db, we need utf8 because people keep putting international characters in their scripts
[19:40] <asac> kristina: and what would you use if you dont use spidermonkey?
[19:41] <kristina> for... utf8? javascript?
[19:42] <asac> you say you need spidermonkey for utf8 support
[19:42] <asac> if you wouldnt need to support utf8. what would you use?
[19:42] <kristina> no, i need spidermonkey with utf8 support
[19:42] <asac> i dont get why you add the "with utf8" support to it ;)
[19:43] <asac> doesnt the current spidermonkey work for utf8? or is that a special build?
[19:43] <asac> sorry if i might be desne, but i definitly miss context
[19:43] <kristina> libmozjs-dev comes with sm 1.7, which needs to be compiled with a special flag to support utf8
[19:44] <kristina> with sm 1.8, you can enable it at runtime
[19:44] <kristina> so as long as i have access to 1.8, i'm fine
[19:45] <asac> heh. ok
[19:46] <asac> kristina: 1.8 is 1.9 xul?
[19:46] <asac> and what is in 1.9.1? i never tracked how javascript folks really release their stuff
[19:46] <kristina> xulrunner-1.9 contains spidermonkey 1.8
[19:47] <kristina> (confusingly)
[19:47] <kristina> aren't you one of the main mozilla people? :)
[19:50] <kristina> it looks like xulrunner-1.9 mushed together a bunch of the 1.8 xul stuff
[19:50] <kristina> i'm not terribly clear on it myself
[19:57] <asac> kristina: main mozilla people? not sure. i am working quite long on mozilla stuff, but mostly on distro side and on security backports upstream. the javascript engine release cycles were always a mystery and i think there is no real rule ;)
[19:58] <asac> but good news is that it seems to be sexy to use javascript nowadays
[19:58] <asac> and more packages need that
[19:58] <asac> so we have to do something on that
[19:58] <asac> kristina: which package is it?
[19:59] <kristina> mongodb
[20:00] <kristina> not actually in the repository yet
[20:06] <asac> kristina: what about? similar to couchdb?
[20:06] <asac> kristina: did you consider to use webkit js engine?
[20:07] <kristina> yeah, it's another document-oriented db
[20:07] <asac> and json is what makes javascript so sexy there? or is it just the trend because javascript is ubiqous and now even fast?
[20:09] <kristina> i don't think we considered webkit, we originally were using v8 but they don't support 64-bit
[20:09] <kristina> i think it's because everyone knows some js and it's fast and easy
[20:10] <kristina> our db actually uses this thing we call bson, binary json, for everything, so it makes sense to use json, too
[20:12] <sebner> asac: *if* I'm ever again mentioned in a ff/xulrunner changelog please with "f" instead of "ph" ;)
[20:13] <asac> urgh
[20:14] <asac> i thought i copied it .... really sorry
[20:14] <asac> i even thought. better check one more time, because its not nice to misspell
[20:14] <asac> and still i made a mistake
[20:14] <sebner> asac: nvm nvm
[20:14] <asac> sebner: i can flip it on next upload. though it wont show up on launchpad (just in changelog)
[20:14] <asac> ok
[20:15] <asac> sebner: but now you probably see what i ment ;)
[20:15] <sebner> asac: fix is working though and that's what counts :)
[20:15] <asac> e.g. where to insert thec hangelog entry etc.
[20:16] <sebner> asac: well, only working when using bzr :P
[20:18] <LLStarks> is asac or fta alive?
[20:24] <asac> LLStarks: at least i payed my provider bill last moth which might indicate that i am still alive
[20:25] <LLStarks> ah
[20:25] <pace_t_zulu> asac: i marked that branch as abandoned
[20:25] <pace_t_zulu> asac: your way is definitely more elegant than mine
[20:25] <asac> which one?
[20:25] <asac> ah the v8?
[20:25] <pace_t_zulu> asac: talking about chromium-v8
[20:25] <pace_t_zulu> asac: yeah i'm 'jhaitas'
[20:25] <asac> yeah. well. personally i think its all ugly ;)
[20:25] <asac> but it works
[20:26] <asac> pace_t_zulu: great. nice to meet you (i think we chattete before though)
[20:26] <pace_t_zulu> asac: yeah we have... pleasure
[20:26] <pace_t_zulu> asac: i'm learning more about debian packaging
[20:26] <asac> nice
[20:27] <asac> i just ended up thinking we should drive the v8 effort a bit more
[20:27] <asac> seems like the debian guy doesnt get his act together et al ;)
[20:27] <pace_t_zulu> asac: i agree that v8 could get more love
[20:27] <pace_t_zulu> asac: it can be useful outside of chromium
[20:27] <asac> yeah. if only there was also 64-bit
[20:27] <asac> but at least they have SONAMEs now
[20:27] <pace_t_zulu> and it could help with reducing chromium
[20:28] <asac> which bumps them in a different league from sexiness for the distro
[20:28] <fta> asac, initial x64 support is in trunk, improving every day
[20:28] <asac> right. thats why i think we should do it
[20:28] <asac> and push that through
[20:28] <pace_t_zulu> fta, yeah i saw some x64 code in the tree
[20:28] <asac> we need an answer to libmozjs.so not having a SONAME
[20:29] <pace_t_zulu> asac and fta, i recall talking to you guys about reducing chromium in the past
[20:29] <asac> ack
[20:29] <pace_t_zulu> y'all mentioned that skia would be a possibility
[20:29] <fta> asac, almost all google chrome-dev are running x64, so once v8 is good enough, x64 fixes are likely to flow in
[20:29] <asac> but from what we understand it wont work for chromium trunk builds
[20:30] <asac> though i know that chrome really seems to have some kind of stable branch model
[20:30] <jcastro> \o/
[20:30] <pace_t_zulu> some i'm working with a guy in my LoCo who is much better at packaging than me...
[20:30] <asac> which i hope might also stabilize on a v8 branch which we can shi pthen
[20:30] <pace_t_zulu> we're working on packaging skia...
[20:30] <asac> skia would be the next topic
[20:30] <asac> after v8
[20:30] <asac> problem is the same as with v8 ... trunk chromium needs a moving skia
[20:31] <asac> so we need to find out if skia will do stable release branches similar to v8
[20:31] <jcastro> asac: btw I did most of gcds with the prism/gears offline combo and it was quite awesome.
[20:31] <asac>  and chromium settles on one of those
[20:31] <pace_t_zulu> but it is apparent that the google devs haven't intended skia to stand alone
[20:31] <asac> jcastro: did stefanlsd get it in yet? last i know was that i signed off his built in revu
[20:31] <fta> asac, "trunk chromium needs a moving " everything
[20:32] <asac> yes
[20:32] <asac> i didnt say any different
[20:32] <asac> ;)
[20:32] <jcastro> asac: yeah it's in universe
[20:32] <asac> i think skia might need some talk upstream. i think it should work if its usable for anything else than chromium in theory
[20:33] <asac> if nobody wants skia i dont care - though i think gears uses it at least
[20:33] <asac> jcastro: thanks. thats great news indeed.
[20:33] <asac> jcastro: did he fix it for firefox 3.5 yet?
[20:33] <asac> jcastro: or just 3.0?
[20:33] <pace_t_zulu> asac: skia doesn't seem to move that fast
[20:33] <asac> pace_t_zulu: even better
[20:34] <asac> pace_t_zulu: problem is not the speed, but the api stability
[20:34] <pace_t_zulu> asac: the revision number is below 300 ... so it doesn't change frequently
[20:34] <asac> then it might just require some talk
[20:34] <asac> with upstreawm
[20:34] <asac> do you know skia upstream?
[20:34] <jcastro> asac: not for ff3.5 yet
[20:34] <asac> ok thats what i remember from my last discussion with him
[20:35] <andrew_sayers> asac: Any news on 3.5 in Hardy/Intrepid?
[20:36] <pace_t_zulu> asac: no i'm not in with the upstream crowd ;)
[20:36] <asac> yeah. its good thing to find right upstream people when starting to package something
[20:36] <pace_t_zulu> skia is at r266 ... it was checked in sept 20 2006... but it's been moving recently
[20:37] <pace_t_zulu> it's only really  been getting attention since December
[20:37] <asac> pace_t_zulu: whcih branch are you looking at?
[20:38] <pace_t_zulu> asac: i'm looking at the trunk
[20:38] <pace_t_zulu> does chromium use a branch?
[20:39] <asac> pace_t_zulu: chromium trunk uses trunk from what i know
[20:39] <asac> fta: ?
[20:39] <pace_t_zulu> asac: there are no branches
[20:39] <asac> pace_t_zulu: right. we need to change that
[20:39] <pace_t_zulu> asac: there are no tags either
[20:39] <fta> yes, delta the green revision
[20:39] <asac> the green revision?
[20:39] <fta> :)
[20:40] <asac> is that saving the world?
[20:40] <asac> ;)
[20:40] <fta> GREEN_REV_URL := http://chromium-status.appspot.com/lkgr
[20:40] <pace_t_zulu> haha...
[20:40] <fta> $ GET http://chromium-status.appspot.com/lkgr
[20:40] <fta> 20762
[20:40] <pace_t_zulu> i was wondering what you were talking about fta
[20:40] <fta> gives me the revision of the last successful build upstream
[20:41] <fta> see http://paste.ubuntu.com/219230/
[20:42] <fta> ~ line 344
[20:43] <asac> is the green rev out of sync with trunk?
[20:44] <fta> it's off by at most 1 hour
[20:44] <fta> same branch (trunk)
[20:45] <fta> i just avoid commits that made the tree burn
[20:45] <fta> (it was far too often)
[20:47] <fta> it's called "Staying Green More Of The Time"
[20:48] <fta> http://chromium-status.appspot.com/lkgr
[20:48] <fta> This URL holds the version of the latest revision to pass only unit tests (in debug mode). This can happen faster, so for most developers this is probably what you want since it will help you ensure that your changes work against a "fresher" version of Chromium.
[20:48] <fta> there's also:
[20:48] <fta> http://build.chromium.org/buildbot/continuous/LATEST/REVISION
[20:48] <fta> This corresponds to the most recent revision that passed both unit tests and layout tests. Since layout tests can take a while to run, this revision may be an hour or more "stale".
[20:48] <fta> so the ppa is less than 1h off
[20:49] <fta> most probably 5 minutes
[20:49] <fta> as they don't clobber the build that often
[20:49]  * fta likes to talk alone
[20:49] <fta> i can sing it if you like :)
[20:50] <pace_t_zulu> fta: i hear you
[20:50] <pace_t_zulu> had to step out the room for a minute just now
[20:51] <asac> fta: how do i get the skia revision used right now?
[20:51] <asac> both just spit out 20762
[20:51] <pace_t_zulu> asac: it's 266
[20:51] <fta> http://src.chromium.org/viewvc/chrome/trunk/src/DEPS
[20:51] <asac> well. thats what you said. but fta said it uses the last green revision
[20:51] <asac> and posted that url
[20:52] <asac> so i was confused seein 20k there ;)
[20:52] <pace_t_zulu> ahh
[20:52] <pace_t_zulu> i should add that to my stuff
[20:52] <asac> "http://skia.googlecode.com/svn/trunk@250",
[20:52] <asac> so its even 250?
[20:52] <asac> ok
[20:52] <pace_t_zulu> i created a skia project on launchpad
[20:53] <pace_t_zulu> for packaging skia
[20:53] <fta> asac, i use the last green for chromium, which contains its DEPS file pointing the skia that was used at this point in time, so it's r250 (now)
[20:53] <asac> thats ok. just try to avoid creating new teams per package ;)
[20:53] <asac> fta: ack. understood. and thanks for the info
[20:53] <pace_t_zulu> asac: so i guess the skia-team was a bad idea
[20:53] <asac> so skia is indeed quite stable
[20:54] <pace_t_zulu> asac: that's why i'm interested in packaging skia
[20:54] <asac> pace_t_zulu: yes. first we need to file a bug about skia not having a soname ... or does it have one?
[20:54] <pace_t_zulu> asac: i haven't looked
[20:55] <fta> have a look at http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?view=log
[20:55] <fta> it's mostly webkit, v8 and gyp
[20:55] <fta> they move a lot
[20:55] <pace_t_zulu> asac: don't think so... http://code.google.com/p/skia/issues/list?can=1&q=soname&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles
[20:56] <fta> i'm now bugcontrol for chromium btw
[20:56] <pace_t_zulu> fta: nice
[20:57] <asac> fta: congrats
[20:58] <pace_t_zulu> asac: i can file an issue right now
[20:58] <pace_t_zulu> asac: "skia needs a SONAME"
[20:59] <pace_t_zulu> asac: or would you rather do it
[21:00] <fta> refer to the v8 bug, the rationale is there
[21:02] <pace_t_zulu> fta: i reused some of your code in the skia packaging code
[21:02] <pace_t_zulu> fta: do you have a link for the v8 bug?
[21:02] <fta> http://code.google.com/p/v8/issues/detail?id=151
[21:02] <pace_t_zulu> fta: ty
[21:02] <fta> the packaging should be almost identical
[21:02] <pace_t_zulu> fta: that was my thinking
[21:03] <pace_t_zulu> fta: currently a skia make only produces libskia.a ...
[21:04] <asac> yeah
[21:04] <asac> refer to that bug
[21:05] <asac> and say we need something similar
[21:05] <asac> pace_t_zulu: it doesnt provide any .so?
[21:05] <fta> it does
[21:06] <asac> good
[21:06] <pace_t_zulu> fta where?
[21:06] <fta> providing the right flags
[21:06] <asac> thought i ment really just libskia.a
[21:06] <asac> yeah ... you might want to configure --enable-shared or something
[21:06] <pace_t_zulu> fta: ah... i need to look at that
[21:06] <fta> there's a way to ask for shared, even without looking, i'm quite sure
[21:07] <pace_t_zulu> http://code.google.com/p/skia/issues/detail?id=28
[21:07] <pace_t_zulu> the issue has been filed
[21:08] <asac> "must" is a bit exclusive ;)
[21:08] <asac> but ok
[21:09] <fta> asac, pace_t_zulu: you may be interested by http://code.google.com/p/chromium/wiki/LinuxPackaging
[21:10] <fta> and https://wiki.ubuntu.com/Chromium/Packaging
[21:12] <pace_t_zulu> asac: you'll notice that i basically copy pasted from http://code.google.com/p/v8/issues/detail?id=151
[21:13] <asac> yeah
[21:17] <fta> my old bug *sigh*
[21:21] <asac> heh
[21:23] <pace_t_zulu> speaking of bugs...
[21:23] <pace_t_zulu> what's up BUGabundo
[21:23] <fta> the buggy man
[21:26] <BUGabundo> guud evenings
[21:26] <BUGabundo> hey pace_t_zulu fta
[21:29] <pace_t_zulu> BUGabundo: how are you?
[21:29] <BUGabundo> eheh
[21:29] <BUGabundo> just anwsered that on +1
[21:29] <BUGabundo> tired very tired
[21:29] <BUGabundo> long day at work, and gym wasn't all that good
[21:30] <pace_t_zulu> BUGabundo: hard to keep track of you on all these channels ;)
[21:30] <pace_t_zulu> BUGabundo: at least you got to the gym... i commend you on that... i need to be doing more of that myself
[21:44] <asac> fta: do you know of a reason they dont hide internal symbols?
[21:44] <fta> nope
[21:45] <fta> asac, they are no used to being a shared lib :)
[21:45] <fta> -ing
[21:45] <asac> yeah so in that way soname doesnt really make sense i guess ;)
[21:46] <fta> do you guys have that in your dmesg? http://paste.ubuntu.com/219275/
[21:46] <asac> fta: i guess if i fix the hiddenness using build system magic in v8 it wont apply in chromium so one could try?
[21:46] <micahg> asac: BUGabundo filed a bug against ff3.6
[21:47] <BUGabundo> me ?
[21:47] <asac> i mean. maybe chromium does crazy stuff like accessing internal symbols directly et al
[21:47] <fta> asac, what do you mean?
[21:47] <BUGabundo> ONE ? when?
[21:47] <micahg> the full screen one
[21:47] <fta> asac, you won't know until you try
[21:47] <BUGabundo> ha
[21:47] <BUGabundo> its fixed
[21:47] <asac> heh
[21:47] <BUGabundo> and closed upstream
[21:47] <asac> yeah
[21:47] <micahg> should I just close it in Ubuntu?
[21:47] <fta> or look at the chromium tree, in depth
[21:47] <asac> micahg: bugabundo special: before we look at bugs he has to disable all his extensions ;)
[21:48] <BUGabundo> is it still opened here?
[21:48] <micahg> yep
[21:48] <BUGabundo> sorry about that I lost track
[21:48] <fta> micahg, asac, BUGabundo: <fta> do you guys have that in your dmesg? http://paste.ubuntu.com/219275/
[21:48] <BUGabundo> asac: it was on NEW profile
[21:48] <BUGabundo> confirmed here, and upstream
[21:48] <BUGabundo> I know how to test stuff
[21:48] <micahg> bug 395534
[21:48] <BUGabundo> I'm just to lazy to lose all funcionality
[21:48] <asac> fta: what is special about that?
[21:48] <fta> i mean, using an usb mouse (external)
[21:48] <asac> looks like its something normal
[21:49] <micahg> fta: I don't have an intellimouse
[21:49] <fta> it makes my mouse disconnect/reconnect while i'm using it
[21:49] <fta> annoying
[21:49] <asac> no but i get something as well: http://paste.ubuntu.com/219277/
[21:49] <asac> and i dont have a fd0 at all
[21:49] <asac> actually the same error blocks boot for about a minute before mounting disks
[21:49] <fta> it's an old bug
[21:49] <asac> I/O error?
[21:50] <asac> i think i had problems with fd0 like four cycles ago
[21:50] <asac> so i dont think its the same anymore ;
[21:50] <asac> it started in .31
[21:50] <fta> it was ~ last month
[21:50] <asac> fta: what chipset are you using?
[21:51] <fta> in my /etc/modprobe.d/blacklist.conf i've added "blacklist floppy"
[21:51] <asac> heh
[21:51] <asac> that cant be the solution ;)
[21:52] <asac> i think i should file and escalate a bug about it ;)
[21:52] <asac> i think its falloff of some boot speed improvements
[21:52] <asac> just a feeling
[21:52] <fta> bug 384469
[21:53] <asac> well. if device kit starts before my /root partition is mounted then it might be my bug
[21:53] <asac> also its fixed since jun29
[21:53] <asac> even 26
[21:53] <asac> we have jul 15
[21:54] <asac> also i get [  157.405379] Buffer I/O error on device fd0, logical block 0
[21:54] <asac> which are not in the bug reported
[21:56] <fta> asac, http://ubuntuforums.org/showthread.php?t=438923 ?
[21:57] <asac> yeah but this one is new for me ;)
[21:57] <asac> .31
[21:57] <asac> is the event trigger
[22:27] <fta> asac, EruditeHermit: so, about o3d, i've reported the libCl issue to upstream and asked for glsl instead. so far, it's the best they have because they want the same js api on all 3 platforms
[22:28] <fta> but.. they are willing to consider a glsl parser, allowing hlsl cross-compilation toward directx
[22:28] <asac> fta: from what i understood, GLSL works on all three platforms
[22:28] <fta> so it's possible
[22:29] <asac> but wait for EruditeHermit to confirm that
[22:29] <asac> my claim was that they need it for directx ... but he said that directx isnt essentially better
[22:30] <fta> they say the gl drivers in windows are not good enough, and directx doesn't obviously support dlsl
[22:31] <asac> right. that was my line
[22:31] <fta> but the goal is a 100% free solution at the end
[22:31] <fta> asac, so they confirm ;)
[22:31] <asac> maybe i didnt explain properly, but EruditeHermit said there was no real reason ;)
[22:31] <asac> ok good
[22:31] <asac> so what does that mean for us?
[22:31] <fta> build with system libcl for now (it's possible)
[22:31] <asac> what does "willing to consider" mean?
[22:32] <fta> that they will do something like that
[22:32] <asac> will they put resources in it still? or are they just saying: if patch comes we take it
[22:32] <asac> thats at least something
[22:32] <fta> i will file a bug
[22:32] <asac> fta: right. i think if they say they work on it, its worth going the multiverse route
[22:32] <asac> fta: you can upload to multiverse with the .so included
[22:33] <asac> not sure if you want to take the legal liability though if the bug stating that its ok now is wrong ;)
[22:33] <fta> it's another of those 300+MB tarball, yeahhh.
[22:33] <asac> if you want i can try to get a legal opinion (most likely not binding)
[22:33] <asac> fta: well we have nvidia-cg-... package
[22:33] <asac> which is an installer
[22:33] <asac> could be converted to ship the .so and headers? directly
[22:34] <asac> if thats allowed to be redistributed for free (e.g. multiverse requirement)
[22:34] <asac> redistributed and anonymously mirrored i think
[22:34] <asac> must be allowed
[22:34] <fta> asac, apparently, it no longer needs to be an installer, we are allowed to distribute the binaries now
[22:34] <EruditeHermit> hi guys
[22:35] <EruditeHermit> fta: the GLSL drivers on windows from ATI and NVIDIA are as good as on Linux if not better
[22:35] <EruditeHermit> thats not a good reason
[22:35] <EruditeHermit> the intel drivers I can understand
[22:36] <EruditeHermit> intel doesn't have openGL 2.1 support yet in windows
[22:36] <EruditeHermit> or they might not
[22:36] <fta> i'm not the one to be convinced ;)
[22:36] <EruditeHermit> but they will soon if they don't
[22:39] <EruditeHermit> fta: well talk to them and tell them about it.
[22:39] <EruditeHermit> fta: if you have a contact that is
[22:39] <asac> fta: yes. but are you sure that thats right
[22:40] <asac> fta: what i mean, there is a bug saying that thats the case, but i have heard bunch of false claims, so better verify before getting sued
[22:40] <EruditeHermit> fta: the way it stands is this. The GLSL calls are converted to nvidia Cg in the nvidia driver anyway so nvidia supports GLSL on all platforms the same as Cg
[22:40] <asac> (i havent looked at the bug in detail)
[22:40] <EruditeHermit> fta: and ATI just added openGL 3.0 support across all platforms too
[22:41] <asac> fta: if you want to do that i can do a quick check with the ones that usually decide if something is good for multiverse
[22:41] <asac> its not happining that often to me, so i am not sure what the normal procedure is for that ;)
[22:41] <asac> EruditeHermit: but maybe the GLSL transformation is lossy?
[22:42] <asac> GLSL -> Cg
[22:42] <EruditeHermit> asac: I think both nvidia and ati support is pretty good at this point
[22:42] <asac> directx -> Cg might be better ... and Cg (the lib) -> directx -> Cg might be better
[22:42] <asac> EruditeHermit: can you comment on the bug fta posted?
[22:42] <EruditeHermit> where is that?
[22:43] <EruditeHermit> what lp#
[22:43] <asac> at least so they can explain why its better to use cg
[22:43] <asac> and why you are wrong in their opinion ;)
[22:43] <asac> EruditeHermit: its a code.google.com bug i guess
[22:43] <asac> fta: ?
[22:44] <EruditeHermit> games such as ET quake wars use OpenGL and run using GLSL
[22:49] <fta> asac, http://paste.ubuntu.com/219317/
[22:49] <asac> i only understand open-source licenses a bit ;)
[22:50] <EruditeHermit> the license of Cg allows it to be distributed on Linux as long as the binary is not modified
[22:50] <asac> No Rental.  Customer may not rent or lease the SOFTWARE to someone else.
[22:50] <asac> but selling is allowed? ;)
[22:50] <EruditeHermit> https://bugs.launchpad.net/debian/+source/nvidia-cg-toolkit/+bug/284750
[22:51] <asac> i dont know the requirements. maybe we require to not restrict that you can sell it/rent it lease it
[22:52] <EruditeHermit> asac: yes but the exception for Linux overrides that
[22:52] <EruditeHermit> it seems to say you  can distribute it as long as its not modified
[22:53] <EruditeHermit> you can't sell any Linux distro as GPLed code can't be sold
[22:53] <EruditeHermit> you can only sell support for it
[22:54] <EruditeHermit> so why would ubuntu require that you could sell it?
[22:55] <EruditeHermit> rent/lease it?
[22:55] <asac> EruditeHermit: you can sell linux distro
[22:55] <asac> EruditeHermit: you can rent linux distro
[22:55] <EruditeHermit> i don't think so
[22:55] <asac> believe me
[22:55] <asac> you are allowed to sell GPL software
[22:55] <asac> you can take ubuntu if you want and sell a CD for $1000
[22:55] <asac> if you find someone who buys it
[22:55] <EruditeHermit> I don't think so
[22:55] <EruditeHermit> that is BSD license
[22:56] <asac> no
[22:56] <asac> you are wrong
[22:56] <asac> believe me ;)
[22:56] <asac> i am long enough here to know for sure  :)
[22:56] <asac> the point that you confuse is that its not practical
[22:56] <EruditeHermit> A number of businesses use dual-licensing to distribute a GPL version and sell a proprietary license
[22:56] <asac> because as i said they can ask for the code and then are allowed to sell it for free
[22:57] <asac> but you could develop something great in GPL and then sell it for 100K
[22:57] <asac> the customer can then leak it
[22:57] <asac> or sell it again
[22:57] <asac> EruditeHermit: thats a different things
[22:57] <EruditeHermit> thats if you dual licensed it
[22:57] <EruditeHermit> or sold it under the guise of another license
[22:57] <asac> the proprietary license is there so customers can distribute it under non-GPL terms
[22:57] <micahg> asac: you can sell GPLv2
[22:58] <asac> micahg: dont tell that me ;)
[22:58] <micahg> not v3
[22:58] <asac> proof please
[22:59] <asac> that conflicts with the debian free software guidelines
[22:59] <asac> "There is no restriction on distributing, or even selling, the software. "
[22:59] <asac> thats a principle
[22:59] <asac> if thats broken it would mean GPLv3 wouldnt be free for debian
[22:59] <micahg> oh, did they cahnge v3?
[23:00] <asac> change?
[23:00] <EruditeHermit> asac: looks like you are right
[23:00] <asac> i have never heard of any intent to prevent selling GPL software
[23:00] <micahg> According to section 4: You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
[23:00] <EruditeHermit> http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney
[23:00] <asac> thats a main principal of free software licenses
[23:00] <asac> you can sell it you can do whatever you want
[23:00] <asac> but just have to obey some principals
[23:01] <micahg> so why were people going bonkers over gplv3?
[23:01] <asac> that are for copy-left licenses that you have to ship the code
[23:01] <asac> to whoever you give the binary
[23:01] <EruditeHermit> asac: but then how come you can include fglrx nad nvidia drivers in the distro?
[23:01] <asac> micahg: thats a good question. its not really true that all going bonkers
[23:01] <asac> EruditeHermit: read what i initially wrote. i said i am not sure about the multiverse requirements
[23:01] <EruditeHermit> ok
[23:02] <asac> could be that they dont allow restrictions in selling/renting
[23:02] <asac> if you are sure the drivers have that term then thats it
[23:02] <EruditeHermit> yes
[23:02] <asac> micahg: mostly companies dont like GPLv3
[23:02] <EruditeHermit> we can find out easily enough
[23:02] <EruditeHermit> compare the nvidia binary driver license to Cg license
[23:02] <asac> micahg: because there is some patent granting section ... e.g. if you release something covered by any of your own patents
[23:03] <asac> you automatically idemnify the GPLv3 licensee
[23:03] <asac> micahg: others that go bonker do it because they feel like they made a mistake (not for all) in the past: they didnt add the "or later clause" because they mistrusted the freesoftware foundation ;)
[23:04] <asac> and got contributions by lots of people to GPLv2 only
[23:04] <asac> now they cant upgrade the code anymore to GPLv3
[23:04] <asac> so they cannot like it ... otherwise they couldnt sleep anymore ;)
[23:07] <micahg> ok
[23:08] <EruditeHermit> I think its fine
[23:08] <EruditeHermit> I am not a legal expert
[23:08] <EruditeHermit> but multiverse should be fine
[23:08] <EruditeHermit> does Ubuntu have a legal department?
[23:09] <pace_t_zulu> EruditeHermit: probably Canonical
[23:09] <asac> as i said. i can find out whats the next steps are
[23:09] <asac> and i will
[23:09] <EruditeHermit> cool
[23:09] <asac> i just wouldnt do that if there is no end in sight
[23:09] <asac> also i want to see the discussion about opengl to go on upstream
[23:10] <asac> so we need at lesat a bug ;)
[23:20] <fta> http://code.google.com/p/o3d/issues/detail?id=94
[23:22] <asac> fta: thanks. just ask them to replay in the bug what they already explained i guess.
[23:23] <asac> or did you already summarized that in your bug?
[23:25] <fta> sort of, but i asked anyway
[23:45] <fta> asac, where should chromium look for plugins? is env(MOZ_PLUGIN_PATH) -> ~/.mozilla/plugins -> $libdir/plugins -> /usr/lib/mozilla/plugins good?
[23:47] <fta> asac_, <fta> where should chromium look for plugins? is env(MOZ_PLUGIN_PATH) -> ~/.mozilla/plugins -> $libdir/plugins -> /usr/lib/mozilla/plugins good?
[23:47] <asac_> fta: s/libdir/pkglibdir/
[23:47] <asac_> yeah. that line i got
[23:47] <asac_> anything after that?
[23:47] <fta> no
[23:47] <fta> i meant appdir/plugin
[23:48] <asac_> yeah thats pkglibdir
[23:48] <asac_> /usr/lib/gtk-2.0
[23:48] <asac_> for instance
[23:48] <asac_> (if that exists at all)
[23:48] <fta> no /usr/lib/chromium-browser/plugins
[23:48] <asac_> yes thats still $pkglibdir/plugins ;)
[23:49] <asac_> i think we mean the same
[23:49] <fta> no need for a ~/.config/chromium/plugins ?
[23:49] <asac_> ;)
[23:50] <asac_> well. that depends on the chromium developers. they should support the mozilla paths if they want firefox plugins to automatically be picked up
[23:51] <asac_> if they want to do their own dirs like the suggested pkglibdir/plugins then they might also want to consider their own user config dir
[23:51] <asac_> personally i dont like all this and have the feeling it needs a reorganization
[23:52] <asac_> question is if they support all plugins that work in firefox
[23:52] <asac_> my guess is no because there exist xpcom plugins
[23:52] <asac_> question is what happens then
[23:52] <asac_> will it break (i guess not) ... will chromium just refuse to load it etc.
[23:53] <asac_> but i think the selection you suggested makes sense. maybe even drop the .mozilla/plugins location
[23:53] <asac_> there are also .mozilla/random.profile/plugins iirc
[23:53] <asac_> e.g. per profile plugins
[23:55] <fta> hm, not the plan, ok for global legacy dir but those ugly things, bbrrrr
[23:55] <asac_> i only would care about /usr/lib/mozilla/plugins
[23:55] <asac_> because thats where already a bunch of packages ship their stuff anyway