Open Source Meeting/2010-05-25

Transcript

[14:00]	Nicky Gilderoy:	hello everyone
[14:00]	Techwolf Lupindo:	Hmmm...where is Oz...*snifs the air*
[14:00]	Techwolf Lupindo:	Hi merovl
[14:00]	Thickbrick Sleaford:	hello poople
[14:00]	Thickbrick Sleaford:	people
[14:00]	Thickbrick Sleaford:	hmm
[14:01]	Merov Linden:	I see that someone wrote an agenda
[14:01]	Merov Linden:	http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
[14:01]	Techwolf Lupindo:	/me tries to look insoent...
[14:01]	Techwolf Lupindo:	:-)
[14:01]	Merov Linden:	"insolent"?
[14:02]	Boroondas Gupte:	"insolvent"
[14:02]	Techwolf Lupindo:	Innocence
[14:03]	Techwolf Lupindo:	can't spell today
[14:03]	Merov Linden:	o "innocent" ... that's *very* different :)
[14:03]	Techwolf Lupindo:	/me chuckles
[14:03]	Thickbrick Sleaford:	"Why do you have sug big eyeglasses, Techwolf?"
[14:03]	Merov Linden:	see where typos can lead you... :)
[14:03]	Techwolf Lupindo:	"The better to see you with my dear". :-D
[14:03]	Merov Linden:	k, I can't seem to find Oz on IRC
[14:04]	Merov Linden:	so, let's start
[14:04]	Merov Linden:	My status: 100% of my time on making SG2.0 better by porting things
[14:05]	Techwolf Lupindo:	Thickbrick, in one day, I missed seeing some text three times....it was time to get my eyes check.
[14:05]	Merov Linden:	thanks *a lot* to those who contributed patches and updated the matrix
[14:05]	Techwolf Lupindo:	/me msiels
[14:05]	Merov Linden:	I haven't reviewed/committed them yet but that hasn't gone unnoticed :)
[14:05]	Techwolf Lupindo:	I threw 10 or so your way Merov.
[14:06]	Merov Linden:	I'm trying to get all the small and easy one that no ne wants out so we have a smaller and cleaner view
[14:06]	Merov Linden:	going fine so far
[14:06]	Merov Linden:	I saw Techwolf, thanks a lot
[14:06]	Merov Linden:	this helps
[14:07]	Merov Linden:	I added 2 "big" tasks to the list though:
[14:07]	Merov Linden:	- Easybuild
[14:07]	Techwolf Lupindo:	Also still listed is the ones for 2.0.2. You might want to see if those can get commited to viewer-public so we don't have to re-do them again when the next big merge comes up.
[14:07]	Ardy Lay:	What's Easybuild?
[14:07]	Merov Linden:	- lltexturefetch/cache qudit
[14:07]	Merov Linden:	*audit*
[14:07]	Merov Linden:	/me fishes the JIRA records
[14:08]	Ardy Lay:	/me searches WIKI
[14:08]	Techwolf Lupindo:	easybuild was a project that imporve the downloading of prebuilds. I *think* what happen was a lot of code got moved around and cmake handle more of that function.
[14:08]	Boroondas Gupte:	easy build is a some-time-ago attemp to cmakeify the build process
[14:08]	Merov Linden:	- Easybuild: SNOW-674
[14:08]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-674 [#SNOW-674] Merge Easybuild back into Snowglobe 2.0
[14:09]	Techwolf Lupindo:	easybuild was merged in all code...or so I thought?:?????
[14:09]	Boroondas Gupte:	yeah
[14:09]	Merov Linden:	- texture audit: SNOW-688
[14:09]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-688 [#SNOW-688] Port of lltexturefetch changes to SG 2.0 : Stability and performance of texture fetching
[14:10]	Merov Linden:	so, on easybuild: the goal was to get rid of develop.py as much as possible, making it possible to build the viewer using cmake only
[14:10]	Merov Linden:	we never really got there but develop.py wasn't doing much
[14:11]	Merov Linden:	that was merged into Snowglobe in July last year and, internally, more was done by some folks but the project sort of stalled
[14:11]	Merov Linden:	so it never made it into viewer which is a shame
[14:11]	Techwolf Lupindo:	I don't use devolopy.py on my builds. To get rid of it, just need to improve cmake with sane defaults and let the LL build system pass any customazing parameters.
[14:12]	Merov Linden:	Techwolf: even to build SG2.0?
[14:12]	Techwolf Lupindo:	Yes.
[14:12]	Boroondas Gupte:	I don't use develop.py, either
[14:12]	Techwolf Lupindo:	I build 2.0 without it.
[14:12]	Merov Linden:	you just use cmake to create the project then and build?
[14:12]	Thickbrick Sleaford:	I thought running cmake caused it to run develop.py first
[14:12]	Boroondas Gupte:	yep ... after patching a bit
[14:12]	Techwolf Lupindo:	Yep. cmake configure then "make"
[14:13]	Techwolf Lupindo:	The "make" part is a cmake build marcro on gentoo.
[14:13]	Merov Linden:	(all the dependencies are coded in CMakeLists.txt files)
[14:13]	Merov Linden:	OK, I see
[14:13]	Merov Linden:	just configure then make
[14:14]	Techwolf Lupindo:	I still patch about 1 to 6 build issues however. Most are related to upgraded lib packages.
[14:14]	Merov Linden:	well, no one internally looked too deeply into easybuild so I took over the task of making an assessment and, eventually, port it internally in viewer-public
[14:14]	Boroondas Gupte:	but I think those have to be patched whether one's using develop.py or not
[14:14]	Merov Linden:	so it can make its way to viewer-external and SG2.x
[14:15]	Techwolf Lupindo:	Correct boroondas, they are build issues with all version of the code.
[14:15]	Merov Linden:	I'd like to have al those build issues fixes in the trunk
[14:16]	Merov Linden:	so that I don't stomp all over them *again* when doing that easybuild work
[14:16]	Boroondas Gupte:	well, the patches are on jira ...
[14:16]	Merov Linden:	one question to you guys though: do you think it's a good use of my time?
[14:16]	Techwolf Lupindo:	My "cmake configure" is: cmake -C /var/tmp/portage/games-simulation/emerald-1.3.2.2006/temp/gentoo_common_config.cmake -DCMAKE_INSTALL_PREFIX=/usr -DSTANDALONE:BOOL=TRUE -DAPP_SHARE_DIR:STRING=/usr/share/games/emerald -DAPP_BINARY_DIR:STRING=/usr/share/games/emerald/bin -DOPENAL=ON -DGSTREAMER=ON -DDBUSGLIB=ON -DUSE_GOOGLE_PERFTOOLS=OFF -DFMOD:BOOL=FALSE -DGCC_DISABLE_FATAL_WARNINGS:BOOL=TRUE -DPACKAGE:BOOL=FALSE -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_DO_STRIP=OFF -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/tmp/portage/games-simulation/emerald-1.3.2.2006/temp/gentoo_rules.cmake /var/tmp/portage/games-simulation/emerald-1.3.2.2006/work/linden/indra
[14:16]	Techwolf Lupindo:	Overkill yes, but this is withen a build system.
[14:16]	Merov Linden:	i.e. will it make building that much easier? (that's my overall goal)
[14:16]	Boroondas Gupte:	Well, I don't know what of easybuild might be missing ....
[14:17]	Merov Linden:	doesn't sound like a great endorsment of that effort ;)
[14:17]	Thickbrick Sleaford:	whenever I look at the build system I get quickly lost, so no opinion if easybuild help or not, but generaly I think making building easier is a very high priority.
[14:17]	Merov Linden:	well, looks like a good idea to assess where it stands then
[14:18]	Boroondas Gupte:	what I'd like in the future (not a pressing issue) is keep the source tree completely pristine, i.e. unpack artwork and prebuild stuff to somewhere else
[14:18]	Ardy Lay:	Heh, "develop.py -G vc80 configure" isn't too painful.
[14:18]	Merov Linden:	Boroondas +1 on this
[14:18]	Techwolf Lupindo:	One just need to look at devolop.py and make sure the cmake will default to that when not using devolop.py
[14:19]	Thickbrick Sleaford:	well, the prebuilt stuff isn't in indra/
[14:19]	Thickbrick Sleaford:	but the artwork is
[14:19]	Merov Linden:	the prebuilt stuff being: the 3rd party libs?
[14:19]	Boroondas Gupte:	yeah
[14:19]	Boroondas Gupte:	whatever the build system downlaods
[14:19]	Techwolf Lupindo:	The artwork needs to stay in unfortully if they ever going to get cpack working.
[14:19]	Merov Linden:	that's what the autobuild project is all about (building the 3rd party libs in a clean open way)
[14:20]	Techwolf Lupindo:	Really?!?!! That what I've been thinking about for the past week.
[14:20]	Thickbrick Sleaford:	well, artwork can be unpacked to a folder outside of indra and copied at the packaging stage into packaged/
[14:20]	Boroondas Gupte:	yeah, something like that
[14:20]	Merov Linden:	I told about it some meetings ago Techwolf
[14:20]	Techwolf Lupindo:	One project to put forth was to down the third party software source code and build it as part of th ebuild process.
[14:21]	Boroondas Gupte:	the idea is, that I can run `hg status` in the source tree (or equivalent svn command until we use mercurial) and see only my uncommited changes, nothing else.
[14:21]	Aleric Inglewood:	(hi)
[14:21]	Techwolf Lupindo:	Would make testing upgraded liberies a lot easer. No more having to wait for LL to put out upgraded prebuild libs.
[14:21]	Merov Linden:	Techwolf: last time I told you about it, you said you don't care as you want to use the OS libs
[14:22]	Merov Linden:	I'm sort of confused now
[14:22]	Ardy Lay:	/me quickly drowns.
[14:22]	Boroondas Gupte:	(hi Aleric)
[14:23]	Merov Linden:	/me was on the phone for a sec...
[14:23]	Merov Linden:	k, back up a bit
[14:23]	Techwolf Lupindo:	Umm....If I did comment on something like that, I think it was in reference to the current build system. Right now, standalone works for Linux. However, for windows builders, having to auto-build the liberieas would be nice for them.
[14:24]	Techwolf Lupindo:	s/to/it
[14:24]	Merov Linden:	ah, OK, I understand now
[14:24]	Ardy Lay:	WHy you want Windows users to build the libraries?
[14:24]	Merov Linden:	We want to give them choice
[14:24]	Techwolf Lupindo:	Upgraded liberies can be injected into the build.
[14:25]	Merov Linden:	so that if something goes wrong (new compiler, new OS, old one we don't support) they have a standing chance of building a working viewer
[14:25]	Techwolf Lupindo:	Current way. Build liberies seperate, then patch some cmake files to pick it up and not download the one from LL.
[14:26]	Merov Linden:	right now it's a little "hail mary" if you don't use our prebuild libs :/
[14:26]	Ardy Lay:	Hmm.. I was thinking kibrary debugging but, okay.
[14:26]	Merov Linden:	for no good reason really
[14:26]	Merov Linden:	lib debugging also, absolutely
[14:26]	Thickbrick Sleaford:	one example of why this is useful is the dependancy on VS2005 (boost issues)
[14:26]	Techwolf Lupindo:	OH....and have a FULL debugging setup. No half debug where the sl bin is debug and the lib are not.
[14:26]	Ardy Lay:	Yeah
[14:27]	Merov Linden:	+1
[14:27]	Techwolf Lupindo:	Merov, better crash reports too as a side effect.
[14:27]	Merov Linden:	yeap, that's all quite a bit of work to get there with autobuild
[14:27]	Ardy Lay:	Just worried about losing ability to use Express Editions
[14:28]	Merov Linden:	I threw easybuild in there as well and wondering if I'm making things mor complicated...
[14:28]	Boroondas Gupte:	Well, before we can answer that, we have to know what if easybuild didn't already make it into 2.0 (if anything)
[14:29]	Boroondas Gupte:	s/if/of/
[14:29]	Calcite Serendipity:	From someone who just built the viewer for the first time my sticking points were poor/missing instructions and illustrations
[14:29]	Ardy Lay:	(Programming isn't my life, it's an interest.)
[14:29]	Techwolf Lupindo:	Well, I think on that jira, more info on what easybuild was about and what it current status is. Right now, all I know about easybuild is I though it was one open source congrubitro doing some changes to the build system. What they was I wasn't sure. Now I'me learning it was a outsource project of LL that got half-way done. Am I correct?
[14:30]	Merov Linden:	k, looks like me digging through this Easybuild story and get a clean picture is useful to us
[14:30]	Merov Linden:	I'll propose a path then and we'll decide what to do
[14:30]	Boroondas Gupte:	sounds good
[14:30]	Thickbrick Sleaford:	Techwold, I think they outsourced it to Kitware (the makers or CMake)
[14:31]	Merov Linden:	next new "big" task is SNOW-688
[14:31]	Techwolf Lupindo:	Merov. +1. Find out what easybuild was and its history.
[14:31]	Boroondas Gupte:	Ardy, why/how would autobuild break compatibility to Express editions?
[14:31]	RINOBIT Footman:	hi all
[14:31]	Merov Linden:	SNOW-688
[14:31]	Techwolf Lupindo:	Oh, its way past 10 minutes after the hour. *marks Oz tardy*
[14:31]	Merov Linden:	where's that bot when you need it...
[14:31]	Techwolf Lupindo:	:-)
[14:31]	Ardy Lay:	I don't know what is creating the solution files I get after running develop.py.
[14:32]	Thickbrick Sleaford:	http://jira.secondlife.com/browse/SNOW-668
[14:32]	JIRA-helper:	[#SNOW-668] Port of SNOW-352 to SG 2.0 : Add optional double-click teleport
[14:32]	Merov Linden:	Ardy: it's cmake
[14:32]	Ardy Lay:	OKay then. :-)
[14:32]	Merov Linden:	called by develop.py
[14:33]	Merov Linden:	k, SNOW-688 is hinging on what we discussed at this meeting last week
[14:33]	Techwolf Lupindo:	I think that was big advantage of cmake. With one file, all required files to build are generated. I don't think automake could do that.
[14:33]	Merov Linden:	I really looked at all this code (mostly Aleric's) and some was co-opted by Bao, some not and it's a mess :/
[14:34]	Thickbrick Sleaford:	oh, I pasted the link to the wrong one...
[14:34]	Merov Linden:	I'm wary of porting wholesale as I said last week but I really feel this threaded code needs analysis
[14:35]	Techwolf Lupindo:	http://jira.secondlife.com/browse/SNOW-688
[14:35]	JIRA-helper:	[#SNOW-688] Port of lltexturefetch changes to SG 2.0 : Stability and performance of texture fetching
[14:35]	Techwolf Lupindo:	That one needs a C/C++ guru.
[14:36]	Thickbrick Sleaford:	Merov, did some of it fail a review by Bao, or it's just that he never got to it?
[14:36]	Merov Linden:	Thickbrick: some he did diferently, some he disagreed with, some he was wory of taking late (?) in the project
[14:37]	Merov Linden:	but in the end, as Aleric said on list, there's a very ugly way in how we handle threads and mutexes and that was the cause of countless bugs
[14:37]	Merov Linden:	really bad ones...
[14:37]	Thickbrick Sleaford:	agreed
[14:38]	Aleric Inglewood:	You can hire me if you want :/
[14:38]	Techwolf Lupindo:	Pay Aleric to redo/refactor that code. Would fix numerious bugs and resednet compaints.
[14:38]	Techwolf Lupindo:	resendents
[14:38]	Merov Linden:	I guess I can't answer that question on the spot :)
[14:39]	Thickbrick Sleaford:	Imprudence took the http-texture code from snowglobe 1.3 for their 1.3 release, and they are having a lot of bugs in it that we didn't see in Snowglobe - I'm guessing they are just tickling this fragile code different than us
[14:39]	Techwolf Lupindo:	Inprudunce is using 1.23 code base.
[14:40]	Merov Linden:	I think that's the crux of it: tinkering with that code without doing a complete analysis is crazy, it's too fragile...
[14:40]	Merov Linden:	we know that all too well
[14:40]	Thickbrick Sleaford:	Techwolf yes, but with http-texture pipeline ported in to it
[14:41]	Merov Linden:	k, well, I note the interest hinging on proper incentives
[14:41]	Merov Linden:	/me is not sure how to say that
[14:42]	Merov Linden:	we discussed it last Thursday and it's not off the table,
[14:42]	Techwolf Lupindo:	Its call "incentive to redo work i've allready done"
[14:42]	Merov Linden:	I'd say it's fair considering how hard it is...
[14:43]	Merov Linden:	Oz working/thinking on this so I think we should move on
[14:44]	Merov Linden:	time check: I've a hard stop @ 3pm today guys (child duty)
[14:44]	Merov Linden:	so forgive me in advance if I bail out a tad fast
[14:44]	Thickbrick Sleaford:	about the texture pipeline patches, can you get Bao to comment on the relevant jiras (or the central 2.0 jira) on what he thinks needs to be done differently?
[14:45]	Thickbrick Sleaford:	considering the goal here is to have something that can be taken upstream
[14:45]	Merov Linden:	Thickbrick: yes, +1, good idera
[14:45]	Merov Linden:	*idea*
[14:46]	Merov Linden:	llqtwebkit: change in API
[14:46]	Thickbrick Sleaford:	that's what tags are for
[14:46]	Merov Linden:	hmm, I didn't noticed that change
[14:47]	Merov Linden:	but, anyway, a plugin system should be resilient to API versioning
[14:47]	Techwolf Lupindo:	Its commented out for now....but look at the commet.
[14:47]	Latif Khalifa:	http texture code is b0rked in 1.3 anyway
[14:47]	Merov Linden:	also, I'm not in favor of putting plugin codes in the same repo as the viewer as the goal of a plugin architecture is to decorrelate things
[14:47]	Latif Khalifa:	very crashy
[14:48]	Latif Khalifa:	and since 1.40 sim is going to enable them, it's not going to be fun for sg 1.x
[14:48]	Techwolf Lupindo:	All the other media plugins are in the source. Just llqtwebkit issn't.
[14:49]	Merov Linden:	it's because it's under gitorous
[14:49]	Merov Linden:	/me needs to fish for the URL
[14:49]	Techwolf Lupindo:	http://hg.secondlife.com/llqtwebkit/
[14:49]	Thickbrick Sleaford:	actually, the problem is that the webkit plugin *is* in the source, but not the llqtwebkit library it links against
[14:49]	Boroondas Gupte:	if you want to decorrelate them, you have to keep the API stable. Seperate repositories don't help too much there, when upstream can easily change them in-sync.
[14:50]	Thickbrick Sleaford:	(or maybe I misunderstood Techwolf?)
[14:50]	Techwolf Lupindo:	Thick, nope. you put it better in words then I did.
[14:50]	Thickbrick Sleaford:	is it a change in the plugin api, or change in the llqtwebkit api?
[14:51]	Merov Linden:	I do not know Thickbrick, I need to ask
[14:51]	Merov Linden:	I don't know what this "WOB" is about
[14:52]	Techwolf Lupindo:	Right now, llqtwebkit has no versiing, so a cmake check for what version the llqtwebit lib is and set some defines is not possaible now.
[14:52]	Boroondas Gupte:	I guess "WOB" is short for "indow open behavior"
[14:52]	Boroondas Gupte:	*window
[14:53]	Thickbrick Sleaford:	This?: 5 days monroe_linden monroe_linden Added a way to handle javascript window.open() reasonably.
[14:53]	Merov Linden:	I see that much in the "setWin<etc>" name
[14:53]	Merov Linden:	but what it covers, don't know
[14:53]	Techwolf Lupindo:	Eeek....sounds like making it popup compatiable. Watch otu for the ads. :-)
[14:54]	Merov Linden:	k, I'll investigate but please, do ask on opensource-dev!
[14:54]	Merov Linden:	so that I don't play the role of the stupid messenger... (getting shot in the process...)
[14:55]	Techwolf Lupindo:	/me grins
[14:55]	Merov Linden:	thanks :)
[14:55]	Techwolf Lupindo:	But this _is_ your role. Liasion for LL and open source folk.
[14:55]	Techwolf Lupindo:	:-)
[14:55]	Latif Khalifa:	lol
[14:56]	Merov Linden:	it's my role to help the communication flow *freely*, not to be the bottleneck for comm...
[14:56]	Boroondas Gupte:	:-P
[14:56]	Merov Linden:	I'd happily stay out of the comm flow as much as possible...
[14:57]	Merov Linden:	so that people talk directly with each other (that scales, me in the middle doesn't)
[14:57]	Techwolf Lupindo:	/me ndos
[14:57]	Techwolf Lupindo:	did we skipped "Source_contributions wiki page needs to be updated."?
[14:58]	Merov Linden:	k, I've a couple of minutes left :/
[14:58]	Merov Linden:	can we tab the rest for Thursday?
[14:58]	Techwolf Lupindo:	Won't be here thursday.
[14:58]	Techwolf Lupindo:	I won't that is.
[14:58]	Ardy Lay:	Lots of "corrupted assets" crashing viewers over the weekend. Including SG1.4.0 and V2.0.1 - SNOW-493 might help
[14:58]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-493 [#SNOW-493] LLDataPackerBinaryBuffer::unpack*() check for buffer overflow, then read buffer regardless
[14:59]	Techwolf Lupindo:	I'll be on my way to Huntsville, AL.
[15:01]	Ardy Lay:	I am using that patch in SG1.4.0 now. Had to edit it some.
[15:01]	Ardy Lay:	Don't think I have been exposed to the bad assets sence I rebuilt though.
[15:01]	Latif Khalifa:	animations?
[15:02]	Ardy Lay:	I may try exposing myself. I have logs.
[15:02]	Boroondas Gupte:	There was a call for stability patches/issues on opensource-dev, might want to mention it there.
[15:02]	Ardy Lay:	I think so, yes.
[15:02]	Thickbrick Sleaford:	I think Robin's method of testing this is idling at Ahern
[15:02]	Ardy Lay:	Ahern is a good place for such exposure.
[15:02]	Ardy Lay:	They usually hit Ahern then Lusk.
[15:03]	Boroondas Gupte:	Help Island Public, works too, I heard.
[15:03]	Techwolf Lupindo:	Whats Ahern?
[15:03]	Boroondas Gupte:	A welcome area Region.
[15:03]	Ardy Lay:	When they hit Lusk they do get lots of abuse reports and then suspended.
[15:03]	Boroondas Gupte:	one of the oldest still in use
[15:04]	Techwolf Lupindo:	I think merov bailed.
[15:04]	Latif Khalifa:	ahern/morris
[15:04]	Thickbrick Sleaford:	he did say he had a hard time limit
[15:04]	Latif Khalifa:	around that area
[15:05]	Thickbrick Sleaford:	Aleric, do you think the lack of the fix for SNOW-103 could be causing this crash in Imprudence? http://redmine.imprudenceviewer.org/issues/293
[15:05]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-103 [#SNOW-103] Assertion 'bytes_read == sizeof(Entry)' fails
[15:05]	Techwolf Lupindo:	Would like if those crashfixes patches include a llinfo UUID in there somewhere so an admin can AR them.

Generated with SLog Wikifier