[opensource-dev] autobuild on linux
on Ubuntu ... i've installed python-boto (sudo apt-get install python-boto) [also tried getting boto source direct and installing with 'sudo python setup.py install' after pulling with 'svn checkout http://boto.googlecode.com/svn/trunk'] i've installed llbase (hg clone https://bitbucket.org/lindenlab/llbase) and installed with 'sudo python setup.py install' i've re-installed autobuild (hg clone https://bitbucket.org/lindenlab/autobuild) and installed with 'sudo python setup.py install' when i run autobuild configure -c OpenSourceRelWithDebInfo I still get 'autobuild.common.AutobuildError: invalid 'pathcheck' setting for 'boto' looking in common.py, the pathcheck for boto is 'lib/python2.5/boto' Anyone have any hints to help me get further? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/ --- (Updated Feb. 19, 2011, 9:08 a.m.) Review request for Viewer. Summary (updated) --- When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't send a AgentSetAppearance message. This can happen without the user being aware, leaving the avatar looking good on their screen, but not updated to the same outfit on other people's screens. The avatar will remain in that state until the user does something that causes a rebake (manually rebake or change outfit.) The solution here is to retry the upload after a small delay. What this diff changes: when a full-res upload fails, retry to upload it after a 5s delay, up to 5 times (in case the cap is available, last attempt is via the old asset store.) Also, some clearer log messages. This implements an old *FIX: comment: // *FIX: retry upload after n seconds, asset server could be busy This isn't needed for low res uploads, because they don't block subsequent full-res uploads (mNeedsUpload isn't set to FALSE in LLTexLayerSetBuffer::doUpload in low-res uploads.) This addresses bug VWR-24889. http://jira.secondlife.com/browse/VWR-24889 Diffs (updated) - indra/newview/llassetuploadresponders.h 379da6bd50a5 indra/newview/llassetuploadresponders.cpp 379da6bd50a5 indra/newview/lltexlayer.h 379da6bd50a5 indra/newview/lltexlayer.cpp 379da6bd50a5 Diff: http://codereview.secondlife.com/r/152/diff Testing --- Attempted outfit changes using a problematic connection (not recently used outfits to avoid using cached bakes). Looked for "Baked full res texture upload for failed" log messages, observed the subsequent retries and successful upload for that region. Observed that eventually the fully-baked avatar is visible to other users. Thanks, Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.
> On Feb. 17, 2011, 1:59 p.m., Boroondas Gupte wrote: > > Both comments are addressed in the new diff. - Thickbrick --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/152/#review375 --- On Feb. 19, 2011, 9:08 a.m., Thickbrick Sleaford wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/152/ > --- > > (Updated Feb. 19, 2011, 9:08 a.m.) > > > Review request for Viewer. > > > Summary > --- > > When a bake upload fails, the viewer doesn't retry it, and subsequently > doesn't send a AgentSetAppearance message. This can happen without the user > being aware, leaving the avatar looking good on their screen, but not updated > to the same outfit on other people's screens. The avatar will remain in that > state until the user does something that causes a rebake (manually rebake or > change outfit.) The solution here is to retry the upload after a small delay. > > What this diff changes: when a full-res upload fails, retry to upload it > after a 5s delay, up to 5 times (in case the cap is available, last attempt > is via the old asset store.) Also, some clearer log messages. This implements > an old *FIX: comment: > // *FIX: retry upload after n seconds, asset server could be busy > > This isn't needed for low res uploads, because they don't block subsequent > full-res uploads (mNeedsUpload isn't set to FALSE in > LLTexLayerSetBuffer::doUpload in low-res uploads.) > > > This addresses bug VWR-24889. > http://jira.secondlife.com/browse/VWR-24889 > > > Diffs > - > > indra/newview/llassetuploadresponders.h 379da6bd50a5 > indra/newview/llassetuploadresponders.cpp 379da6bd50a5 > indra/newview/lltexlayer.h 379da6bd50a5 > indra/newview/lltexlayer.cpp 379da6bd50a5 > > Diff: http://codereview.secondlife.com/r/152/diff > > > Testing > --- > > Attempted outfit changes using a problematic connection (not recently used > outfits to avoid using cached bakes). Looked for "Baked full res texture > upload for failed" log messages, observed the subsequent > retries and successful upload for that region. Observed that eventually the > fully-baked avatar is visible to other users. > > > Thanks, > > Thickbrick > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: Nearby chat history is displaying both Display Names and user.names when the Display Name is not changed from default.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/153/ --- Review request for Viewer. Summary --- https://jira.secondlife.com/browse/VWR-24917 I have been finding the redundent display of functionally equivalent names in nearby chat history and IM history quite tiresome. Simple proposal: If the resident's Display Name is at the default then do not display their user.name. https://bitbucket.org/ArdyLay/viewer-development-vwr-24917 Change is to: LLAvatarName::getCompleteName I find the following Callers: LLAvatarActions::requestFriendshipDialog LLAvatarActions::startIM LLAvatarActions::startCall LLIMModel::LLIMSession LLIMModel::logToFile LLPostponedNotification::onAvatarNameCache LLUrlEntryAgent::onAvatarNameCache LLUrlEntryAgent::getLabel LLUrlEntryAgentCompleteName::getName // Callback for name resolution of a god/estate message llviewermessage.cpp(2149): args["NAME"] = av_name.getCompleteName(); llviewermessage.cpp(2154): chat.mText = av_name.getCompleteName() + ": " + message; static void on_avatar_name_cache_toast ... llimview.cpp(108): args["FROM"] = av_name.getCompleteName(); Some of these make me wonder if this change will cause some defects and should be implimented as a seperate function. This addresses bug VWR-24917. http://jira.secondlife.com/browse/VWR-24917 Diffs - doc/contributions.txt c10d5e37db1e indra/llcommon/llavatarname.cpp c10d5e37db1e Diff: http://codereview.secondlife.com/r/153/diff Testing --- I have been using this trivial change and have shared it with a friend, via bitbucket. We have both built the viewer on Windows 7 and find the resulting reduction in redundent text in chat and IM history on screen to be very helpful. Thanks, ardy.lay ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] autobuild on linux
> > when i run autobuild configure -c OpenSourceRelWithDebInfo I still get > 'autobuild.common.AutobuildError: invalid 'pathcheck' setting for 'boto' > looking in common.py, the pathcheck for boto is 'lib/python2.5/boto' > > Anyone have any hints to help me get further? > As normal user try the following ( cd "/var/tmp/`whoami`/install.cache" && wget http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boto-1.9b-common-20100414.tar.bz2 ) Then try again. Looks like boto is a prereg that needs to be downloaded, but for downloading you need boto. Or something like this :) autobuild should really be happy if there is a system wide boto and use this. For now you need to populate install.cache with the package, than autobuild will unpack it for you and continue from there. Cheers, Nicky ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux build error: missing binary operator before token "(" (was: Hacking up to Visual Studio 2010 ...)
> [19:13:30]: LogScan (1s)
> [19:13:30]: [LogScan] from /usr/include/c++/4.1.3/cmath:53,
> [19:13:30]: [LogScan] from
> /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/llcommon/linden_common.h:48,
> [19:13:30]: [LogScan] from
> /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/newview/tests/lldateutil_test.cpp:26:
> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:28:18: error: missing
> binary operator before token "("
> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:30:20: error: missing
> binary operator before token "("
>
> With "build" in the second command instead of "configure", I'm getting the
> same error, though not just for /usr/include/bits/huge_val.h but many more
> system headers, too.
>
Tried it today, getting that too. Huge slew of errors.
Even though this looks intimidating, the reason is really simple.
In OZ's version of json there is a file features.h in
../include/json/. Metaphorical
speaking there he laid the bomb.
It is then trigged in cmake/JsonCpp.cmake and newview/CMakeList.txt
JsonCpp.cmake sets JSONCPP_INCLUDE_DIRS to ${LIBS_PREBUILD_DIR)/include/json.
newview/CMakeList.txt adds JSONCPP_INCLUDE_DIRS to the system include dirs.
Now the the problem with gcc is, that adding include dirs with -I
makes them be searched
before the system include dirs.
And there our little bomb goes off. Because now the compiler findes
the features.h file
first in ../include/json. When it fact it needs the system one from
/usr/include/features.h.
One solution might be to use the -I- switch or -iquote for new gcc
versions. But lucky
enough there is a trivially simple fix, just use
${LIBS_PREBUILD_DIR)/include for
JSONCPP_INCLUDE_DIRS.
I attached a patch that does just this. Standalone builds might need
some extra hackery,
I did not try one of those yet.
Cheers,
Nicky
# HG changeset patch
# User Nicky
# Date 1298143658 -3600
# Node ID ab363082f660e186ce0bfef8bf455b6d932c2663
# Parent 07163388fcb99b292843648c6256946cc622976f
Do not add /include/json as an include director. Instead use /include.
Otherwise include/json/features.h will mask /usr/include/features.
diff -r 07163388fcb9 -r ab363082f660 indra/cmake/JsonCpp.cmake
--- a/indra/cmake/JsonCpp.cmake Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/cmake/JsonCpp.cmake Sat Feb 19 20:27:38 2011 +0100
@@ -18,5 +18,5 @@
elseif (LINUX)
set(JSONCPP_LIBRARIES libjson_linux-gcc-4.3.2_libmt)
endif (WINDOWS)
- set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include/json)
+ set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include)
endif (STANDALONE)
diff -r 07163388fcb9 -r ab363082f660 indra/newview/lltranslate.cpp
--- a/indra/newview/lltranslate.cpp Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/newview/lltranslate.cpp Sat Feb 19 20:27:38 2011 +0100
@@ -33,7 +33,7 @@
#include "llversioninfo.h"
#include "llviewercontrol.h"
-#include "reader.h"
+#include "json/reader.h"
// These two are concatenated with the language specifiers to form a complete Google Translate URL
const char* LLTranslate::m_GoogleURL = "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=";;
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Autobuild still requires cmake?
If the goal is to have a building tool why does it still require cmake? -- --- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. --- --- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Autobuild still requires cmake?
> If the goal is to have a building tool why does it still require cmake? See Oz's original post. Short version "Autobuild is a framework for maintaining and building libraries and other programs. It acts as director providing a common interface to build and package libraries and programs, but it is not a build system like make or cmake (it uses them "under the covers")." > -- > --- > This email is a private and confidential communication. Any use of email may > be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > --- > --- -- Ima Mechanique ima.mechanique(at)blueyonder.co.uk ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Wild idea on building an install platform
As a sidebar to the whole autobuild system it would be cool if somebody could download a program and then verify that they have a Valid install platform (bonus points if it could also download the missing parts (i suppose that you could only pop the webpage for MS VStudio). -- Robert L Martin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux build error: missing binary operator before token "("
On 02/19/2011 08:30 PM, Nicky D. wrote:
>> [...]
>> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:30:20: error: missing
>> binary operator before token "("
>> [...]
> Tried it today, getting that too. Huge slew of errors.
>
> Even though this looks intimidating, the reason is really simple.
>
> In OZ's version of json there is a file features.h in
> ../include/json/. Metaphorical
> speaking there he laid the bomb.
> It is then trigged in cmake/JsonCpp.cmake and newview/CMakeList.txt
>
> JsonCpp.cmake sets JSONCPP_INCLUDE_DIRS to ${LIBS_PREBUILD_DIR)/include/json.
> newview/CMakeList.txt adds JSONCPP_INCLUDE_DIRS to the system include dirs.
>
> Now the the problem with gcc is, that adding include dirs with -I
> makes them be searched
> before the system include dirs.
> And there our little bomb goes off. Because now the compiler findes
> the features.h file
> first in ../include/json. When it fact it needs the system one from
> /usr/include/features.h.
That analysis looks correct, so go ask Oz about that Eternal Glory he
offered on IRC. :-)
> One solution might be to use the -I- switch or -iquote for new gcc
> versions. But lucky
> enough there is a trivially simple fix, just use
> ${LIBS_PREBUILD_DIR)/include for
> JSONCPP_INCLUDE_DIRS.
>
> I attached a patch that does just this.
I just tested, and reverting eeb812d81330
(the changeset that switched to the new json download) works as a
workaround, too. Though, I guess your change is the preferred way to fix
this issue, because
1. there probably was a reason for updating jsoncpp
2. the other jsoncpp headers in the package also have very generic
names, so using the containing dir as a way of namespacing will
probably avoid further conflicts in the future
> Standalone builds might need
> some extra hackery,
> I did not try one of those yet.
Since 7690f4cb5e81
, the
jsoncpp include was probably broken for standalone anyway. (Can't test,
as standalone fails due to other (unrelated) errors.)
Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] unresolved external media_plugin_webkit.obj viewer-development and viewer-autobuild w/ Visual Studio 10
I have used a self compiled Visual Studio 10 llqtwebkit.lib and successfully built Imprudence 1.4.0, logged in to SL, and used search and the internal web browser. No errors at all. Using viewer-development and viewer-autobuild I get the following link error. "c:\users\bill\lindenhg\viewer-autobuild-vc100\build-vc80\media_plugins\webkit\media_plugin_webkit.vcxproj" (default target) (23) -> (Link target) -> media_plugin_webkit.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLQtWebKit::keyboardEvent(int,enum LLQtWebKit::e_key_event,unsigned int,char const *,enum LLQtWebKit::e_keyboard_modifier,unsigned int,unsigned int,unsigned int)" (?keyboardEvent@LLQtWebKit@@QAE_NHW4e_key_event@1@IPBDW4e_keyboard_modifier@1@III@Z) referenced in function "private: void __thiscall MediaPluginWebKit::keyEvent(enum LLQtWebKit::e_key_event,int,enum LLQtWebKit::e_keyboard_modifier,class LLSD)" (?keyEvent@MediaPluginWebKit@@AAEXW4e_key_event@LLQtWebKit@@HW4e_keyboard_modifier@3@VLLSD@@@Z) [c:\users\bill\lindenhg\viewer-autobuild-vc100\build-vc80\media_plugins\webkit\media_plugin_webkit.vcxproj] ] C:\Users\Bill\lindenhg\viewer-autobuild-vc100\build-vc80\media_plugins\webkit\RelWithDebInfo\media_plugin_webkit.dll : fatal error LNK1120: 1 unresolved externals [c:\users\bill\lindenhg\viewer-autobuild-vc100\build-vc80\media_plugins\webkit\media_plugin_webkit.vcxproj] Anyone have ideas of where to start looking. I guess v-d and v-a could be using a method that is expected to be in the llqtwebkit.lib that Imprudence never used. Or, maybe the method it isn't properly declared within the viewer code. I would like some help on this one. Thanks, NickyP ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
