Open Source Meeting/2010-07-15

== Agenda Thursday, 15 July 2010 ==
# Weekly Snowglobe update - Merov Linden
# 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.
# Few topics to retouch:
## 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.
## 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
## If we turn the viewer into a prebuilt/distributable shared library, would this increase chances of support for a 64 bit version?
## (I have lots more for another day... lol)
# 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.
# 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 ===
# After discussion, r3349 was reverted. Do these still need discussion (e.g. for viewer-external)?:
## Changeset 3349 added unit test to llplugin but forgot LL_TESTS, resulting in a build failure in lltut.cpp
## Tries to build pulseaudio when pulseaudio not found.
## Standalone build failure r3349, cmake error on SLPlugin
## Bulding of integration_tests when not needed
## Notifier Issue Since [sldev-commits] r3349
## (Robin Cornelius)
## Make libllcommon shared for SLPlugin + plugins on 1.4
## Ready to commit (Aleric Inglewood)
## idem
# 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]	:	hey boroondas
[13:54]	:	heya
[13:55]	:	Hi
[13:59]	:	Hi.
[14:00]	:	hi Oz
[14:00]	:	Aloha
[14:00]	:	Hi all.... Merov is tied up, so I'm your host this afternoon
[14:01]	:	Hi Oz.
[14:01]	:	Hi Oz. :)
[14:01]	:	Merov reports that the TeamCity integration is going well, and he expects proper builds to start popping out normally agiain soon
[14:02]	:	ossm
[14:02]	:	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]	:	So now I'm really dangerous :-)
[14:03]	:	Hehe
[14:03]	:	Need more OS X dev.
[14:03]	:	only a fool is dangerous =)
[14:03]	:	Merov also says he fixed SNOW-713
[14:04]	:	http://jira.secondlife.com/browse/SNOW-713
[14:04]	:	SG2.1.0(3491) built okay on Windows 7
[14:04]	:	yay!
[14:04]	:	So we got Windows and OSX going... just need revisit to jsonccp and touchup breakpad to complete the setup
[14:04]	:	The installer built too a,d seems to have worked but has some branding issues.
[14:04]	:	on linux
[14:04]	:	I have posted (jiraed) a few build fixes patches for snowglobe 2.1.
[14:04]	:	im running it on windows 7 32-bit just have and odd crash issue
[14:05]	:	I couldn't get the build to finish, yet.
[14:06]	:	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]	:	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]	:	there is a prebuilt breakpad? i didn't dl for me
[14:07]	:	no, but techwolf made an ebuild (gentoo package)
[14:07]	:	yay!
[14:08]	:	techwolf - do we have an issue that spells out what's missing so that we can get it fixed in the prebuilds?
[14:09]	:	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]	:	lmao, nice message wolf
[14:09]	:	lol
[14:10]	:	lol
[14:10]	:	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]	:	oz who would be able to check the crash logs i just sent
[14:11]	:	I can go ahead and make a jira with a patch.
[14:11]	:	It will take me a while. I hope the 64-bit project isn't going on now....LOL
[14:12]	 	checks the agenda
[14:13]	:	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]	:	So there is a prebuilt 32bit breakpad for linux? If so then it may be just a url mistype
[14:13]	:	sorry ... Wolfpup - what crash logs and where did you send them?
[14:13]	:	Oh...there is a MD5sum error on snowglobe 2.1....*looks for it.
[14:14]	:	I don't know Dzonatas .. I thought so, but I'll have to check
[14:14]	:	is that googlemock*?
[14:14]	:	breakpad, you mean?
[14:14]	:	no - it's a crash stack tool
[14:15]	:	i saw it download something called googlemock... so if that is breakpad then it is teh md5sum
[14:15]	:	that is in error
[14:15]	:	yes, there's a prebuilt breakpad bundle for linux32 (otherwise 2.1 won't build)
[14:15]	:	to where ever the crash loger sends them
[14:15]	:	Dzonatas, NOT related.
[14:15]	:	kk
[14:15]	:	Incidentally, it is possible to replace the URL for where the logger sends stacks
[14:16]	:	(don't know how, myself, but it is possible)
[14:16]	:	If you do a svn checkout of google breakpad, it will also do a checkout of gmock and gtest.
[14:16]	:	this is the version im running Snowglobe 2.1.0 (3494) Jul 15 2010 00:32:33 (Snowglobe Test Build)
[14:16]	:	Plus another one I forget.
[14:16]	:	breakpad_client?
[14:17]	:	thanks for the confirming that
[14:17]	:	breakpad_client is one of the executables you get when building building google breakpad
[14:17]	:	hmmm i'll need to dl that when i get back in town tom night or sat
[14:17]	:	I have a patch on jira that finished out the FindGoogleBreakpad.cmake.
[14:17]	:	SNOW-746
[14:17]	:	http://jira.secondlife.com/browse/SNOW-746
[14:18]	:	btw., I think you duplicated some stuff in your _v2 patch
[14:18]	:	yes i had to start with fresh source for the v2 patch to apply properly
[14:18]	:	This is the md5sum error I was talking about. http://pastebin.com/MmreHprh
[14:19]	:	techwolf - are you saying that the cpp files use full path names for the breakpad include files?
[14:19]	:	Yes, let me paste that bit of code....
[14:19]	:	I believe you...
[14:19]	 	sighs
[14:20]	:	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]	:	Oz, i had that file pulled up yesterday, but closed it out. searching for it now.
[14:21]	:	our coding std is rather sparse on topics like that, alas.
[14:21]	:	well, we'll have to fix that
[14:21]	:	Coding_standard#Include_Files
[14:21]	:	(and I don't even know whether internal devs have the same document)
[14:22]	:	=)
[14:23]	:	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]	:	o/
[14:23]	:	#include "client/linux/crash_generation/crash_generation_client.h"
[14:24]	:	However....let me check something.
[14:24]	:	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]	:	*sighs* Can't blame LL for that one. Those include are from upstream. They are in exception_handler.h
[14:25]	 	was afk checking build reviewing chat to catch up
[14:26]	:	oz how would i find out where the crashloger for sg sends the crash log
[14:26]	:	<digression> Does anyone else think that putting all these files into the svn checkout is a problem? </digression>
[14:26]	:	What files are you refereing to Oz?
[14:26]	:	Crash it and sniff the network ? :-)
[14:26]	:	the artwork bundles, etc
[14:27]	:	all the stuff that comes up with '?' in front of it when you do 'svn st'
[14:28]	:	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]	:	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]	 	looks up svn st
[14:29]	:	artwork crosses directories, so svn:external would be tricky
[14:29]	:	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]	:	think being to unpack them is why they are set aside
[14:30]	:	that way you can do "git add" or "svn add" and only pickup source related files
[14:30]	:	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]	:	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]	:	Aleric recently commited an .svnignore to SG1 trunk
[14:31]	:	svn export ... ; git add ... ; tar xzf artwork ; cd indra ; ./develop.py ; cd *rel* ; make
[14:31]	:	for example
[14:31]	:	Oz, on my sytem, ? files are ~ from editors and CmakeCache.txt files.
[14:31]	 	going to grab SG2/SNOW-375 for testing
[14:31]	:	http://jira.secondlife.com/browse/SNOW-375
[14:32]	:	woot!
[14:32]	:	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]	:	yeah
[14:32]	:	I notice the artwork bundle part in cmake was removed in the merge.
[14:32]	:	or have the build look for it outside the svn checkout part of the tree
[14:32]	:	everything that isn't in the repo shouldn't be in the source tree, either
[14:33]	:	mmhmm
[14:33]	:	agreed, Boroondas
[14:33]	:	anyway, just a nit of mine
[14:33]	:	(except your building in-tree, if course. Which with CMake, you actually shouldn't.)
[14:33]	:	probably won't get it changed quickly
[14:34]	:	(develop.py doesn't build in-tree, but running make directly does.)
[14:34]	:	the the actual building folders sould also be outside of the repo tree
[14:34]	:	Oz, another cmake related bug, the unit test will fail if using a cmake out of source tree build.
[14:34]	:	Btw., who would I have to poke to get LL_TESTS fixed for out-of-tree builds?
[14:35]	:	Boroondas... let's hold off on that until Merov gets the TeamCity builds working
[14:35]	:	All Go
[14:35]	:	my linden build folder is pushing 20GB
[14:35]	:	i bet they'll move LL_TESTS as they do move code splits
[14:35]	:	Currentelly, my build does a indra_buld tree.
[14:36]	:	WolfPup, I had to delete a lot of /var/tmp/ builds yesterday. Free up 10Gb.
[14:36]	:	B
[14:36]	:	svn uses lots of space
[14:36]	:	we'll move to hg soon - that will save space
[14:37]	:	i know it makes a .svninformation file for each folder and file
[14:37]	:	avn doesn't keep full history in the checkout
[14:37]	:	hg, does, but it does it more efficiently...
[14:37]	:	my checkout is only 500mb
[14:37]	:	thought those build scripts for the prebuilts would be a good start for a new snowglobe hg repos
[14:37]	:	Hello:)
[14:38]	:	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]	:	That'll depend on the export scripts, I guess.
[14:39]	:	yes, the idea is that the changesets will track cleanly
[14:39]	:	we'll just pull (or push) with hg normally
[14:40]	:	Mr. Oz, can I have some help?
[14:40]	:	Now, that's the scenario for after project code-split is finished, isn't it?
[14:40]	:	I need a Linden to do it...
[14:41]	:	I'm not sure what the relative timing will be ...
[14:41]	:	should know more next week on that
[14:41]	:	IIRC, Merov said code-split will take some longer, so he'll go ahead and port the current export scripts to hg
[14:42]	:	"code-split"?
[14:42]	:	seperating server and client code into different repos
[14:42]	:	that was our thinking, but I'm going to be meeting w/ the code split team next week to get an update
[14:42]	:	ah, good
[14:42]	:	more accurately, separating the code that's common to sim and viewer into a repo of its own
[14:43]	:	that both will use
[14:43]	:	makes sense
[14:44]	:	it'll be a different paradigm internally, yet they already have started it
[14:44]	:	It doesn't sound like that should be hard, but ....
[14:44]	:	that sounds like it could complicate your life if you need to change something in llcommon
[14:44]	:	it means that changes in that repo will be subject to a higher level of scrutiny, for sure
[14:45]	:	aight, thank you for the OH Oz! i am off for now! laterz people
[14:45]	:	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]	:	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]	:	(they have diverged somewhat and must be put back together)
[14:47]	:	but it will all be open source
[14:47]	:	did that answer your question?
[14:48]	:	I think so, but I'm not sure :-P
[14:48]	:	well, then we're even :-))
[14:48]	:	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]	:	originally (pre-open-source), viewer and sim were in the same source tree
[14:49]	:	when the viewer was opened, some code was duplicated
[14:49]	:	the two forks (sim and viewer) diverged somewhat, as code will do
[14:49]	:	The indra cmake txt files has code for both viewer and server.
[14:50]	:	and now we need to un-diverge them so that we can have one version that everyone uses
[14:50]	:	does that help?
[14:50]	:	yes, thanks
[14:51]	:	indra/CmakeFile.txt needs to be split into respective brances. Right now, it contains code for server and viewer.
[14:51]	:	then the process starts all overagain right oz?
[14:51]	:	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]	:	ah, that's what I meant :-)
[14:52]	:	orthogonal woudl imply optimizagonal
[14:52]	:	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]	:	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]	 	notes we dont exactly live in an ideal world >.>
[14:53]	:	"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]	:	:-P
[14:53]	:	SNOW-508
[14:53]	:	http://jira.secondlife.com/browse/SNOW-508
[14:53]	:	Oz: it's got an 'o' and a 'z' in it, must be good.
[14:53]	:	I'm not up on the details yet (and it's all details) - I'm sure it will evolve
[14:53]	 	laughs at morgaine
[14:54]	:	eh, only 6 min left. Back to Agenda?
[14:54]	:	indeed - I have a hard stop (going to my daughters birthday dinner)
[14:54]	:	what's next?
[14:55]	:	ooh your daughter has a bday today oz?
[14:55]	:	=)
[14:55]	:	yup - my first baby is 24 today!
[14:55]	:	Tapas!
[14:56]	:	"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]	:	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]	:	so pass on my wishes for a good bday to her please
[14:56]	:	LOL
[14:56]	:	will do
[14:56]	:	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]	:	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]	:	Cummere: Happy Getting Younger Day!
[14:57]	:	ty morgaine :)
[14:57]	:	It might be a good idea to rename "standalone", though.
[14:57]	:	"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]	:	that name is really confusing for newcomeers
[14:57]	:	agreed Boroondas.
[14:58]	:	not just newcomers
[14:58]	:	standalone is confusing when you still need non-standalone parts =p
[14:58]	:	I can vouche for that - it confuses me
[14:58]	:	standalone to me would be a firmware program in a prom
[14:58]	:	standalone meANS THAT RUNNS APART FROM THE MAIN SYSTEM
[14:58]	:	Suggestions for better terminology are welcome
[14:58]	:	sorry caps loc
[14:59]	:	i originally thought standalone was what you needed to use to distrobute a packaged version of the viewer
[14:59]	:	PREBUILT_LIBS:BOOL
[14:59]	:	LOL, very true. standalone = ~standalone, in this case. Would be good if the terminology could be improved.
[14:59]	:	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]	:	so basically if im understanding that right, you could run the system and load a sim, on your own computer?
[14:59]	:	techworf has the answer "prebuilt_libs"
[15:00]	:	so the non-standalone links all the libs, and standalone does not?
[15:00]	:	l*
[15:00]	:	non-standalone links downloaded libs, standalone links system libs
[15:00]	:	Yep Oz, ie the opposite of what the word suggests.
[15:00]	:	ah... thank you Boroondas
[15:01]	:	we certainly should fix that word
[15:01]	:	Aleric wrote an explanation at Compiling_the_viewer_(Linux)#What_does_.27Standalone.27_mean.3F
[15:01]	:	or SYSTEM_LIB:BOOL
[15:01]	:	seems like its the oposite
[15:01]	:	and just where do you set standalone?
[15:01]	:	In cmake
[15:01]	:	or SYSTEM_LIBS:BOOL
[15:02]	:	Run ccmake and look at the variables. One of them is "STANDALONE".
[15:02]	:	or USE_SYSTEM_LIBS:BOOL
[15:02]	:	I think that one is the best one to use.
[15:02]	:	you mean when running developpy
[15:02]	:	or cmake-gui, if you want a graphical interface ;-)
[15:02]	:	ccmake is the curses UI one.
[15:02]	:	yeah
[15:03]	:	(can also be set by "./develop.py --standalone")
[15:03]	:	Folks... I must go catch a subway.
[15:03]	:	+1 for USE_SYSTEM_LIBS
[15:03]	:	tc oz
[15:03]	:	i always run develop.py in the cmd window then yse vs2005 to build
[15:03]	:	develop.py is legacy interface. That shouldn't be used anymore, but called from cmake.
[15:03]	:	have fun!
[15:03]	:	and happy bday to your duaghter
[15:03]	:	Have fun, Oz!
[15:03]	:	Cya Oz :-)
[15:03]	:	see you Oz
[15:03]	:	tc oz
[15:03]	:	Tell your daughter the internet says Happy Birthday!
[15:04]	:	Thank you, I'll pass that on.
[15:04]	:	i second that stickman
[15:04]	:	!
[15:04]	:	take care!
== Transcript (after Meeting) ==
After the meeting some sticked around for talk/informal discussion:
[15:04]	:	okay so out of those of you here left... how hard would it be to convert the damn ui to something usable?
[15:05]	:	morgain and just how would some one running windows set up the build then useing the cmake gui
[15:05]	:	rember im on windows enviroment
[15:05]	:	Dunno Wolf, I don't do Windows.
[15:05]	:	Cummere... working on it
[15:05]	:	if you're on windows, the cmake-gui should be available in the start menu IIRC.
[15:05]	:	see SNOW-375
[15:06]	:	and that is what the develop.py is for
[15:06]	:	Morgaine, the problem with using "cmake . && make" is that it builds in-tree
[15:06]	:	Wolf: no, cmake was chosen because it's cross-platform. develop.py is legacy on all platforms now.
[15:06]	 	check his build...
[15:06]	:	using "./develop.py build" builds in a different directory (even though it's inside indra)
[15:07]	:	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]	:	so, change it to "mkdir ${BUILD_DIR}; cd ${BUILD_DIR}; cmake ${SOURCE_DIR}; make"
[15:07]	:	cmake can build anywhere I think, although I'm not a cmake expert.
[15:07]	:	i just use develop -G vs80 then start vs2005 and do a build from there
[15:07]	:	ah, that makes sense. cmake confuses me.
[15:08]	:	Mayo, at risk is defending 2.0 the newset corrects the focus issue
[15:08]	:	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]	:	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]	:	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]	:	ive lost untold thousands so far from that
[15:09]	:	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]	:	So my ebuild use viewer_mainifest.py for the install stage. Just like LL uses viewer_manifest.py for build stage.
[15:10]	:	I like your concept dzon allot
[15:10]	:	Thats right, LL install and packages the client durning the _BUILD_ stage.
[15:10]	:	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]	:	i think i best go rebuild the viewer after that svn update the just occured
[15:11]	:	especially since it no longer goes to the trash
[15:12]	:	would it really be that hard to shuffle the inventory offers to someplace ELSE on the screen?
[15:12]	:	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]	:	I'm gonna flee, later!
[15:14]	:	and where to find the code for the mini-nav bar to try and patch into the top bar
[15:14]	:	http://icysphereical.blogspot.com
[15:14]	:	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]	:	nope
[15:14]	:	inventory in its own window
[15:14]	:	more could be done
[15:15]	:	like puttings iventory items on the desktop as files
[15:15]	:	the offers dzonatas is what im talking about
[15:15]	:	I think I'm going to implement a "Teleport spam retaliation" feature. Incoming TP spam automatically gets a TP spam back.
[15:15]	:	=^_^=
[15:15]	:	lol morgain
[15:15]	:	i just make myself appear offline for the random tpers :P
[15:15]	:	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]	:	if both clients have it, you'll get loops
[15:15]	:	Has anyone changed the time to 24 hour clock?
[15:15]	:	backend is there to achieve it... i just got to get for scripts written to get the basics going more
[15:16]	:	Bor: worth trying just to see the loop :P
[15:16]	:	anyways *wonders where the hell she packed her latex and goes offline to go looking for it. "see yall next week"
[15:16]	:	Cya Cummere :-)
[15:16]	:	bye
[15:17]	:	I don't suppose you can send someone a TP offer to some other place, can you?
[15:17]	 	wants to TP spammers to hell
[15:18]	:	send a SLURL instead, then
[15:18]	:	That's not retaliation :-)
[15:19]	:	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]	:	Haha
[15:20]	:	Corsi always wants more people to talk at :P
[15:20]	:	lol
[15:23]	:	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]	:	Did you try the one I just post earlier today to SNOW-375... for r3328?
[15:25]	:	If not, then I'm working on it... =)
[15:27]	 	looks
[15:27]	:	ah, that might be what I've been looking for, thanks :-)
[15:28]	:	That looks interesting =^_^=
[15:28]	:	thanks, and bye =^_^=
[15:28]	:	I add more features to that patch and its sizes gets smaller
[15:28]	:	lol
[15:29]	:	hmm ... looks like you resolved the conflict in indra/newview/llviewermessage.cpp the same way I tried.
[15:30]	:	whitespace is usually the conflict issue
[15:30]	:	well, taht was a non-trivial conflict
[15:30]	:	patch has the -l option to help
[15:31]	:	new code at the same place the patch wanted to add something
[15:31]	:	hey techwold did you see my error on irc?
[15:31]	 	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]	:	i'll get it updated to 3494 or later soon... if you're still awake
[15:32]	:	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]	:	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]	:	oh ya... some chatbars bypass the normal chat route, so i might have to update that since 2.x
[15:33]	:	oh, the joy of LL code ^_^
[15:34]	:	some just echo what you type and other wait for round trip from the sim
[15:35]	:	ic
[15:35]	:	i thought llqtwebkit2 was needed for 2+ viewers
[15:35]	:	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]	:	same error i got
[15:35]	:	Marc just mentioned the same error
[15:36]	:	* dev-libs/llqtwebkit-hg
[15:36]	:	i found this when searching the error http://hg.secondlife.com/llqtwebkit/changeset/e2eaaf8b3e96
[15:37]	:	Torch Mobile?
[15:37]	:	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]	:	Morgaine, have you re-emerge llqtwebkit-hg?
[15:38]	:	Was just about to. But if the ebuild always needs the latest from hg, it ought to fetch it.
[15:39]	:	Morgaine, correct. That why you need to emerge it every month or so.
[15:39]	:	maybe a future version of portage will bring a saner model for life ebuilds
[15:40]	:	THere is no way to tell portage that a certion CVS version number is needed as a depend.
[15:40]	:	but right now, there's not much the ebuild file author can do about it, I guess
[15:40]	:	I know Techwolf, but maybe there *should* be?
[15:42]	:	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]	:	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]	:	Dunno. Emerging something else should clear it, though.
[15:43]	:	But it didn't, hence odd.
[15:44]	:	indeed, never saw that
[15:45]	:	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]	:	Morgaine, if its trying to do that, it mean the last emerge you did was good. You need to start fresh.
[15:46]	:	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]	:	np
[15:47]	:	Poratage now hold the last two failed emerges to allow one to fix with an emerge then resume the failed emerge.
[15:47]	:	ah, cool
[15:47]	:	emerge --resume
[15:47]	:	rm -rf FTW :P
[15:47]	:	:-)
[15:49]	:	There's no problem in IT that can resist to rm -rf! (Whether it'll be solved by that is another question.)
[15:49]	:	ok so i fixed the WOB_SIMULATE_BLANK_HREF_CLICK error but i had to modify /usr/include/llqtwebkit.h
[15:49]	:	ew
[15:49]	:	sudo rm -rf / && ftw!!!
[15:50]	:	because Monroe Linden added something to it
[15:50]	:	i suppose i could have copied 11qtwebkit.h to the include folder
[15:50]	:	it was 1 change though not a big deal
[15:50]	:	ftw: command not found. Have you deleted the corresponding binary?
[15:51]	:	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]	:	lol
[15:51]	:	Actually, that can be used as an optimization technique, too.
[15:52]	:	I remember when a sysadmin thought it would be great to save space by erasing all core dumps
[15:52]	:	yah who needs core dumps
[15:52]	:	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]	:	That was back when a core dump had a smiliar file name to the core object files
[15:53]	:	uh oh
[15:53]	:	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]	:	indeed
[15:54]	:	XML is OSSM
[15:54]	:	they should rename it to OSSM
[15:54]	:	Open Source Software Memory
[15:55]	:	?
[15:55]	:	oh wait... this isn't twitter... we don't know words like ossm here
[16:01]	:	well im off to the beta grid to see if i can catch the end of the beta server OH
[16:01]	:	see you guys later
[16:01]	:	Cya Marc
[16:01]	:	I'm off too, NN all
[16:03]	:	I guess I should get some sleep, too.
[16:03]	:	Good night
[16:03]	 	waves to Techwolf and Dzonatas
 
Generated with SLog Wikifier