Open Source Meeting/2010-07-15

Agenda Thursday, 15 July 2010

1. Weekly Snowglobe update - Merov Linden
2. While the windows prebuild libs scripts has been published ( http://bitbucket.org/brad_linden/build-lindenlib ), the Linux and MAC build scripts are still MIA.
3. Few topics to retouch:
   1. Depth of moving from LL prebuild scripts to pure standalone Snowglobe (meaning true standalone not based on any system library, not cmake's standalone build for linking with systems libs.) Good candidate to keep in bitbucket.
   2. Shared library version of Snowglobe viewer. Would a patch be accepted and maintained if it only allowed this options and exposed a few calls? Maybe -DSHARED:BOOL=TRUE
   3. If we turn the viewer into a prebuilt/distributable shared library, would this increase chances of support for a 64 bit version?
   4. (I have lots more for another day... lol)
4. Unity3D devs make a move in-world, yet they won't support Linux (even though they say multiplatform) -- could LL fill this gap with (hint) distributable shared library that'll eventually be narrowed down to an embeddable renderer. Pretty much already there if all inventory related functions were separated from the scene, which neither one needs really to know about the other in a constant frame loop.
5. Add you topic here!

If we run out of topics before the end of the meeting, we'll triage Snowglobe or Open Source specific Jira Issues from the list below.

Jira Issues

1. After discussion, r3349 was reverted. Do these still need discussion (e.g. for viewer-external)?:
   1. SNOW-649 Changeset 3349 added unit test to llplugin but forgot LL_TESTS, resulting in a build failure in lltut.cpp
   2. SNOW-650 Tries to build pulseaudio when pulseaudio not found.
   3. SNOW-651 Standalone build failure r3349, cmake error on SLPlugin
   4. SNOW-654 Bulding of integration_tests when not needed
   5. SNOW-658 Notifier Issue Since [sldev-commits] r3349
   6. SNOW-619 (Robin Cornelius)
   7. SNOW-713 Make libllcommon shared for SLPlugin + plugins on 1.4
   8. SNOW-596 Ready to commit (Aleric Inglewood)
   9. SNOW-593 idem
2. Unscheduled SNOW issues triage: would be good to go with the community through those and decide for some what we should take immediately (2.0 or 1.4) or later.

If you think an issue warrants a deeper discussion, please add it as topic to one of the agendas above.

Transcript (Meeting)

[13:54]	WolfPup Lowenhar:	hey boroondas
[13:54]	Boroondas Gupte:	heya
[13:55]	Dzonatas Sol:	Hi
[13:59]	Stickman Ingmann:	Hi.
[14:00]	Ashiri Sands:	hi Oz
[14:00]	Dzonatas Sol:	Aloha
[14:00]	Oz Linden:	Hi all.... Merov is tied up, so I'm your host this afternoon
[14:01]	Techwolf Lupindo:	Hi Oz.
[14:01]	Stickman Ingmann:	Hi Oz. :)
[14:01]	Oz Linden:	Merov reports that the TeamCity integration is going well, and he expects proper builds to start popping out normally agiain soon
[14:02]	Dzonatas Sol:	ossm
[14:02]	Oz Linden:	And I have my own good news... Aimee fixed the last problem that was getting in my way on MacOS 10.6 and I was able to build a runnalbe (if not perfectly stable) Snowglobe today
[14:03]	Oz Linden:	So now I'm really dangerous :-)
[14:03]	Ardy Lay:	Hehe
[14:03]	Techwolf Lupindo:	Need more OS X dev.
[14:03]	Youri Ashton:	only a fool is dangerous =)
[14:03]	Oz Linden:	Merov also says he fixed SNOW-713
[14:04]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-713
[14:04]	Ardy Lay:	SG2.1.0(3491) built okay on Windows 7
[14:04]	Oz Linden:	yay!
[14:04]	Dzonatas Sol:	So we got Windows and OSX going... just need revisit to jsonccp and touchup breakpad to complete the setup
[14:04]	Ardy Lay:	The installer built too a,d seems to have worked but has some branding issues.
[14:04]	Dzonatas Sol:	on linux
[14:04]	Techwolf Lupindo:	I have posted (jiraed) a few build fixes patches for snowglobe 2.1.
[14:04]	WolfPup Lowenhar:	im running it on windows 7 32-bit just have and odd crash issue
[14:05]	Boroondas Gupte:	I couldn't get the build to finish, yet.
[14:06]	Techwolf Lupindo:	google breakpad was the hardest as the breakpad install did not include the headers. So I ended up using the same paths as the prebuilt. The #include had paths hardcoded into them, so I had to folow the same paths instead of putting all the headers into /usr/include/google_breakpad.
[14:07]	Oz Linden:	We're going to try to get a regular 64 bit build of the linux prebuilt libs... no time prediction yet, but it's now on the list of active projects
[14:07]	Dzonatas Sol:	there is a prebuilt breakpad? i didn't dl for me
[14:07]	Boroondas Gupte:	no, but techwolf made an ebuild (gentoo package)
[14:07]	Dzonatas Sol:	yay!
[14:08]	Oz Linden:	techwolf - do we have an issue that spells out what's missing so that we can get it fixed in the prebuilds?
[14:09]	Techwolf Lupindo:	Oz, viewer_manifest.py will need a change. right now, it works for standalone due to arch=x86_64 will copy all the files expect the prebuilts that don't exists. The viewermanifest will have to be changed into standalone and "not standalone" instead of currrent i686 and x86-64 now.
[14:09]	Youri Ashton:	lmao, nice message wolf
[14:09]	Marc Adored:	lol
[14:10]	Cummere Mayo:	lol
[14:10]	Oz Linden:	If we don't have an issue for that, can you create one that describes the problem with what you have for a workaround?
[14:11]	WolfPup Lowenhar:	oz who would be able to check the crash logs i just sent
[14:11]	Techwolf Lupindo:	I can go ahead and make a jira with a patch.
[14:11]	Techwolf Lupindo:	It will take me a while. I hope the 64-bit project isn't going on now....LOL
[14:12]	Techwolf Lupindo	checks the agenda
[14:13]	Techwolf Lupindo:	Oz, the second item on the agenda does relate. I need the linux build script used by LL for testing the viewer_manifest.py changes.
[14:13]	Dzonatas Sol:	So there is a prebuilt 32bit breakpad for linux? If so then it may be just a url mistype
[14:13]	Oz Linden:	sorry ... Wolfpup - what crash logs and where did you send them?
[14:13]	Techwolf Lupindo:	Oh...there is a MD5sum error on snowglobe 2.1....*looks for it.
[14:14]	Oz Linden:	I don't know Dzonatas .. I thought so, but I'll have to check
[14:14]	Dzonatas Sol:	is that googlemock*?
[14:14]	Oz Linden:	breakpad, you mean?
[14:14]	Oz Linden:	no - it's a crash stack tool
[14:15]	Dzonatas Sol:	i saw it download something called googlemock... so if that is breakpad then it is teh md5sum
[14:15]	Dzonatas Sol:	that is in error
[14:15]	Thickbrick Sleaford:	yes, there's a prebuilt breakpad bundle for linux32 (otherwise 2.1 won't build)
[14:15]	WolfPup Lowenhar:	to where ever the crash loger sends them
[14:15]	Techwolf Lupindo:	Dzonatas, NOT related.
[14:15]	Dzonatas Sol:	kk
[14:15]	Oz Linden:	Incidentally, it is possible to replace the URL for where the logger sends stacks
[14:16]	Oz Linden:	(don't know how, myself, but it is possible)
[14:16]	Techwolf Lupindo:	If you do a svn checkout of google breakpad, it will also do a checkout of gmock and gtest.
[14:16]	WolfPup Lowenhar:	this is the version im running Snowglobe 2.1.0 (3494) Jul 15 2010 00:32:33 (Snowglobe Test Build)
[14:16]	Techwolf Lupindo:	Plus another one I forget.
[14:16]	Marc Adored:	breakpad_client?
[14:17]	Dzonatas Sol:	thanks for the confirming that
[14:17]	Boroondas Gupte:	breakpad_client is one of the executables you get when building building google breakpad
[14:17]	Cummere Mayo:	hmmm i'll need to dl that when i get back in town tom night or sat
[14:17]	Techwolf Lupindo:	I have a patch on jira that finished out the FindGoogleBreakpad.cmake.
[14:17]	Boroondas Gupte:	SNOW-746
[14:17]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-746
[14:18]	Boroondas Gupte:	btw., I think you duplicated some stuff in your _v2 patch
[14:18]	Marc Adored:	yes i had to start with fresh source for the v2 patch to apply properly
[14:18]	Techwolf Lupindo:	This is the md5sum error I was talking about. http://pastebin.com/MmreHprh
[14:19]	Oz Linden:	techwolf - are you saying that the cpp files use full path names for the breakpad include files?
[14:19]	Techwolf Lupindo:	Yes, let me paste that bit of code....
[14:19]	Oz Linden:	I believe you...
[14:19]	Oz Linden	sighs
[14:20]	Oz Linden:	Can you create a subissue on SNOW-746 to fix the full path usage (poor form, should be a violation of the coding std)
[14:21]	Techwolf Lupindo:	Oz, i had that file pulled up yesterday, but closed it out. searching for it now.
[14:21]	Boroondas Gupte:	our coding std is rather sparse on topics like that, alas.
[14:21]	Oz Linden:	well, we'll have to fix that
[14:21]	Boroondas Gupte:	Coding_standard#Include_Files
[14:21]	Boroondas Gupte:	(and I don't even know whether internal devs have the same document)
[14:22]	Dzonatas Sol:	=)
[14:23]	Oz Linden:	that's rather badly worded, but it says the right thing, so stick that URL into the issue and we'll get that fixed and pushed upstream too
[14:23]	Boroondas Gupte:	o/
[14:23]	Techwolf Lupindo:	#include "client/linux/crash_generation/crash_generation_client.h"
[14:24]	Techwolf Lupindo:	However....let me check something.
[14:24]	Oz Linden:	well, those are relative - we just have to get the bundle to drop them in a good place relative to the existing paths
[14:25]	Techwolf Lupindo:	*sighs* Can't blame LL for that one. Those include are from upstream. They are in exception_handler.h
[14:25]	Nicky Perian	was afk checking build reviewing chat to catch up
[14:26]	WolfPup Lowenhar:	oz how would i find out where the crashloger for sg sends the crash log
[14:26]	Oz Linden:	<digression> Does anyone else think that putting all these files into the svn checkout is a problem? </digression>
[14:26]	Techwolf Lupindo:	What files are you refereing to Oz?
[14:26]	Oz Linden:	Crash it and sniff the network ? :-)
[14:26]	Oz Linden:	the artwork bundles, etc
[14:27]	Oz Linden:	all the stuff that comes up with '?' in front of it when you do 'svn st'
[14:28]	Techwolf Lupindo:	Thanks to google, there is a trick with svn checkout that will also checkout other svns. So a seperate branch in svn for artwork, libs, even source code to the prebuilts could be place in svn outside the snowglobe branch and svn co can be twicked to auto check out those branches.
[14:28]	WolfPup Lowenhar:	speaking of atrwork bundles i had to copy the artwork from my viewer external folder to the sg trunk to clear up som grey (missing) artowrk
[14:28]	Techwolf Lupindo	looks up svn st
[14:29]	Dzonatas Sol:	artwork crosses directories, so svn:external would be tricky
[14:29]	Thickbrick Sleaford:	I think 2.1 (after merov's merge, so not in SG yet) does away with the artwork zipfile (though not sure if the solution is better or worse)
[14:29]	Dzonatas Sol:	think being to unpack them is why they are set aside
[14:30]	Dzonatas Sol:	that way you can do "git add" or "svn add" and only pickup source related files
[14:30]	Techwolf Lupindo:	Oh, files that show up in svn st are temp files and should never be commited unless you forgot to add a file when creating a .h or .cpp or other source file.
[14:31]	Oz Linden:	Maybe I"m old school - I think essentially anything that shows up as a ? in svn st is a bug in the process
[14:31]	Boroondas Gupte:	Aleric recently commited an .svnignore to SG1 trunk
[14:31]	Dzonatas Sol:	svn export ... ; git add ... ; tar xzf artwork ; cd indra ; ./develop.py ; cd *rel* ; make
[14:31]	Dzonatas Sol:	for example
[14:31]	Techwolf Lupindo:	Oz, on my sytem, ? files are ~ from editors and CmakeCache.txt files.
[14:31]	Nicky Perian	going to grab SG2/SNOW-375 for testing
[14:31]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-375
[14:32]	Dzonatas Sol:	woot!
[14:32]	Thickbrick Sleaford:	Ithink the right solution is to have cmake or viewer_manifest.py handle copying the artwork etc. from someplace external to indra/ into the staging area.
[14:32]	Boroondas Gupte:	yeah
[14:32]	Techwolf Lupindo:	I notice the artwork bundle part in cmake was removed in the merge.
[14:32]	Oz Linden:	or have the build look for it outside the svn checkout part of the tree
[14:32]	Boroondas Gupte:	everything that isn't in the repo shouldn't be in the source tree, either
[14:33]	Dzonatas Sol:	mmhmm
[14:33]	Oz Linden:	agreed, Boroondas
[14:33]	Oz Linden:	anyway, just a nit of mine
[14:33]	Boroondas Gupte:	(except your building in-tree, if course. Which with CMake, you actually shouldn't.)
[14:33]	Oz Linden:	probably won't get it changed quickly
[14:34]	Thickbrick Sleaford:	(develop.py doesn't build in-tree, but running make directly does.)
[14:34]	WolfPup Lowenhar:	the the actual building folders sould also be outside of the repo tree
[14:34]	Techwolf Lupindo:	Oz, another cmake related bug, the unit test will fail if using a cmake out of source tree build.
[14:34]	Boroondas Gupte:	Btw., who would I have to poke to get LL_TESTS fixed for out-of-tree builds?
[14:35]	Oz Linden:	Boroondas... let's hold off on that until Merov gets the TeamCity builds working
[14:35]	Flight Band:	All Go
[14:35]	WolfPup Lowenhar:	my linden build folder is pushing 20GB
[14:35]	Dzonatas Sol:	i bet they'll move LL_TESTS as they do move code splits
[14:35]	Techwolf Lupindo:	Currentelly, my build does a indra_buld tree.
[14:36]	Techwolf Lupindo:	WolfPup, I had to delete a lot of /var/tmp/ builds yesterday. Free up 10Gb.
[14:36]	Techwolf Lupindo:	B
[14:36]	Dzonatas Sol:	svn uses lots of space
[14:36]	Oz Linden:	we'll move to hg soon - that will save space
[14:37]	WolfPup Lowenhar:	i know it makes a .svninformation file for each folder and file
[14:37]	Thickbrick Sleaford:	avn doesn't keep full history in the checkout
[14:37]	Thickbrick Sleaford:	hg, does, but it does it more efficiently...
[14:37]	Marc Adored:	my checkout is only 500mb
[14:37]	Dzonatas Sol:	thought those build scripts for the prebuilts would be a good start for a new snowglobe hg repos
[14:37]	OneAndNtgElseMetalls Albatros:	Hello:)
[14:38]	Techwolf Lupindo:	Oz, when that happen, will each change be one change per change? Right now, svn change set has about 100 hg change sets. Make it very hard to follow any bugfixes and changes that could affect any TPV patches.
[14:38]	Boroondas Gupte:	That'll depend on the export scripts, I guess.
[14:39]	Oz Linden:	yes, the idea is that the changesets will track cleanly
[14:39]	Oz Linden:	we'll just pull (or push) with hg normally
[14:40]	OneAndNtgElseMetalls Albatros:	Mr. Oz, can I have some help?
[14:40]	Boroondas Gupte:	Now, that's the scenario for after project code-split is finished, isn't it?
[14:40]	OneAndNtgElseMetalls Albatros:	I need a Linden to do it...
[14:41]	Oz Linden:	I'm not sure what the relative timing will be ...
[14:41]	Oz Linden:	should know more next week on that
[14:41]	Boroondas Gupte:	IIRC, Merov said code-split will take some longer, so he'll go ahead and port the current export scripts to hg
[14:42]	Thickbrick Sleaford:	"code-split"?
[14:42]	Boroondas Gupte:	seperating server and client code into different repos
[14:42]	Oz Linden:	that was our thinking, but I'm going to be meeting w/ the code split team next week to get an update
[14:42]	Boroondas Gupte:	ah, good
[14:42]	Oz Linden:	more accurately, separating the code that's common to sim and viewer into a repo of its own
[14:43]	Oz Linden:	that both will use
[14:43]	Boroondas Gupte:	makes sense
[14:44]	Dzonatas Sol:	it'll be a different paradigm internally, yet they already have started it
[14:44]	Oz Linden:	It doesn't sound like that should be hard, but ....
[14:44]	Thickbrick Sleaford:	that sounds like it could complicate your life if you need to change something in llcommon
[14:44]	Oz Linden:	it means that changes in that repo will be subject to a higher level of scrutiny, for sure
[14:45]	Youri Ashton:	aight, thank you for the OH Oz! i am off for now! laterz people
[14:45]	Boroondas Gupte:	though, would the common and client repos be free of content that LL isn't allowed to share with us? Otherwise we still can't to unfiltered cloning.
[14:47]	Oz Linden:	sorry... I didn't follow that... it will mostly be code that is in the viewer source, merged with the versions of the same code that the sim is using
[14:47]	Oz Linden:	(they have diverged somewhat and must be put back together)
[14:47]	Oz Linden:	but it will all be open source
[14:47]	Oz Linden:	did that answer your question?
[14:48]	Boroondas Gupte:	I think so, but I'm not sure :-P
[14:48]	Oz Linden:	well, then we're even :-))
[14:48]	Boroondas Gupte:	I had the impression the current export process is not only for filtering out server-only stuff, but also libraries that LL has licenced but has no right to distribute.
[14:48]	Oz Linden:	originally (pre-open-source), viewer and sim were in the same source tree
[14:49]	Oz Linden:	when the viewer was opened, some code was duplicated
[14:49]	Oz Linden:	the two forks (sim and viewer) diverged somewhat, as code will do
[14:49]	Techwolf Lupindo:	The indra cmake txt files has code for both viewer and server.
[14:50]	Oz Linden:	and now we need to un-diverge them so that we can have one version that everyone uses
[14:50]	Oz Linden:	does that help?
[14:50]	Boroondas Gupte:	yes, thanks
[14:51]	Techwolf Lupindo:	indra/CmakeFile.txt needs to be split into respective brances. Right now, it contains code for server and viewer.
[14:51]	Cummere Mayo:	then the process starts all overagain right oz?
[14:51]	Oz Linden:	the code-split is really orthogonal to the export problem (which does include not publishing stuff that is used now in the LInden viewer that isn't open)
[14:51]	Boroondas Gupte:	ah, that's what I meant :-)
[14:52]	Dzonatas Sol:	orthogonal woudl imply optimizagonal
[14:52]	Oz Linden:	well, ideally no, Cummere - since the sim team will actually be building from those same sources, and both will modify the same repo
[14:52]	Techwolf Lupindo:	Oz, there is also the problem of incuding some non-ll headers, glh_liener.h and so on. Its been a ping pong of where those files are placed.
[14:52]	Cummere Mayo	notes we dont exactly live in an ideal world >.>
[14:53]	Oz Linden:	"optimizagonal" - good word... not sure what it means, but it sure sounds good (or would if I could figure out how to pronounce it)
[14:53]	Boroondas Gupte:	:-P
[14:53]	Techwolf Lupindo:	SNOW-508
[14:53]	JIRA-helper:	http://jira.secondlife.com/browse/SNOW-508
[14:53]	Morgaine Dinova:	Oz: it's got an 'o' and a 'z' in it, must be good.
[14:53]	Oz Linden:	I'm not up on the details yet (and it's all details) - I'm sure it will evolve
[14:53]	Cummere Mayo	laughs at morgaine
[14:54]	Boroondas Gupte:	eh, only 6 min left. Back to Agenda?
[14:54]	Oz Linden:	indeed - I have a hard stop (going to my daughters birthday dinner)
[14:54]	Oz Linden:	what's next?
[14:55]	Cummere Mayo:	ooh your daughter has a bday today oz?
[14:55]	Dzonatas Sol:	=)
[14:55]	Oz Linden:	yup - my first baby is 24 today!
[14:55]	Oz Linden:	Tapas!
[14:56]	Ardy Lay:	"optimizagonal", they design, fabrication and laying of non-rectangular pavers or tiles in interlocking patterns that reduce the surface area of grout lines." (I just made that up.)
[14:56]	Cummere Mayo:	hehe well she shares a great day to have a bday on. my roomie turns 31 today and um im not telling how young im turning
[14:56]	Cummere Mayo:	so pass on my wishes for a good bday to her please
[14:56]	Oz Linden:	LOL
[14:56]	Oz Linden:	will do
[14:56]	Dzonatas Sol:	5 min left to think about turning the viewer into a shared lib... would a patch be maintained in the repos if i post one
[14:56]	Thickbrick Sleaford:	item 3 on the agenda seems to me to stem from misunderstanding what "standalone" does - if I understand it correctly, it basically suggest to recreate standalone by another name.
[14:56]	Morgaine Dinova:	Cummere: Happy Getting Younger Day!
[14:57]	Cummere Mayo:	ty morgaine :)
[14:57]	Boroondas Gupte:	It might be a good idea to rename "standalone", though.
[14:57]	Oz Linden:	"turning the viewer into a shared lib" ... I'd want to see some more detail on what that means, but yes, it sounds interesting as long as the patch doesn't break anything else
[14:57]	Boroondas Gupte:	that name is really confusing for newcomeers
[14:57]	Thickbrick Sleaford:	agreed Boroondas.
[14:58]	Cummere Mayo:	not just newcomers
[14:58]	Dzonatas Sol:	standalone is confusing when you still need non-standalone parts =p
[14:58]	Oz Linden:	I can vouche for that - it confuses me
[14:58]	Nicky Perian:	standalone to me would be a firmware program in a prom
[14:58]	WolfPup Lowenhar:	standalone meANS THAT RUNNS APART FROM THE MAIN SYSTEM
[14:58]	Oz Linden:	Suggestions for better terminology are welcome
[14:58]	WolfPup Lowenhar:	sorry caps loc
[14:59]	Marc Adored:	i originally thought standalone was what you needed to use to distrobute a packaged version of the viewer
[14:59]	Techwolf Lupindo:	PREBUILT_LIBS:BOOL
[14:59]	Morgaine Dinova:	LOL, very true. standalone = ~standalone, in this case. Would be good if the terminology could be improved.
[14:59]	Boroondas Gupte:	I *think* it strems from being able to do a networkless build (i.e. standalone during compiletime). But the result, is the inverse of standalone, as it's depending on system libs.
[14:59]	Cummere Mayo:	so basically if im understanding that right, you could run the system and load a sim, on your own computer?
[14:59]	Dzonatas Sol:	techworf has the answer "prebuilt_libs"
[15:00]	Oz Linden:	so the non-standalone links all the libs, and standalone does not?
[15:00]	Dzonatas Sol:	l*
[15:00]	Boroondas Gupte:	non-standalone links downloaded libs, standalone links system libs
[15:00]	Morgaine Dinova:	Yep Oz, ie the opposite of what the word suggests.
[15:00]	Oz Linden:	ah... thank you Boroondas
[15:01]	Oz Linden:	we certainly should fix that word
[15:01]	Boroondas Gupte:	Aleric wrote an explanation at Compiling_the_viewer_(Linux)#What_does_.27Standalone.27_mean.3F
[15:01]	Techwolf Lupindo:	or SYSTEM_LIB:BOOL
[15:01]	Marc Adored:	seems like its the oposite
[15:01]	WolfPup Lowenhar:	and just where do you set standalone?
[15:01]	Morgaine Dinova:	In cmake
[15:01]	Techwolf Lupindo:	or SYSTEM_LIBS:BOOL
[15:02]	Morgaine Dinova:	Run ccmake and look at the variables. One of them is "STANDALONE".
[15:02]	Techwolf Lupindo:	or USE_SYSTEM_LIBS:BOOL
[15:02]	Techwolf Lupindo:	I think that one is the best one to use.
[15:02]	WolfPup Lowenhar:	you mean when running developpy
[15:02]	Boroondas Gupte:	or cmake-gui, if you want a graphical interface ;-)
[15:02]	Morgaine Dinova:	ccmake is the curses UI one.
[15:02]	Boroondas Gupte:	yeah
[15:03]	Thickbrick Sleaford:	(can also be set by "./develop.py --standalone")
[15:03]	Oz Linden:	Folks... I must go catch a subway.
[15:03]	Thickbrick Sleaford:	+1 for USE_SYSTEM_LIBS
[15:03]	Cummere Mayo:	tc oz
[15:03]	WolfPup Lowenhar:	i always run develop.py in the cmd window then yse vs2005 to build
[15:03]	Morgaine Dinova:	develop.py is legacy interface. That shouldn't be used anymore, but called from cmake.
[15:03]	Boroondas Gupte:	have fun!
[15:03]	Cummere Mayo:	and happy bday to your duaghter
[15:03]	Stickman Ingmann:	Have fun, Oz!
[15:03]	Morgaine Dinova:	Cya Oz :-)
[15:03]	Thickbrick Sleaford:	see you Oz
[15:03]	WolfPup Lowenhar:	tc oz
[15:03]	Stickman Ingmann:	Tell your daughter the internet says Happy Birthday!
[15:04]	Oz Linden:	Thank you, I'll pass that on.
[15:04]	WolfPup Lowenhar:	i second that stickman
[15:04]	Boroondas Gupte:	!
[15:04]	Dzonatas Sol:	take care!

