Second Life Wiki - User contributions [en]

User:Dzonatas Sol/Snowglobe

2011-04-06T23:57:49Z

Dzonatas Sol: /* Base 32 bit chroot setup */

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this in <code>/etc/schroot/schroot.conf</code>

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

<code>$ schroot -c squeeze</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready in the <code>build-linux-i686/newview/packaged</code> directory. You can zip, tar, copy, etc that directory as needed to run or package your viewer.

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-06T23:15:07Z

Dzonatas Sol: /* Step-by-Step 32bit Chroot Compile */

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

<code>$ schroot -c squeeze</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready in the <code>build-linux-i686/newview/packaged</code> directory. You can zip, tar, copy, etc that directory as needed to run or package your viewer.

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-06T23:13:08Z

Dzonatas Sol: /* Run the Compile */

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c squeeze</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready in the build-linux-i686/newview/packaged directory. You can zip, tar, copy, etc that directory as needed to run or package your viewer.

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-06T22:54:57Z

Dzonatas Sol: /* Sources Setup */ update from sid to squeeze (use mainstream for gcc 4.4 and avoid gcc 4.5 & glibcxx3.4.14 abi in sid for now)

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c squeeze</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-06T22:53:10Z

Dzonatas Sol: /* Snowglobe 32 bit Compatibility on Debian Lenny 64 */ section removed, assertion fix confirmed in repos

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-06T22:52:14Z

Dzonatas Sol: /* Base 32 bit chroot setup */ update from sid to squeeze (needed to proper c++ abi, avoid gcc 4.5 for now, use gcc 4.4)

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "squeeze" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 squeeze /var/chroot/squeeze-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[squeeze]
description=Debian squeeze (stable)
location=/var/chroot/squeeze-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=stable,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c squeeze -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T03:30:42Z

Dzonatas Sol: /* Base 32 bit chroot setup */ now have to install make also

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin make cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T03:30:08Z

Dzonatas Sol: /* Run the Compile */ updated for autobuild

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd viewer-development</code> 
<code>$ autobuild build -c OpenSourceRelWithDebInfo</code>

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T03:10:18Z

Dzonatas Sol: /* Sources Setup */ updated from svn to hg

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ hg clone http://hg.secondlife.com/viewer-development</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T03:05:00Z

Dzonatas Sol: /* Base 32 bit chroot setup */

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex git mercurial</code>

Install [[Autobuild]]:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ svn export https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk snowglobe</code> 
<code>$ cd snowglobe</code> 
<code>$ ./scripts/public_fetch_tarballs.py</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T03:03:22Z

Dzonatas Sol: /* Base 32 bit chroot setup */ added autobuild

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex git mercurial</code>

Install LL Autobuild:

<code>$ cd /tmp && hg clone http://hg.secondlife.com/autobuild && cd autobuild && python setup.py install</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ svn export https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk snowglobe</code> 
<code>$ cd snowglobe</code> 
<code>$ ./scripts/public_fetch_tarballs.py</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T02:16:45Z

Dzonatas Sol: /* Base 32 bit chroot setup */ added git mercurial

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex git mercurial</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ svn export https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk snowglobe</code> 
<code>$ cd snowglobe</code> 
<code>$ ./scripts/public_fetch_tarballs.py</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T01:53:06Z

Dzonatas Sol: /* Sources Setup */

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ <code>schroot -c sid</code>

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ svn export https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk snowglobe</code> 
<code>$ cd snowglobe</code> 
<code>$ ./scripts/public_fetch_tarballs.py</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/Snowglobe

2011-04-04T01:52:11Z

Dzonatas Sol: /* Base 32 bit chroot setup */ remove steps for lenny, combined others for sid

== Step-by-Step 32bit Chroot Compile ==

=== Base 32 bit chroot setup ===

Note: If you have a separate /var partition it will need to be greater than 3.7GB to complete the build.

On Debian, bootstrap "sid" for your 32bit chroot:

<code>$ sudo debootstrap --arch i386 sid /var/chroot/sid-ia32 http://ftp.debian.org/debian/</code>

Once done, make sure you have your schroot entry set properly, mine looks like this

[sid]
description=Debian sid (unstable)
location=/var/chroot/sid-ia32
priority=3
groups=dzonatas,root
root-groups=root
aliases=unstable,default,ia32
personality=linux32
type=plain
run-setup-scripts=true
run-exec-scripts=true

Now you can log into your chroot as root to setup the base packages:

<code>$ sudo linux32 schroot -c sid -u root</code>

Initialize the packages:

<code>$ apt-get update</code>

Install these packages:

<code>$ apt-get install python g++ subversion unzip bzip2 libx11-dev libxrender-dev libgl1-mesa-dev libxft-dev libxrandr-dev</code>
<code> libxcursor-dev libglu-dev libsdl-dev libgtk2.0-bin cmake bison flex</code>

At this point, you can log out of root:

<code>$ exit</code>

The packages are setup.

=== Sources Setup ===

Login to your chroot as a regular user:

$ schroot -c lenny

Or, for sid:

$ schroot -c sid

We can use the <code>/tmp</code> directory for this example, and download the sources.

<code>$ cd /tmp</code> 
<code>$ svn export https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk snowglobe</code> 
<code>$ cd snowglobe</code> 
<code>$ ./scripts/public_fetch_tarballs.py</code>

=== Run the Compile ===

<code>$ cd indra</code> 
<code>$ ./develop.py</code> 
<code>$ cd viewer-linux-i686-relwithdebinfo</code> 
<code>$ make</code> 

After that completes, you should have it all ready for a package in the <code>newview/packaged</code> directory1. Copy that directory where you would normally want to execute it from (see YOURBUILTSNOWGLOBEDIR2 below).

1. This is where you copy from for example: /var/chroot//squeeze-ia32/snowglobe/indra/viewer-linux-i686-relwithdebinfo/newview/packaged.

2. This is where you copy to, the install directory for the 64 bit secondlife binary.

[[User:Nicky Perian|Nicky Perian]]

== Snowglobe 32 bit Compatibility on Debian Lenny 64 ==

To prevent assertion failures with the 32 bit pre-compiled libs included above, perform these steps:

<code>$ mkdir /tmp/extralibs</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb</code> 
<code>$ wget http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb</code> 
<code>$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs</code> 
<code>$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs</code> 
<code>$ cd YOURBUILTSNOWGLOBEDIR</code> 
<code>$ cp /tmp/extralibs/lib/* lib</code> 
<code>$ cp /tmp/extralibs/usr/lib/* lib</code> 

Replace the word YOURBUILTSNOWGLOBEDIR with your final installed/packaged directory (the one that looks like newview/packaged after a successful build and wherever you copied it to).

32 bit Snowglobe 1.4+/2.0+ binaries then work on Debian Lenny 64

== Standalone 64 bit Compile: Debian Lenny/Squeeze AMD 64 ==

Here are my notes about the compilation experience:

Lenny comes with cmake 2.6.0, but the experimental version is required:
sudo apt-get install -t sid cmake

Specific cmake builds wouldn't be needed if an universal binary was used, instead.

Downloaded and unpacked Snowglobe source (1.2.4.3008). Not gonna worry about git/hg/svn matters for this annotation.

Downloaded related files as specified in doc/asset_urls.txt: MD5, ART, LIBS_LINUXI386 (see above 32bit compile)

$ cd indra
$ ./develop.py --standalone -m64 configure
$ cd viewer-linux-x86_64-relwithdebinfo
$ make secondlife-bin

Issues:

* {{JIRA|SNOW-240}} At this time there is no jsoncpp debian package, so configure fails on this. Downloaded and compiled from sources noted in jira issue. Copied include files to /usr/local/include and libs to /usr/local/lib for temporary fix.
* {{JIRA|SNOW-285}} build error: llqtwebkit.h: No such file or directory -- Despite this being a dependency, it should have made the configure fail like above in {{JIRA|SNOW-240}}. The configure failure message could point to a wiki page to resolve the dependency (like an extra deb package for Debian).
* Somewhere in the attempts to build llqtwebkit, the /usr/lib/libGL.so file got deleted. I can pinpoint here because other programs worked (X, wine, monovida, etc) up until that moment. Very strange for that to happen, yet not totally unexpected (from other people's experience with qt-webkit). The older NVidia drivers that have Xgl support didn't have a deb package, so qt-webkit thought it could overwrite the GL files. Blind installs, like this issue, is exactly what the Debian-Way tries to avoid. I eventually avoided the llqtwebkit build entirely and just used the pre-built 32bit version for now. These plugins could be downloaded by a debian package separate from this build since it really isn't required to build and run secondlife-bin (thanks to LLMediaPlugin work).
* [[../NVidia 190.42|Upgrade to NVidia 190.42 drivers the Debian-Way]].

With the above issues resolved, you can install the built files. Normally, a "make package" would package them for you, yet since this is a "standalone" version this means it is assumed some pieces that were normally put into the package are already installed somewhere else rather than being a static build with secondlife-bin. The "make package" works if you built the plugins.

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-03T14:46:53Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="1" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|-
| rowspan="1" | /AvatarTracker/FriendsChanged
| style="text-align:right;" | POST
| -> [ { ID: uuid, Active: boolean, Online: boolean }, ... ] <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Complex query contains information for a specified friend UUID

== /AvatarTracker/FriendsChanged ==

Queried to update status. [ Deprecated ]

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-03T14:45:36Z

Dzonatas Sol: /* /AvatarTracker/FriendsChanged */

User:Dzonatas Sol/SNOW-375 Resources/Inventory

2010-08-03T05:00:39Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Inventory/Asset(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&status }, ... ] ( ?? uuid <- &status )

|-
| rowspan="1" | /Inventory/Item(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&item }, ... ] ( ?? uuid <- &item )

|-
| rowspan="1" | /Inventory/Root
| style="text-align:right;" | GET
| <- { ID: uuid }

|-
| rowspan="1" | /Inventory/Category(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&category }, ... ] ( ?? uuid <- &category )

|-
| rowspan="1" | /Inventory/Changed
| style="text-align:right;" | POST
| -> [ { ID: uuid, AssetType: string }, ... ] <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Inventory/Asset(/<uuid>) ==