Transcript (after Meeting)

After the meeting some sticked around for talk/informal discussion:

[15:04]	Cummere Mayo:	okay so out of those of you here left... how hard would it be to convert the damn ui to something usable?
[15:05]	WolfPup Lowenhar:	morgain and just how would some one running windows set up the build then useing the cmake gui
[15:05]	WolfPup Lowenhar:	rember im on windows enviroment
[15:05]	Morgaine Dinova:	Dunno Wolf, I don't do Windows.
[15:05]	Dzonatas Sol:	Cummere... working on it
[15:05]	Boroondas Gupte:	if you're on windows, the cmake-gui should be available in the start menu IIRC.
[15:05]	Dzonatas Sol:	see SNOW-375
[15:06]	WolfPup Lowenhar:	and that is what the develop.py is for
[15:06]	Thickbrick Sleaford:	Morgaine, the problem with using "cmake . && make" is that it builds in-tree
[15:06]	Morgaine Dinova:	Wolf: no, cmake was chosen because it's cross-platform. develop.py is legacy on all platforms now.
[15:06]	Techwolf Lupindo	check his build...
[15:06]	Thickbrick Sleaford:	using "./develop.py build" builds in a different directory (even though it's inside indra)
[15:07]	Cummere Mayo:	dzon, id settle for soemthing closer to the 1.4 or even, jsut if focus wasnt stolen so you didnt wind up declining things by accident all the damn time
[15:07]	Boroondas Gupte:	so, change it to "mkdir ${BUILD_DIR}; cd ${BUILD_DIR}; cmake ${SOURCE_DIR}; make"
[15:07]	Morgaine Dinova:	cmake can build anywhere I think, although I'm not a cmake expert.
[15:07]	WolfPup Lowenhar:	i just use develop -G vs80 then start vs2005 and do a build from there
[15:07]	Thickbrick Sleaford:	ah, that makes sense. cmake confuses me.
[15:08]	Nicky Perian:	Mayo, at risk is defending 2.0 the newset corrects the focus issue
[15:08]	Boroondas Gupte:	CMake *is* confusing when you're used to other build systems, but don't judge it by how it's used by LL (which is often very un-CMake-ish, thus even more confusing.)
[15:08]	Techwolf Lupindo:	My ebuilds cmake eclass uses cmake for the configure stage, then make for the build stage and "make install" for the install stage. Note that the SL cleint does not have a working "make install".
[15:09]	Cummere Mayo:	not for me it doesnt. when im trying to select okay on a notification and i get an inventory offer, the inventory offer still steals focus, meaning i acidently decline
[15:09]	Cummere Mayo:	ive lost untold thousands so far from that
[15:09]	Dzonatas Sol:	Cummere, SNOW-375 is agnostic, but the look & feel of 1.4 is what i used for a basic UI... since people are familiar with it
[15:09]	Techwolf Lupindo:	So my ebuild use viewer_mainifest.py for the install stage. Just like LL uses viewer_manifest.py for build stage.
[15:10]	Cummere Mayo:	I like your concept dzon allot
[15:10]	Techwolf Lupindo:	Thats right, LL install and packages the client durning the _BUILD_ stage.
[15:10]	Cummere Mayo:	but between here and there, i and allot of sg users i know would really like the notifications changes so that you cant accidently decline stuff anymore
[15:11]	WolfPup Lowenhar:	i think i best go rebuild the viewer after that svn update the just occured
[15:11]	Cummere Mayo:	especially since it no longer goes to the trash
[15:12]	Cummere Mayo:	would it really be that hard to shuffle the inventory offers to someplace ELSE on the screen?
[15:12]	WolfPup Lowenhar:	just wish i knew where in the heck to edit so that there was less space between the buy button in the top bar and the time there
[15:13]	Stickman Ingmann:	I'm gonna flee, later!
[15:14]	WolfPup Lowenhar:	and where to find the code for the mini-nav bar to try and patch into the top bar
[15:14]	Dzonatas Sol:	http://icysphereical.blogspot.com
[15:14]	Cummere Mayo:	okay well tiem to find my RL outfit thats similar to what my avatar is wearing. Gonna drive to pheonix and go clubbing to night
[15:14]	Dzonatas Sol:	nope
[15:14]	Dzonatas Sol:	inventory in its own window
[15:14]	Dzonatas Sol:	more could be done
[15:15]	Dzonatas Sol:	like puttings iventory items on the desktop as files
[15:15]	Cummere Mayo:	the offers dzonatas is what im talking about
[15:15]	Morgaine Dinova:	I think I'm going to implement a "Teleport spam retaliation" feature. Incoming TP spam automatically gets a TP spam back.
[15:15]	Ashiri Sands:	=^_^=
[15:15]	WolfPup Lowenhar:	lol morgain
[15:15]	Marc Adored:	i just make myself appear offline for the random tpers :P
[15:15]	Cummere Mayo:	where a object sends you something. that notification pops up the same place as the other notifications. and the okay button for notifciations is the same spot the decline button is
[15:15]	Boroondas Gupte:	if both clients have it, you'll get loops
[15:15]	Ashiri Sands:	Has anyone changed the time to 24 hour clock?
[15:15]	Dzonatas Sol:	backend is there to achieve it... i just got to get for scripts written to get the basics going more
[15:16]	Morgaine Dinova:	Bor: worth trying just to see the loop :P
[15:16]	Cummere Mayo:	anyways *wonders where the hell she packed her latex and goes offline to go looking for it. "see yall next week"
[15:16]	Morgaine Dinova:	Cya Cummere :-)
[15:16]	Ashiri Sands:	bye
[15:17]	Morgaine Dinova:	I don't suppose you can send someone a TP offer to some other place, can you?
[15:17]	Morgaine Dinova	wants to TP spammers to hell
[15:18]	Boroondas Gupte:	send a SLURL instead, then
[15:18]	Morgaine Dinova:	That's not retaliation :-)
[15:19]	Boroondas Gupte:	But I don't know if the residents at http://maps.secondlife.com/secondlife/Hell/128/128/2 would appreciate if you send spammers there, anyway.
[15:19]	Morgaine Dinova:	Haha
[15:20]	Morgaine Dinova:	Corsi always wants more people to talk at :P
[15:20]	Ashiri Sands:	lol
[15:23]	Boroondas Gupte:	Dzon, do you have a version of the SNOW-375 patch for recent SG2 trunk revisions? I'm unsure how to correctly merge it with the changes introduced by the translation.
[15:24]	Dzonatas Sol:	Did you try the one I just post earlier today to SNOW-375... for r3328?
[15:25]	Dzonatas Sol:	If not, then I'm working on it... =)
[15:27]	Boroondas Gupte	looks
[15:27]	Boroondas Gupte:	ah, that might be what I've been looking for, thanks :-)
[15:28]	Ashiri Sands:	That looks interesting =^_^=
[15:28]	Ashiri Sands:	thanks, and bye =^_^=
[15:28]	Dzonatas Sol:	I add more features to that patch and its sizes gets smaller
[15:28]	Dzonatas Sol:	lol
[15:29]	Boroondas Gupte:	hmm ... looks like you resolved the conflict in indra/newview/llviewermessage.cpp the same way I tried.
[15:30]	Dzonatas Sol:	whitespace is usually the conflict issue
[15:30]	Boroondas Gupte:	well, taht was a non-trivial conflict
[15:30]	Dzonatas Sol:	patch has the -l option to help
[15:31]	Boroondas Gupte:	new code at the same place the patch wanted to add something
[15:31]	Marc Adored:	hey techwold did you see my error on irc?
[15:31]	Marc Adored	dia/Storage/src/snowglobe/trunk/indra/media_plugins/webkit/media_plugin_webkit.cpp:325: error: ‘WOB_SIMULATE_BLANK_HREF_CLICK’ is not a member of ‘LLQtWebKit’
[15:31]	Dzonatas Sol:	i'll get it updated to 3494 or later soon... if you're still awake
[15:32]	Boroondas Gupte:	but anyway ... so this bug I'm seeing must be from something else: you won't see your own text in external IM windows when you've sent it via the internal IM window. (For public chat, your own text seems to display no matter what, though)
[15:33]	Techwolf Lupindo:	llqtwebkit tip will work with 2.1. Will work with 1.4 with an update to one file that a drop from 2.0
[15:33]	Dzonatas Sol:	oh ya... some chatbars bypass the normal chat route, so i might have to update that since 2.x
[15:33]	Boroondas Gupte:	oh, the joy of LL code ^_^
[15:34]	Dzonatas Sol:	some just echo what you type and other wait for round trip from the sim
[15:35]	Boroondas Gupte:	ic
[15:35]	Marc Adored:	i thought llqtwebkit2 was needed for 2+ viewers
[15:35]	Morgaine Dinova:	Hey Tech, your games-simulation/snowglobe2-svn build failed to compile at 43%: --> /var/tmp/portage/games-simulation/snowglobe2-svn-2/work/linden/indra/media_plugins/webkit/media_plugin_webkit.cpp:325: error: 'WOB_SIMULATE_BLANK_HREF_CLICK' is not a member of 'LLQtWebKit'
[15:35]	Marc Adored:	same error i got
[15:35]	Boroondas Gupte:	Marc just mentioned the same error
[15:36]	Morgaine Dinova:	* dev-libs/llqtwebkit-hg
[15:36]	Marc Adored:	i found this when searching the error http://hg.secondlife.com/llqtwebkit/changeset/e2eaaf8b3e96
[15:37]	Morgaine Dinova:	Torch Mobile?
[15:37]	Boroondas Gupte:	dev-libs/llqtwebkit-hg is a live ebuild. You might have to rebuild it to fetch the latest hg revision, even when the ebuild file (and thus the ebuild version) hasn't changed.
[15:37]	Techwolf Lupindo:	Morgaine, have you re-emerge llqtwebkit-hg?
[15:38]	Morgaine Dinova:	Was just about to. But if the ebuild always needs the latest from hg, it ought to fetch it.
[15:39]	Techwolf Lupindo:	Morgaine, correct. That why you need to emerge it every month or so.
[15:39]	Boroondas Gupte:	maybe a future version of portage will bring a saner model for life ebuilds
[15:40]	Techwolf Lupindo:	THere is no way to tell portage that a certion CVS version number is needed as a depend.
[15:40]	Boroondas Gupte:	but right now, there's not much the ebuild file author can do about it, I guess
[15:40]	Boroondas Gupte:	I know Techwolf, but maybe there *should* be?
[15:42]	Boroondas Gupte:	Then again, stable versions of stable software usually features a non-life ebuild, too (if not only), so the ones using life ebuilds should be those who're ready to get their hands dirty, anyway.
[15:42]	Morgaine Dinova:	That's odd, an emerge --resume tried to continue something I did many days ago. What's the proper way to clear out old stuff, short of deleting the old in /var/tmp manually?
[15:43]	Boroondas Gupte:	Dunno. Emerging something else should clear it, though.
[15:43]	Morgaine Dinova:	But it didn't, hence odd.
[15:44]	Boroondas Gupte:	indeed, never saw that
[15:45]	Morgaine Dinova:	Old build trees always remain in /var/tmp, until the ebuild completes successfully. But never seen --resume go back to antique junk before.
[15:45]	Techwolf Lupindo:	Morgaine, if its trying to do that, it mean the last emerge you did was good. You need to start fresh.
[15:46]	Dzonatas Sol:	Boroondas, i'm going to double inspect that patch applied to r3494... so i'm not gonna upload it in the next hour
[15:47]	Boroondas Gupte:	np
[15:47]	Techwolf Lupindo:	Poratage now hold the last two failed emerges to allow one to fix with an emerge then resume the failed emerge.
[15:47]	Boroondas Gupte:	ah, cool
[15:47]	Morgaine Dinova:	emerge --resume
[15:47]	Morgaine Dinova:	rm -rf FTW :P
[15:47]	Boroondas Gupte:	:-)
[15:49]	Boroondas Gupte:	There's no problem in IT that can resist to rm -rf! (Whether it'll be solved by that is another question.)
[15:49]	Marc Adored:	ok so i fixed the WOB_SIMULATE_BLANK_HREF_CLICK error but i had to modify /usr/include/llqtwebkit.h
[15:49]	Boroondas Gupte:	ew
[15:49]	Dzonatas Sol:	sudo rm -rf / && ftw!!!
[15:50]	Marc Adored:	because Monroe Linden added something to it
[15:50]	Marc Adored:	i suppose i could have copied 11qtwebkit.h to the include folder
[15:50]	Marc Adored:	it was 1 change though not a big deal
[15:50]	Boroondas Gupte:	ftw: command not found. Have you deleted the corresponding binary?
[15:51]	Morgaine Dinova:	Bor: a friend of mine who was a sysadmin that didn't know C, tackled all compile errors by deleting the offending line. Oddly, it seemed to work for him.
[15:51]	Marc Adored:	lol
[15:51]	Boroondas Gupte:	Actually, that can be used as an optimization technique, too.
[15:52]	Dzonatas Sol:	I remember when a sysadmin thought it would be great to save space by erasing all core dumps
[15:52]	Marc Adored:	yah who needs core dumps
[15:52]	Boroondas Gupte:	Delete random source lines (or assambler commands) and see if the program still does what it should. Often it'll do it slightly faster.
[15:52]	Dzonatas Sol:	That was back when a core dump had a smiliar file name to the core object files
[15:53]	Boroondas Gupte:	uh oh
[15:53]	Morgaine Dinova:	LOL, from Groupies: [15:51] CodeWarrior Carling: In random dev discussion: "Java is a DSL for converting large XML files into Stack Traces"
[15:53]	Boroondas Gupte:	indeed
[15:54]	Dzonatas Sol:	XML is OSSM
[15:54]	Dzonatas Sol:	they should rename it to OSSM
[15:54]	Dzonatas Sol:	Open Source Software Memory
[15:55]	Boroondas Gupte:	?
[15:55]	Dzonatas Sol:	oh wait... this isn't twitter... we don't know words like ossm here
[16:01]	Marc Adored:	well im off to the beta grid to see if i can catch the end of the beta server OH
[16:01]	Marc Adored:	see you guys later
[16:01]	Morgaine Dinova:	Cya Marc
[16:01]	Morgaine Dinova:	I'm off too, NN all
[16:03]	Boroondas Gupte:	I guess I should get some sleep, too.
[16:03]	Boroondas Gupte:	Good night
[16:03]	Boroondas Gupte	waves to Techwolf and Dzonatas

Generated with SLog Wikifier