Complex query used to localize assets. Asynchronously queries /Asset/Loaded as they become available.

== /Inventory/Item(/<uuid>) ==

Complex query contains &category

== /Inventory/Root ==

Response is root category uuid of agent's inventory

== /Inventory/Category(/<uuid>) ==

Complex query contains &category

== /Inventory/Changed ==

Queried when an inventory item(s) changes.

== status ==

{ status: string }

Value is "ok"

== category ==

{
{|
|-
| Version
| : integer
|-
| Name
| : string
|-
| Base
| : uuid
|-
| Categories
| : [ uuid, ... ]
|-
| Items
| : [ uuid, ... ]
|-
| Data
| : llsd
|}
}

== item ==

{
{|
|-
| *data*
|-
| ...
|-
| (Active)
| : bool
|}
}

Map elements and data are implementation specific, yet currently uses same LLSD format as internal to Snowglobe. Active is optional map entry that appears for gestures.

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-03T04:49:58Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="1" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|-
| rowspan="1" | /AvatarTracker/FriendsChanged
| style="text-align:right;" | POST
| -> [ { ID: uuid, Active: boolean, Online: boolean }, ... ] <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Complex query contains information for a specified friend UUID

== /AvatarTracker/FriendsChanged ==

Queried to update status.

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-03T04:49:19Z

Dzonatas Sol:

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="4" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|-
| rowspan="1" | /AvatarTracker/FriendsChanged
| style="text-align:right;" | POST
| -> [ { ID: uuid, Active: boolean, Online: boolean }, ... ] <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Complex query contains information for a specified friend UUID

== /AvatarTracker/FriendsChanged ==

Queried to update status.

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-03T04:43:01Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Interface/Connect
| style="text-align:right;" | POST
| -> &connect <- &result

|-
| rowspan="1" | /Interface/UI
| style="text-align:right;" | POST
| -> { UI: bool } <- { status: string }

|-
| rowspan="1" | /Interface/Status
| style="text-align:right;" | POST
| -> { Status: string } <- { status: string }

|-
| rowspan="1" | /Interface/Startup
| style="text-align:right;" | POST
| -> &empty <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Interface/Connect ==

Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [http://en.wikipedia.org/wiki/Flow_(psychology) Flow]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.

["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. [[User:Dzonatas_Sol/HttpCastRayLLSD|For example, ray-casting]] may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]

=== Forward: ===

Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).

An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.

=== Reverse: ===

The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.

A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.

[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure; 4) or, let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]

== /Interface/Status ==

A message that describes the changed state of the connection.

== /Interface/Startup ==

This resource capability URI defaults to the value of InterfaceStartupCapability. [ See note above about role switch. ]

== connect ==

{
{|
|-
| (host)
| : string
|-
| port
| : integer
|}
}

Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.

== result ==

{
{|
|-
| status
| : string
|-
| session
| : uuid
|-
| Version
| : string
|}
|

Version string is only informational, as given or detected capabilities are more significant.

User:Dzonatas Sol/SNOW-375 Resources/FloaterChat

2010-08-03T04:27:59Z

Dzonatas Sol: /* chat */

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /FloaterChat/AddChat
| style="text-align:right;" | POST
| -> &chat <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /FloaterChat/AddChat ==

Delivers &chat to local chat session. [ Resource should be renamed, maybe /ChatterBox/LocalChat ]

== chat ==

{
{|
|-
| text
| : string
|-
| from
| : string
|-
| from_id
| : uuid
|-
| source
| : integer
|-
| type
| : integer
|-
| audible
| : integer
|-
| muted
| : boolean
|-
| time
| : real
|-
| position
| : { X: real, Y: real, Z: real }
|}
}

User:Dzonatas Sol/SNOW-375 Resources/FloaterChat

2010-08-03T04:27:30Z

Dzonatas Sol: Created page with '__NOTOC__ {| border="1" cellpadding="5" cellspacing="0" |- | Resource || Method || Description |- |- | rowspan="1" | /FloaterChat/AddChat | style="text-align:right;" | POST | ->...'

User:Dzonatas Sol/SNOW-375 Resources

2010-08-03T04:19:07Z

Dzonatas Sol:

== Overview ==

This is a dictionary of all SNOW-375 resources.

Please see the main [[User:Dzonatas_Sol/SNOW-375|SNOW-375]] page for overview and technical documentation.

== SNOW-375 Resources ==

Resources are grouped by major representations. These are still being developed, yet a basic set exists that enables communication and gesture activation.

Resources may have more than one method. Each one is described as based on LLIDL. Parenthesized resources are denote complex queries, which may automatically transition simpler queries. Complex queries are usually used to group multiple queries together, and it includes each result code.

* [[User:Dzonatas_Sol/SNOW-375_Resources/ControlGroup|ControlGroup]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Agent|Agent]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Asset|Asset]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/AvatarTracker|AvatarTracker]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/ChatterBox|ChatterBox]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/FloaterChat|FloaterChat]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/GestureManager|GestureManager]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Inventory|Inventory]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Interface|Interface]]

User:Dzonatas Sol/SNOW-375 Resources/Asset

2010-08-03T04:12:05Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Asset/Notecard(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&notecard }, ... ] ( ?? uuid <- &notecard )

|-
| rowspan="1" | /Asset/Gesture(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&gesture }, ... ] ( ?? uuid <- &gesture )

|-
| rowspan="1" | /Asset/Loaded
| style="text-align:right;" | POST
| -> { ID: uuid, Type: string } <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Asset/Notecard(/<uuid>) ==

Complex query contains &notecard

== /Asset/Gesture(/<uuid>) ==

Complex query contains &gesture

== /Asset/Loaded ==

Queried when asset is localized.

== notecard ==

Asset in nested XML format (translated from 'linden notecard format'). Embedded notecard inventory items are nested in <embed> tags.

== gesture ==

{
{|
|-
| Name
| : string
|-
| Trigger
| : string
|-
| ReplaceText
| : string
|-
| Key
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/ChatterBox

2010-08-03T04:05:11Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /ChatterBox/Message
| style="text-align:right;" | POST
| -> { message: string, session: uuid, to: uuid, dialog: integer } <- &status

|-
| rowspan="1" | /ChatterBox/AddMessage
| style="text-align:right;" | POST
| -> &chat <- &status

|-
| rowspan="1" | /ChatterBox/StartGroupSession
| style="text-align:right;" | POST
| -> { session: uuid } <- &status

|-
| rowspan="1" | /ChatterBox/UpdateSessionID
| style="text-align:right;" | POST
| -> { session: uuid, temporary: uuid } <- &status

|}

Note: Description syntax is only based on LLIDL.

== /ChatterBox/Message ==

Deliver a message to a group/IM channel

== /ChatterBox/AddMessage ==

Deliver a message to session. [ Resource should be renamed to reverse /ChatterBox/Message ]

== /ChatterBox/StartGroupSession ==

Initiate a group chat session

== /ChatterBox/UpdateSessionID ==

Update temporary session to real session.

== status ==

{ status: string }

Value is "ok", consistently

== chat ==

{
{|
|-
| session
| : uuid
|-
| label
| : string
|-
| from
| : string
|-
| message
| : string
|-
| dialog
| : integer
|-
| estate
| : integer
|-
| region
| : uuid
|-
| link
| : boolean
|-
| position
| : { X: real, Y: real, Z: real }
|}
}

User:Dzonatas Sol/SNOW-375 Resources/ChatterBox

2010-08-03T03:56:43Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /ChatterBox/Message
| style="text-align:right;" | POST
| -> { message: string, session: uuid, to: uuid, dialog: integer } <- &status

|-
| rowspan="1" | /ChatterBox/AddMessage
| style="text-align:right;" | POST
| -> &chat <- &status

|-
| rowspan="1" | /ChatterBox/StartGroupSession
| style="text-align:right;" | POST
| -> { session: uuid } <- &status

|}

Note: Description syntax is only based on LLIDL.

== /ChatterBox/Message ==

Deliver a message to a group/IM channel

== /ChatterBox/AddMessage ==

Deliver a message to session. [ Resource should be renamed to reverse /ChatterBox/Message ]

== /ChatterBox/StartGroupSession ==

Initiate a group chat session

== status ==

{ status: string }

Value is "ok", consistently

== chat ==

{
{|
|-
| session
| : uuid
|-
| label
| : string
|-
| from
| : string
|-
| message
| : string
|-
| dialog
| : integer
|-
| estate
| : integer
|-
| region
| : uuid
|-
| link
| : boolean
|-
| position
| : { X: real, Y: real, Z: real }
|}
}

User:Dzonatas Sol/SNOW-375 Resources/ChatterBox

2010-08-03T03:56:11Z

Dzonatas Sol:

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /ChatterBox/Message
| style="text-align:right;" | POST
| -> { message: string, session: uuid, to: uuid, dialog: integer } <- &status

|-
| rowspan="1" | /ChatterBox/Message
| style="text-align:right;" | POST
| -> &chat <- &status

|-
| rowspan="1" | /ChatterBox/StartGroupSession
| style="text-align:right;" | POST
| -> { session: uuid } <- &status

|}

Note: Description syntax is only based on LLIDL.

== /ChatterBox/Message ==

Deliver a message to a group/IM channel

== /ChatterBox/AddMessage ==

Deliver a message to session. [ Resource should be renamed to reverse /ChatterBox/Message ]

== /ChatterBox/StartGroupSession ==

Initiate a group chat session

== status ==

{ status: string }

Value is "ok", consistently

== chat ==

{
{|
|-
| session
| : uuid
|-
| label
| : string
|-
| from
| : string
|-
| message
| : string
|-
| dialog
| : integer
|-
| estate
| : integer
|-
| region
| : uuid
|-
| link
| : boolean
|-
| position
| : { X: real, Y: real, Z: real }
|}
}

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-03T03:29:09Z

Dzonatas Sol: /* /Interface/Connect */

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Interface/Connect
| style="text-align:right;" | POST
| -> &connect <- &result

|-
| rowspan="1" | /Interface/UI
| style="text-align:right;" | POST
| -> { UI: bool } <- { status: string }

|-
| rowspan="1" | /Interface/Status
| style="text-align:right;" | POST
| -> { Status: string } <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Interface/Connect ==

Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [http://en.wikipedia.org/wiki/Flow_(psychology) Flow]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.

["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. [[User:Dzonatas_Sol/HttpCastRayLLSD|For example, ray-casting]] may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]

=== Forward: ===

Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).

An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.

=== Reverse: ===

The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.

A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.

[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure; 4) or, let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]

== /Interface/Status ==

A message that describes the changed state of the connection.

== connect ==

{
{|
|-
| (host)
| : string
|-
| port
| : integer
|}
}

Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.

== result ==

{
{|
|-
| status
| : string
|-
| session
| : uuid
|-
| Version
| : string
|}
|

Version string is only informational, as given or detected capabilities are more significant.

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T21:02:56Z

Dzonatas Sol: /* /Interface/Connect */

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Interface/Connect
| style="text-align:right;" | POST
| -> &connect <- &result

|-
| rowspan="1" | /Interface/UI
| style="text-align:right;" | POST
| -> { UI: bool } <- { status: string }

|-
| rowspan="1" | /Interface/Status
| style="text-align:right;" | POST
| -> { Status: string } <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Interface/Connect ==

Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [[http://en.wikipedia.org/wiki/Flow_(psychology)|Flow_(psychology)]]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.

["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. [[User:Dzonatas_Sol/HttpCastRayLLSD|For example, ray-casting]] may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]

=== Forward: ===

Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).

An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.

=== Reverse: ===

The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.

A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.

[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure; 4) or, let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]

== /Interface/Status ==

A message that describes the changed state of the connection.

== connect ==

{
{|
|-
| (host)
| : string
|-
| port
| : integer
|}
}

Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.

== result ==

{
{|
|-
| status
| : string
|-
| session
| : uuid
|-
| Version
| : string
|}
|

Version string is only informational, as given or detected capabilities are more significant.

User:Dzonatas Sol/HttpCastRayLLSD

2010-08-01T21:01:31Z

Dzonatas Sol:

This code does the very basic functionality to process casted rays by a query and to return the result as LLSD. This doesn't represent ideal functionality. It just allows us to research this basic functionality for potential optimization. It's not to be used to implement a full ray-tracer even if it is possible. It is meant to detect an object and use smart methods to not cast rays again through the area of that object. For now, we just use the bounding-box as the default area. Maybe if there was an extra filter to llCastRay that only returned static objects...

<lsl>
default
{
state_entry()
{
llSay(0, "Rebooted.");
llRequestURL();
}

http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == URL_REQUEST_DENIED)
{
llSay(0, "Something went wrong, no url. " + body);
}
else if (method == "GET")
{
string query = llGetHTTPHeader(id, "x-query-string");
list qvar = llParseString2List(query, ["filter=", "&sx=", "&sy=","&sz=","&ex=", "&ey=","&ez="], [""]);
integer filter = (integer)llList2String(qvar, 0);

float x = (float)llList2String(qvar, 1);
float y = (float)llList2String(qvar, 2);
float z = (float)llList2String(qvar, 3);
vector start = <x,y,z> ;

x = (float)llList2String(qvar, 4);
y = (float)llList2String(qvar, 5);
z = (float)llList2String(qvar, 6);
vector end = <x,y,z> ;
llSay(0, (string)start + " " + (string)end) ;

list results = llCastRay( start, end, filter, 0 ) ;
key uuid = llList2Key(results, 0);
string vec = llList2String(results, 1);

list box = llGetBoundingBox(uuid);
vector center = (llList2Vector(box, 0) + llList2Vector(box, 1)) * 0.5;
vector size = llList2Vector(box, 1) - llList2Vector(box, 0);

string text ;
text += "<llsd><map>" ;
text += "<key>ID</key>" ;
text += "<string>" + (string)uuid + "<string>" ;
text += "<key>Point</key>" ;
text += "<string>" + (string)vec + "<string>" ;
text += "<key>Center</key>" ;
text += "<string>" + (string)center + "<string>" ;
text += "<key>Size</key>" ;
text += "<string>" + (string)size + "<string>" ;
text += "</map></llsd>" ;
llHTTPResponse(id,200, text );
}
else
{
llHTTPResponse(id,405,"Unsupported Method");
}
}
}
</lsl>

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T18:29:35Z

Dzonatas Sol: /* Reverse: */

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Interface/Connect
| style="text-align:right;" | POST
| -> &connect <- &result

|-
| rowspan="1" | /Interface/UI
| style="text-align:right;" | POST
| -> { UI: bool } <- { status: string }

|-
| rowspan="1" | /Interface/Status
| style="text-align:right;" | POST
| -> { Status: string } <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Interface/Connect ==

Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [[http://en.wikipedia.org/wiki/Flow_(psychology)|Flow_(psychology)]]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.

["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. For example, ray-casting may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]

=== Forward: ===

Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).

An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.

=== Reverse: ===

The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.

A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.

[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure; 4) or, let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]

== /Interface/Status ==

A message that describes the changed state of the connection.

== connect ==

{
{|
|-
| (host)
| : string
|-
| port
| : integer
|}
}

Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.

== result ==

{
{|
|-
| status
| : string
|-
| session
| : uuid
|-
| Version
| : string
|}
|

Version string is only informational, as given or detected capabilities are more significant.

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T18:28:42Z

Dzonatas Sol: /* Reverse: */

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Interface/Connect
| style="text-align:right;" | POST
| -> &connect <- &result

|-
| rowspan="1" | /Interface/UI
| style="text-align:right;" | POST
| -> { UI: bool } <- { status: string }

|-
| rowspan="1" | /Interface/Status
| style="text-align:right;" | POST
| -> { Status: string } <- { status: string }

|}

Note: Description syntax is only based on LLIDL.

== /Interface/Connect ==

Note the roles here are in perspective of the initiator. They may switch automatically in bidirectional only connections. See [[http://en.wikipedia.org/wiki/Flow_(psychology)|Flow_(psychology)]]. Fallback to unidirectional connections is optional (see VWRAP), yet that implies static initiation. A non-intrusive proxy in between a bidirectional connection and a unidirectional connection may appear ideal. The unidirectional connection between Snowglobe (client) and the Second Life (server) is ideal for a static initiation, which can be a backbone for various processes that create bidirectional connections (primarily within a firewalled, multi-headed client domain). Authentication levels and connection security schemes may vary upon implementation (highly demanded by VWRAP/IETF for such flexibility, possibly closed-augmented levels). Note that use-cases exist that request security and authentication without traditional textual user and password means.

["Feature Freeze": Possible models yet to be demonstrated may include (or may never be implemented) resources for stationary and mobile environments. In this sense, mobile means where the presence of the avatar may authenticate from different clients. Stationary means that capabilities and their roles may have persistent values, like InterfaceStartupCapability below. For example, ray-casting may allow to see without being able to change and no need to expose original data. There are some "obvious" applications for stationary roles.]

=== Forward: ===

Attempt to negotiate a connection. A reverse /Interface/Connect query is made by this forward interface (which is the Snowglobe Viewer when InterfaceStartupCapability is unset).

An optional session cookie is set as an extra security measure to in order to lock-down a single client/server connection.

=== Reverse: ===

The application that requested the initial connection also listens for this query. On a successful query the Snowglobe's ControlGroup variable "InterfaceStartupCapability" is set to http://host:port/Interface/Connect, as detected by the forward interface. Note that Snowglobe Viewer may later use InterfaceStartupCapability to automatically connect by /Interface/Connect in a role switch.

A bidirectional paradigm can be created here that is unlike traditional unidirectional client/server security models, yet this bidirectional paradigm assumes connections do not fallback to unidirectional capabilities. The bidirectional paradigm may also include the intention that unhandled capabilities or query transitions should be encapsulated by crash prevention rather than default to exceptional states. The implementation of the transport layer should not exceptionalize it abstraction, or further transitions become impossible. General rule is that original content cannot be made impossible, and the basis of this is reality itself: that's Life™.

[It cannot be stressed enough that in the "flow" of the bidirectional paradigm that if a bug is found: 1) Don't immediately "fix" bug; 2) instead, ensure baby-safe style prevention; 3) then determine if self found buried treasure, or 4) let it live and die another day. For every fire-wall, there is an ice-wall... is this not clear enough?]

== /Interface/Status ==

A message that describes the changed state of the connection.

== connect ==

{
{|
|-
| (host)
| : string
|-
| port
| : integer
|}
}

Host is optional for remote sessions. Note that multi-headed clients may appear similar to remote.

== result ==

{
{|
|-
| status
| : string
|-
| session
| : uuid
|-
| Version
| : string
|}
|

Version string is only informational, as given or detected capabilities are more significant.

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T17:54:32Z

Dzonatas Sol: /* Forward: */

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T17:39:40Z

Dzonatas Sol: Security & Authentication

User:Dzonatas Sol/SNOW-375 Resources/ControlGroup

2010-08-01T14:34:05Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description

|-
| rowspan="1" | [[#/ControlGroup|/ControlGroup]]
| style="text-align:right;" | GET
| <- [ &[[#group|group]] , ... ]

|-

|-
| rowspan="1" | [[#/ControlGroup/<group>|/ControlGroup/<group>]]
| style="text-align:right;" | GET
| ?? &[[#group|group]] <- [ &[[#defvar|defvar]], ... ]

|-

|-
| rowspan="1" | [[#/ControlGroup/<group>/<identifier>|/ControlGroup/<group>/<identifier>]]
| style="text-align:right;" | GET
| ?? &[[#group|group]] ?? &[[#identifier|identifier]] <- &[[#curvar|curvar]]

|}

Note: Description syntax is only based on LLIDL.

== /ControlGroup ==

Response is a list of control &[[#group|group]]s

== /ControlGroup/<group> ==

Response is a list of valid variable &[[#identifier|identifier]]s in a controlgroup with default settings

== /ControlGroup/<group>/<identifier> ==

Response is the current settings for the specific variable identified

== group ==

&group = string

Name of the ControlGroup.

== identifier ==

&identifier = string

Name of the ControlGroup variable.

== defvar ==

&defvar =
{
{|
|-
| identifier
| : &[[#identifier|identifier]],
|-
| persist
| : boolean,
|-
| comment
| : string,
|-
| type
| : int,
|-
| value
| : llsd
|}
}

== curvar ==

&curvar = llsd

The current value of ControlGrounp variable as nested LLSD.

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T03:16:12Z

Dzonatas Sol:

User:Dzonatas Sol/SNOW-375 Resources/Interface

2010-08-01T03:13:40Z

Dzonatas Sol:

User:Dzonatas Sol/SNOW-375 Resources/Inventory

2010-08-01T02:32:10Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Inventory/Asset(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&status }, ... ] ( ?? uuid <- &status )

|-
| rowspan="1" | /Inventory/Item(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&item }, ... ] ( ?? uuid <- &item )

|-
| rowspan="1" | /Inventory/Root
| style="text-align:right;" | GET
| <- { ID: uuid }

|-
| rowspan="1" | /Inventory/Category(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&category }, ... ] ( ?? uuid <- &category )

|}

Note: Description syntax is only based on LLIDL.

== /Inventory/Asset(/<uuid>) ==

Complex query used to localize assets. Asynchronously queries /Asset/Loaded as they become available.

== /Inventory/Item(/<uuid>) ==

Complex query contains &category

== /Inventory/Root ==

Response is root category uuid of agent's inventory

== /Inventory/Category(/<uuid>) ==

Complex query contains &category

== status ==

{ status: string }

Value is "ok"

== category ==

{
{|
|-
| Version
| : integer
|-
| Name
| : string
|-
| Base
| : uuid
|-
| Categories
| : [ uuid, ... ]
|-
| Items
| : [ uuid, ... ]
|-
| Data
| : llsd
|}
}

== item ==

{
{|
|-
| *data*
|-
| ...
|-
| (Active)
| : bool
|}
}

Map elements and data are implementation specific, yet currently uses same LLSD format as internal to Snowglobe. Active is optional map entry that appears for gestures.

User:Dzonatas Sol/SNOW-375 Resources/Inventory

2010-08-01T02:31:24Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Inventory/Asset(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&status }, ... ] ( ?? uuid <- &status )

|-
| rowspan="1" | /Inventory/Item(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&item }, ... ] ( ?? uuid <- &item )

|-
| rowspan="1" | /Inventory/Root
| style="text-align:right;" | GET
| <- { ID: uuid }

|-
| rowspan="1" | /Inventory/Category/<uuid>
| style="text-align:right;" | GET (POST)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&category }, ... ] ( ?? uuid <- &category )

|}

Note: Description syntax is only based on LLIDL.

== /Inventory/Asset(/<uuid>) ==

Complex query used to localize assets. Asynchronously queries /Asset/Loaded as they become available.

== /Inventory/Item(/<uuid>) ==

Complex query contains &category

== /Inventory/Root ==

Response is root category uuid of agent's inventory

== /Inventory/Category(/<uuid>) ==

Complex query contains &category

== status ==

{ status: string }

Value is "ok"

== category ==

{
{|
|-
| Version
| : integer
|-
| Name
| : string
|-
| Base
| : uuid
|-
| Categories
| : [ uuid, ... ]
|-
| Items
| : [ uuid, ... ]
|-
| Data
| : llsd
|}
}

== item ==

{
{|
|-
| *data*
|-
| ...
|-
| (Active)
| : bool
|}
}

Map elements and data are implementation specific, yet currently uses same LLSD format as internal to Snowglobe. Active is optional map entry that appears for gestures.

User:Dzonatas Sol/SNOW-375 Resources/GestureManager

2010-08-01T01:53:17Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /GestureManager/Items
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="1" | /GestureManager/Item/<uuid>
| style="text-align:right;" | POST (GET)
| (deprecated, use /Inventor/Item and /Asset/Gesture)

|-
| rowspan="1" | /GestureManager/PlayGesture/<uuid>
| style="text-align:right;" | POST
| -> &empty <- &status

|}

Note: Description syntax is only based on LLIDL.

== /GestureManager/Items ==

Response is a list of UUIDs of active gestures

== /GestureManager/Item/<uuid> ==

(deprecated, use /Inventor/Item and /Asset/Gesture)

== /GestureManager/PlayGesture/<uuid> ==

Start a gesture

== empty ==

Valid empty LLSD payload (i.e. "<llsd/>")

== status ==

{ status: string }

Value is "ok", consistently

User:Dzonatas Sol/SNOW-375 Resources/GestureManager

2010-08-01T01:52:29Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /GestureManager/Items
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="1" | /GestureManager/Item/<uuid>
| style="text-align:right;" | POST (GET)
| (deprecated, use /Inventor/Item and /Asset/Gesture)

|-
| rowspan="1" | /GestureManager/PlayGesture/<uuid>
| style="text-align:right;" | POST
| -> &empty <- &status

|}

Note: Description syntax is only based on LLIDL.

== /GestureManager/Items ==

Response is a list of UUIDs of active gestures

== /GestureManager/Item/<uuid> ==

(deprecated, use /Inventor/Item and /Asset/Gesture)

== empty ==

Valid empty LLSD payload (i.e. "<llsd/>")

== status ==

{ status: string }

Value is "ok", consistently

== /GestureManager/PlayGesture/<uuid> ==

Start a gesture

User:Dzonatas Sol/SNOW-375 Resources/GestureManager

2010-08-01T01:52:00Z

Dzonatas Sol:

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /GestureManager/Items
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="1" | /GestureManager/Item/<uuid>
| style="text-align:right;" | POST (GET)
| (deprecated, use /Inventor/Item and /Asset/Gesture)

|-
| rowspan="1" | /GestureManager/PlayGesture/<uuid>
| style="text-align:right;" | POST
| -> &empty <- &status

|}

Note: Description syntax is only based on LLIDL.

== /GestureManager/Items ==

Response is a list of UUIDs of active gestures

== /GestureManager/Item/<uuid> ==

(deprecated, use /Inventor/Item and /Asset/Gesture)

== empty ==

Valid empty LLSD payload (i.e. "<llsd/>")

== status ==

{ status: string }

Value is "ok", consistently

== /GestureManager/PlayGesture/<uuid> ==

Start a gesture

User:Dzonatas Sol/SNOW-375 Resources

2010-08-01T01:40:24Z

Dzonatas Sol: /* SNOW-375 Resources */

== Overview ==

This is a dictionary of all SNOW-375 resources.

Please see the main [[User:Dzonatas_Sol/SNOW-375|SNOW-375]] page for overview and technical documentation.

== SNOW-375 Resources ==

Resources are grouped by major representations. These are still being developed, yet a basic set exists that enables communication and gesture activation.

Resources may have more than one method. Each one is described as based on LLIDL. Parenthesized resources are denote complex queries, which may automatically transition simpler queries. Complex queries are usually used to group multiple queries together, and it includes each result code.

* [[User:Dzonatas_Sol/SNOW-375_Resources/ControlGroup|ControlGroup]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Agent|Agent]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Asset|Asset]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/AvatarTracker|AvatarTracker]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/ChatterBox|ChatterBox]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/GestureManager|GestureManager]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Inventory|Inventory]]
* [[User:Dzonatas_Sol/SNOW-375_Resources/Interface|Interface]]

User:Dzonatas Sol/SNOW-375 Resources/ChatterBox

2010-08-01T01:29:05Z

Dzonatas Sol:

User:Dzonatas Sol/SNOW-375 Resources/ChatterBox

2010-08-01T01:27:56Z

Dzonatas Sol:

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-01T01:19:38Z

Dzonatas Sol:

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="4" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Complex query contains information for a specified friend UUID

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-01T01:18:49Z

Dzonatas Sol: /* /AvatarTracker/Friend(/) */

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="4" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Complex query contains information for a specified friend UUID

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/AvatarTracker

2010-08-01T01:15:49Z

Dzonatas Sol:

{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /AvatarTracker/Friends
| style="text-align:right;" | GET
| <- [ uuid, ... ]

|-
| rowspan="4" | /AvatarTracker/Friend(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&friend }, ... ] ( ?? uuid <- &friend )

|}

Note: Description syntax is only based on LLIDL.

== /AvatarTracker/Friends ==

Response is the UUID list of the agent's friends and basic status of each

== /AvatarTracker/Friend(/<uuid>) ==

Response is a detailed relationship information for a specified friend UUID

== friend ==

{
{|
|-
| Online
| : bool
|-
| First
| : string
|-
| Last
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/Asset

2010-08-01T00:58:25Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Asset/Notecard(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&notecard }, ... ] ( ?? uuid <- &notecard )

|-
| rowspan="1" | /Asset/Gesture(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&gesture }, ... ] ( ?? uuid <- &gesture )

|}

Note: Description syntax is only based on LLIDL.

== /Asset/Notecard(/<uuid>) ==

Complex query contains &notecard

== /Asset/Gesture(/<uuid>) ==

Complex query contains &gesture

== notecard ==

Asset in nested XML format (translated from 'linden notecard format'). Embedded notecard inventory items are nested in <embed> tags.

== gesture ==

{
{|
|-
| Name
| : string
|-
| Trigger
| : string
|-
| ReplaceText
| : string
|-
| Key
| : string
|}
}

User:Dzonatas Sol/SNOW-375 Resources/Asset

2010-08-01T00:56:49Z

Dzonatas Sol:

__NOTOC__
{| border="1" cellpadding="5" cellspacing="0"
|-
| Resource || Method || Description
|-

|-
| rowspan="1" | /Asset/Notecard(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&notecard }, ... ] ( ?? uuid <- &notecard )

|-
| rowspan="1" | /Asset/Gesture(/<uuid>)
| style="text-align:right;" | POST (GET)
| ?? 's' -> [ uuid , ... ] <- [ { ID: uuid, +&gesture }, ... ] ( ?? uuid <- &gesture )

|}

Note: Description syntax is only based on LLIDL.

== /Asset/Notecard(/<uuid>) ==

Complex query contains &notecard

== /Asset/Gesture(/<uuid>) ==

Complex query contains &gesture

== &notecard ==

Asset in nested XML format (translated from 'linden notecard format'). Embedded notecard inventory items are nested in <embed> tags.

== &gesture ==

{
{|
|-
| Name
| : string
|-
| Trigger
| : string
|-
| ReplaceText
| : string
|-
| Key
| : string
|}
}