From sl.nicky.ml at googlemail.com Tue Feb 4 13:28:53 2020 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Tue, 4 Feb 2020 22:28:53 +0100 Subject: [opensource-dev] viewer-release vs The Penguins Message-ID: it has been a while since LL released their last Linux capable viewer. To get things started again I brought 6.3.6 up to Linux support: https://bitbucket.org/NickyD/viewer-linux https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build scripts) As I know the chances to see a penguin fly are bigger than get a release from LL, I also created a flatpak that users can install and run (instructions below). I'm still pondering to make an AppImage from it, but that's something for another day. Differences in the Linux version: - Uses SDL2 rather than SDL (so the "OS" version can be used). - Uses GTK3 instead of GTK2, again to not have to compile the old GTK version. - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. Once FMOD Studio gets into the viewer I add it to the Linux release. - No KDU. I obviously don't have access to LLs version of KDU and won't use the one I have for Firestorm. - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets updated by the OS (Flatpak in this case) rather than shipping some ancient VLC version. - dullahan/CEF is added. So it got the usual web browser as Windows/OSX got. - It's obviously unsupported. The flatpak is hosted by The Phoenix Firestorm Project Inc. ( https://www.firestormviewer.org/about/) but could easily hosted by any webserver or say AWS/S3. Installation: flatpak is needed and must be installed via the distros usual ways ( https://flatpak.org/setup/) Then the viewer can be installed either system or user specific: Add Flatpak repo - Systemwide: - flatpak remote-add viewer-builds https://flatpak.firestormviewer.org/viewer.flatpakrepo - User install - flatpak remote-add --user viewer-builds https://flatpak.firestormviewer.org/viewer.flatpakrepo Install viewer (it will give the option which branch, stable has the advantage that it can be updated as new released get added): - Systemwide: - flatpak install viewer-builds viewer-release - User install - flatpak install --user viewer-builds viewer-release Run the viewer - flatpak run org.lindenlab.viewer-release Cheers, Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200204/7ea4d4e4/attachment.htm From misteracacia at gmail.com Tue Feb 4 14:53:17 2020 From: misteracacia at gmail.com (misteracacia at gmail.com) Date: Tue, 4 Feb 2020 16:53:17 -0600 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: References: Message-ID: <65fba9ca-7abb-90e8-06a6-64d1f6e4dc53@gmail.com> Attempting this on a non-GNOME distro (Xubuntu 18.04.3), I was told I was missing org.gnome.Platform/x86_64/3.30. Installing that allowed me to proceed. On 2/4/20 3:28 PM, Nicky D. wrote: > > it has been a while since LL released their last Linux capable viewer. > To get things started > again I brought 6.3.6 up to Linux support: > https://bitbucket.org/NickyD/viewer-linux > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > scripts) > > As I know the chances to see a penguin fly are bigger than get a > release from > LL, I also created a flatpak that users can install and run > (instructions below). > I'm still pondering to make an AppImage from it, but that's something > for another day. > > Differences in the Linux version: > - Uses SDL2 rather than SDL (so the "OS" version can be used). > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > version. > - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. > Once > FMOD Studio gets into the viewer I add it to the Linux release. > - No KDU. I obviously don't have access to LLs version of KDU and > won't use the one I have for Firestorm. > - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets > updated by the OS (Flatpak in this case) rather than shipping some > ancient VLC version. > - dullahan/CEF is added. So it got the usual web browser as > Windows/OSX got. > - It's obviously unsupported. > > The flatpak is hosted by The Phoenix Firestorm Project Inc. > (https://www.firestormviewer.org/about/) but could easily hosted by > any webserver or say AWS/S3. > > Installation: > flatpak is needed and must be installed via the distros usual ways > (https://flatpak.org/setup/) > Then the viewer can be installed either system or user specific: > > Add Flatpak repo > > * > Systemwide: > o > flatpak remote-add viewer-builds > https://flatpak.firestormviewer.org/viewer.flatpakrepo > * > User install > o > flatpak remote-add --user viewer-builds > https://flatpak.firestormviewer.org/viewer.flatpakrepo > > Install viewer (it will give the option which branch, stable has the > advantage that it can be updated as new released get added): > > * > Systemwide: > o > flatpak install viewer-builds viewer-release > * > User install > o > flatpak install --user viewer-builds viewer-release > > Run the viewer > > * > flatpak run org.lindenlab.viewer-release > > > Cheers, > ?? Nicky > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200204/332319b9/attachment.htm From sldev at free.fr Thu Feb 6 02:44:17 2020 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 6 Feb 2020 11:44:17 +0100 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: References: Message-ID: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > it has been a while since LL released their last Linux capable viewer. To > get things started > again I brought 6.3.6 up to Linux support: > https://bitbucket.org/NickyD/viewer-linux > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > scripts) > > As I know the chances to see a penguin fly are bigger than get a release > from LL, I also created a flatpak that users can install and run > (instructions below). I fail to see the advantage of a flatpak, when the current distribution method (i.e. bundling libraries that are likely to lack on the user's system, or that have been patched) do work nicely... Flatpaks are huge and bloated with stuff that the viewer won't really need (but are just non-essential dependencies to some libraries it uses). The alternative to both flatpaks and dynamic libraries bundling in the viewer distribution is to statically link all libraries that are likely to be missing on the user's system. That's what software like Firefox or Blender do for their pre-compiled Linux binaries distributions. > Differences in the Linux version: > - Uses SDL2 rather than SDL (so the "OS" version can be used). That's an interesting and useful change, that I'll probably pick-up for my own viewer: SDL2 is the path to the future anyway (with Wayland support, even though the latter is likely to stay inappropriate for running the viewer in the foreseeable future, since NVIDIA proprietary drivers don't support it and Open Source NVIDIA drivers are way too slow or right out incomplete). However, I would recommend to keep linking statically SDL2 to the viewer binary, since SDL2 is far from a mandatory prerequisite in many Linux distros (i.e. it is not always installed by default). > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > version. I solved the GTK dependency a looong while ago... By removing it entirely ! The viewer depends on GTK under Linux only for the text clipboard (and it is not even properly implemented with it), and for the file selector (which lacks proper threading, or causes threading bugs/slow downs when threading is attempted). My solution has been to re-code the clipboard stuff directly with Xlib primitives (with proper primary and secondary paste buffer support) and to code an XUI file selector, that also works for Windows and macOS by the way, with a code that is beautifully simple and largely OS-independent (only a few #if LL_WINDOWS here and there to deal with Windows file system peculiarities, such as with hidden files and drive volume names), since it relies on llcommon classes to deal with OS-dependent stuff. An alternative, if you want to keep an OS-dependent file selector, would be to migrate to Qt's: easier and cleaner to implement in C++... > - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. > Once FMOD Studio gets into the viewer I add it to the Linux release. I got support for FMOD Studio in my viewer for a long while too. Quite easy to implement based on FMOD Ex implementation. The only loss is support for the (rarely used) OSS backend in FMOD (but OpenAL can use it, and I got both OpenAL and FMOD Studio supported in my Linux viewer). > - No KDU. I obviously don't have access to LLs version of KDU and won't > use the one I have for Firestorm. OpenJPEG does a good job anyway (pretty much as fast as KDU too, when compiled with SSE2/3 support). Just make sure to use a SL-compatible version (I use a heavily patched v1.4.0.635 personal fork, with security fixes and SSE optimizations backported from v2). Here again, OpenJPEG is best statically linked to the viewer (I even integrated its sources to the viewer sources, since they are so specific/heavily modified). > - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets > updated by the OS (Flatpak in this case) rather than shipping some ancient > VLC version. I totally agree with you. Beside, like I already explained back in 2016 in this list, GStreamer would also be a better choice for Windows and macOS users: it only needs to be installed once and for all (i.e. no need to bundle a huge amount of libraries with the viewer, like is the case of VLC) and solves all software patent issues (users can choose what CODECs they install on their system, depending on where they live and/or how "sensitive" they are towards the patent issues). I use Gstreamer for all OSes in my viewer: never got a single complaint from any user for doing so... > - dullahan/CEF is added. So it got the usual web browser as Windows/OSX got. > - It's obviously unsupported. I provided and kept up to date the sources for a Linux-compatible Dullahan since November 2015 on my site... That could count as "support", I think... :-D Another thing you might want to look at is getting rid of the deprecated, unsupported and utterly buggy dbus-glib dependency. I solved this a long time ago by coding DBus support based on glib-gio (see llappviewerlinux.cpp in my viewer sources): it's very clean and small code, that also does properly work (dbus-glib got a timeout bug, unless you use a very old version that no distro would provide any more nowadays, anyway). Henri. From sl.nicky.ml at googlemail.com Thu Feb 6 03:05:17 2020 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 6 Feb 2020 12:05:17 +0100 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> References: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> Message-ID: On Thu, Feb 6, 2020 at 11:45 AM Henri Beauchamp wrote: > On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > > > it has been a while since LL released their last Linux capable viewer. To > > get things started > > again I brought 6.3.6 up to Linux support: > > https://bitbucket.org/NickyD/viewer-linux > > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > > scripts) > > > > As I know the chances to see a penguin fly are bigger than get a release > > from LL, I also created a flatpak that users can install and run > > (instructions below). > > I fail to see the advantage of a flatpak, when the current distribution > method (i.e. bundling libraries that are likely to lack on the user's > system, or that have been patched) do work nicely... Flatpaks are huge > and bloated with stuff that the viewer won't really need (but are just > non-essential dependencies to some libraries it uses). > > The main reason why this happened is LL not wanting to have their own Linux viewer depend on many 3Ps but rather use as much standalone that you can find on a Linux system. That led to either snap, flatpak or AppImage. Of course then due to time constraints they never picked it up. But that's the reason behind the current format. It is based on what I did for LL. > > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > > version. > > I solved the GTK dependency a looong while ago... By removing it > entirely ! > > I know. I already looked at it for Firestorm. But LL won't let you contribute this as we know due to their CA standards. I'd really like to get rid of the GTK dependency. Even if only for Firestorm. As long as we're speaking about a viewer LL might want to integrate (debatable if it ever happens), taking contributions of others is out of the question. Taking contribution from others without CA is completely unthinkable. > > - It's obviously unsupported. > > I provided and kept up to date the sources for a Linux-compatible Dullahan > since November 2015 on my site... That could count as "support", I think... > :-D > > Hehe I meant the viewer is unsupported. Everyone but LL has dullahan for Linux since ages. Then again LL has no Linux viewer since ages either. > Another thing you might want to look at is getting rid of the deprecated, > unsupported and utterly buggy dbus-glib dependency. I solved this a long > time ago by coding DBus support based on glib-gio (see llappviewerlinux.cpp > in my viewer sources): it's very clean and small code, that also does > properly work (dbus-glib got a timeout bug, unless you use a very old > version that no distro would provide any more nowadays, anyway). > > > I'm going to look at that. Thank you for the input. Again though likely going to look at it for Firestorm. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200206/35088cc4/attachment.htm From sldev at free.fr Thu Feb 6 04:45:16 2020 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 6 Feb 2020 13:45:16 +0100 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: References: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> Message-ID: <20200206134516.5594b558a3540e9128c51a6e@free.fr> On Thu, 6 Feb 2020 12:05:17 +0100, Nicky D. wrote: > I know. I already looked at it for Firestorm. But LL won't let you > contribute this as we know due to their CA standards. I see... I was apparently mistaken by the 'vs' term in the subject of your message, and by the fact your viewer-linux sources was hosted on a private repository and not on LL's. I thought it was just a "generic Linux viewer" forked from LL's viewer-release, and as such, open to any Open Source developer's contributions (or at the very least, suggestions). > I'd really like to get rid of the GTK dependency. Even if only for > Firestorm. Like I suggested (if I'm still permitted to do that), you could also go the Qt route, which I believe would be much cleaner, easier, future-proof (GTK4 is already in the pipeline and will incur even harder breakages), and better for the end user (with Qt, as a user, you can choose the look and feel and the theme, including GTK2's if you fancy it !). > As long as we're speaking about a viewer LL might want to integrate > (debatable if it ever happens), taking contributions of others is out > of the question. Taking contribution from others without CA is > completely unthinkable. Like is unthinkable for me to sign a CA that requests personal information that go way beyond the purpose of such an agreement. LL shall respect the Law of the country of the contributor, with regard to their CA, and they simply don't. Henri. From monty at lindenlab.com Thu Feb 6 14:51:03 2020 From: monty at lindenlab.com (monty) Date: Thu, 6 Feb 2020 17:51:03 -0500 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: References: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> Message-ID: <8d2e35d2-3a9c-d7f6-7f22-cfcb9b4469d1@lindenlab.com> On 2/6/2020 6:05, Nicky D. wrote: > The main reason why this happened is LL not wanting to have their own > Linux viewer depend on many 3Ps but rather use as much standalone > that you can find on a Linux system. That led to either snap, flatpak or > AppImage. I'm certainly interested in what you discover in containerizing the viewer. Distribution size, edge cases where things go wrong. Dropping it into a wsl2 instance on windows to see what happens... m From deepbluemistake at gmail.com Thu Feb 6 21:51:27 2020 From: deepbluemistake at gmail.com (Andras Farkas) Date: Fri, 7 Feb 2020 00:51:27 -0500 Subject: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2) Message-ID: Hello! I was watching a friend play Second Life and thought it looked cool (I'm really into MUCKs, so VR is a cool topic in general) so I decided I'd try to compile it on FreeBSD, my desktop OS. I decided to try compiling it on Ubuntu first, to examine the build process. However, I encountered an error related to libndof, as seen in the attached errout.txt Moreover, the info on the wiki related to ndof (and everything): http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)#More_problematic_libraries_.28standalone.29 is so out of date that it isn't useful. Debian Squeeze and Lenny are ancient, and Ubuntu Lucid and Precise are too. http://apt.byteme.org.uk/ also no longer exists. And at least on Ubuntu Eoan Ermine, a package name has changed: libopenjpeg-dev --> libopenjp2-7-dev If you can let me know how to get past this error, I'd be grateful. Thanks! :D (this is the second attempt to send this, hope it works) -------------- next part -------------- Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified; using a value from the UTC date and time (200360842), which may not be unique '/usr/bin/cmake' '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' '-DADDRESS_SIZE:STRING=64' '-DROOT_PROJECT_NAME:STRING=SecondLife' '-DINSTALL_PROPRIETARY=FALSE' '-G' 'Unix Makefiles' '../indra' -- Using PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/share/pkgconfig -- Revision (from autobuild environment): 200360842 -- Building 'Second Life Test' Version 6.3.7.200360842 CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) llrender/CMakeLists.txt:6 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/base/CMakeLists.txt:14 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/gstreamer010/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/libvlc/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/example/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. ERROR: Package not installable due to conflicts open-libndofdev configuration Release version 0.3 build_id 297553 Conflict: dependency SDL with installed package SDL installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/1103/2554/SDL-1.2.15-linux64-501092.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/sdl_3p-update-sdl/rev/297546/arch/Linux/installer/SDL-1.2.15-linux-297546.tar.bz2 installed hash 7ea2df03bfc35c06acf23dd9e734adac vs 459cdc8d7c19a8025f98f61db95622ff installed build_id 501092 vs 297546 dependency libpng with installed package libpng installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/882/1946/libpng-1.6.8.500873-linux64-500873.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/libpng_3p-update-libpng/rev/297051/arch/Linux/installer/libpng-1.6.8.297051-linux-297051.tar.bz2 installed hash 13de93ea11544051b69f238eeb644fd3 vs 6dec32fc2527f8cafd616f9271ff3478 installed version 1.6.8.500873 vs 1.6.8.297051 installed build_id 500873 vs 297051 dependency zlib with installed package zlib installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/866/1898/zlib-1.2.8.500857-linux64-500857.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/zlib_3p-update-zlib/rev/296881/arch/Linux/installer/zlib-1.2.8.296881-linux-296881.tar.bz2 installed hash dab6be8b0596c1e3354f2b6d41335131 vs 2eb8e59b6464222dcf4435016ad5f618 installed version 1.2.8.500857 vs 1.2.8.296881 installed build_id 500857 vs 296881 used by libxml2 version 2.9.4.500877 build 500877 If you have updated the configuration for any of the conflicting packages, try uninstalling those packages and rerunning. For more information: try re-running your command with --verbose or --debug CMake Error at cmake/Prebuilt.cmake:57 (message): Failed to download or unpack prebuilt 'open-libndofdev'. Process returned 1. Call Stack (most recent call first): cmake/NDOF.cmake:14 (use_prebuilt_binary) newview/CMakeLists.txt:46 (include) -- Configuring incomplete, errors occurred! See also "/home/darty/min/secondlaifu/lindenlab-viewer-2998552f3d74/build-linux-i686/CMakeFiles/CMakeOutput.log". ERROR: configuring default configuration returned 1 For more information: try re-running your command with --verbose or --debug From sldev at vlan1000.net Thu Feb 6 22:57:29 2020 From: sldev at vlan1000.net (Alex) Date: Fri, 07 Feb 2020 17:57:29 +1100 Subject: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2) In-Reply-To: References: Message-ID: Hi! Regarding FreeBSD.. You will not get this to work on FreeBSD without an absolute buttload of work.. For starters, autobuild would not recognize FreeBSD as a valid platform, you would need to hack it to support FreeBSD (or write your own build system). Many things would also be missing and would need implementing, like CEF and dullahan and voice support. Also, FreeBSD's OSS (open sound system) is not implemented in the viewer, so you'd probably have no sound. Then you would need to compile a metric tonne of dependent libraries for FreeBSD, or modify the build to use system wide libraries instead of trying to link against the packages ones that autobuild will try and download and link statically. I wouldnt even go there... Just.... Dont. lol. And yes, the linux build instructions are grossly out of date in LL's wiki. LL no longer provide a linux viewer or support it in any shape or form. A. On 2020-02-07 16:51, Andras Farkas wrote: > Hello! > I was watching a friend play Second Life and thought it looked cool > (I'm really into MUCKs, so VR is a cool topic in general) so I decided > I'd try to compile it on FreeBSD, my desktop OS. > > I decided to try compiling it on Ubuntu first, to examine the build > process. However, I encountered an error related to libndof, as seen > in the attached errout.txt > > Moreover, the info on the wiki related to ndof (and everything): > http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)#More_problematic_libraries_.28standalone.29 > is so out of date that it isn't useful. Debian Squeeze and Lenny are > ancient, and Ubuntu Lucid and Precise are too. > http://apt.byteme.org.uk/ also no longer exists. > And at least on Ubuntu Eoan Ermine, a package name has changed: > libopenjpeg-dev --> libopenjp2-7-dev > > If you can let me know how to get past this error, I'd be grateful. > Thanks! :D > > (this is the second attempt to send this, hope it works) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified; using a value from the UTC date and time (200360842), which may not be unique '/usr/bin/cmake' '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' '-DADDRESS_SIZE:STRING=64' '-DROOT_PROJECT_NAME:STRING=SecondLife' '-DINSTALL_PROPRIETARY=FALSE' '-G' 'Unix Makefiles' '../indra' -- Using PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/share/pkgconfig -- Revision (from autobuild environment): 200360842 -- Building 'Second Life Test' Version 6.3.7.200360842 CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) llrender/CMakeLists.txt:6 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/base/CMakeLists.txt:14 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/gstreamer010/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/libvlc/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/example/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. ERROR: Package not installable due to conflicts open-libndofdev configuration Release version 0.3 build_id 297553 Conflict: dependency SDL with installed package SDL installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/1103/2554/SDL-1.2.15-linux64-501092.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/sdl_3p-update-sdl/rev/297546/arch/Linux/installer/SDL-1.2.15-linux-297546.tar.bz2 installed hash 7ea2df03bfc35c06acf23dd9e734adac vs 459cdc8d7c19a8025f98f61db95622ff installed build_id 501092 vs 297546 dependency libpng with installed package libpng installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/882/1946/libpng-1.6.8.500873-linux64-500873.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/libpng_3p-update-libpng/rev/297051/arch/Linux/installer/libpng-1.6.8.297051-linux-297051.tar.bz2 installed hash 13de93ea11544051b69f238eeb644fd3 vs 6dec32fc2527f8cafd616f9271ff3478 installed version 1.6.8.500873 vs 1.6.8.297051 installed build_id 500873 vs 297051 dependency zlib with installed package zlib installed url http://automated-builds-secondlife-com.s3.amazonaws.com/ct2/866/1898/zlib-1.2.8.500857-linux64-500857.tar.bz2 vs http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/zlib_3p-update-zlib/rev/296881/arch/Linux/installer/zlib-1.2.8.296881-linux-296881.tar.bz2 installed hash dab6be8b0596c1e3354f2b6d41335131 vs 2eb8e59b6464222dcf4435016ad5f618 installed version 1.2.8.500857 vs 1.2.8.296881 installed build_id 500857 vs 296881 used by libxml2 version 2.9.4.500877 build 500877 If you have updated the configuration for any of the conflicting packages, try uninstalling those packages and rerunning. For more information: try re-running your command with --verbose or --debug CMake Error at cmake/Prebuilt.cmake:57 (message): Failed to download or unpack prebuilt 'open-libndofdev'. Process returned 1. Call Stack (most recent call first): cmake/NDOF.cmake:14 (use_prebuilt_binary) newview/CMakeLists.txt:46 (include) -- Configuring incomplete, errors occurred! See also "/home/darty/min/secondlaifu/lindenlab-viewer-2998552f3d74/build-linux-i686/CMakeFiles/CMakeOutput.log". ERROR: configuring default configuration returned 1 For more information: try re-running your command with --verbose or --debug From sldev at free.fr Fri Feb 7 01:52:12 2020 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 7 Feb 2020 10:52:12 +0100 Subject: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2) In-Reply-To: References: Message-ID: <20200207105212.427ab4efd9f2c92db39fdb2b@free.fr> On Fri, 7 Feb 2020 00:51:27 -0500, Andras Farkas wrote: > I was watching a friend play Second Life and thought it looked cool > (I'm really into MUCKs, so VR is a cool topic in general) so I decided > I'd try to compile it on FreeBSD, my desktop OS. FreeBSD is not a build target for the viewer: beyond the need to rework the build system (and corresponding #defines in the sources), you'd lack all the pre-built libraries that the viewer needs. > I decided to try compiling it on Ubuntu first, to examine the build > process. However, I encountered an error related to libndof, as seen > in the attached errout.txt Do not use Linden Lab's sources to try and build a Linux viewer: you would invariably fail. [rant] You can thank LL for not providing support for Linux; while they benefit for free from all the work done by GNU/Linux developers and while SL won't even exist without their work (especially on the server side of things, but even the viewer is using a shitload of Open Source components that have been primarily developed under and for GNU/Linux). That's how LL is repaying the Open Source community when they could just "devote" one developer to simply reuse the work TPV developers did for Linux, and provide a Linux supported viewer. Hell ! I've been maintaining (and vastly improving) my own viewer (and not just for Linux) for the past 13 years, alone, and only on part of my sparse free time: don't tell me a programmer at LL cannot maintain a Linux viewer: all what it would take them (once their viewer is brought on par with TPVs' Linux support) is just a couple of hours of work *per week* ! [/rant] Instead, try TPV sources. My viewer (Cool VL Viewer) builds with just a single command under any Linux distro (just type ./buildlinux.sh in a terminal pointing in the linden/indra/ directory). It would also be a good candidate for a FreeBSD port: it got a stand- alone build system (so adding FreeBSD to the cmake files would not be an impossible task), and the sources/scripts for building the pre-built libraries are also provided (http://sldev.free.fr/libraries/sources/ ). Be warned however, that porting the viewer to *BSD would require C/C++ programming skills (i.e. beyond what is needed to simply compile the viewer or its libraries), and that I won't be of help for this task (no *BSD system here, and no time whatsoever to devote to such a port). On Fri, 07 Feb 2020 17:57:29 +1100, Alex wrote: > Many things would also be missing and would need implementing, like CEF > and dullahan Not sure there is a recent enough port of CEF (*), indeed, but once you got the CEF binaries, building Dullahan won't be much of an issue, using my sources/script as a base. (*) With a quick search on the web, I only found this: https://github.com/prash-wghats/Brackets-CEF-for-FreeBSD/tree/master/CEF but it's way too old (CEF 51, and currently using CEF 74). > and voice support. Voice support is largely hosed under Linux anyway (the v2.1 voice client, which is the last Linux version Vivox provided, still works for public voice chat, but you cannot do voice with another resident not using themselves that same old client). However, for a vast majority of SLers (especially non native-English- speaking residents, but also all genuine role-players), voice is not even a useful feature of SL (never using it myself), so... > Also, FreeBSD's OSS (open sound system) is not implemented in the viewer Wrong ! The viewer got support for OpenAL, which itself supports the OSS backend. FMOD sound would however be ruled out (not really an issue either since OpenAL can do sound, including streaming). Henri. From sldev at vlan1000.net Fri Feb 7 02:23:14 2020 From: sldev at vlan1000.net (Alex) Date: Fri, 07 Feb 2020 21:23:14 +1100 Subject: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2) In-Reply-To: <20200207105212.427ab4efd9f2c92db39fdb2b@free.fr> References: <20200207105212.427ab4efd9f2c92db39fdb2b@free.fr> Message-ID: <0527bfc16c4e6c138cbf0a5e9a3825b7@vlan1000.net> On 2020-02-07 20:52, Henri Beauchamp wrote: > [rant] > You can thank LL for not providing support for Linux; while they > benefit > for free from all the work done by GNU/Linux developers and while SL > won't even exist without their work (especially on the server side of > things, but even the viewer is using a shitload of Open Source > components > that have been primarily developed under and for GNU/Linux). > That's how LL is repaying the Open Source community when they could > just "devote" one developer to simply reuse the work TPV developers did > for Linux, and provide a Linux supported viewer. > > Hell ! I've been maintaining (and vastly improving) my own viewer (and > not just for Linux) for the past 13 years, alone, and only on part of > my > sparse free time: don't tell me a programmer at LL cannot maintain a > Linux viewer: all what it would take them (once their viewer is brought > on par with TPVs' Linux support) is just a couple of hours of work *per > week* ! > [/rant] Agreed 100% Though I have given up hope of LL ever changing their stance (based on some recent events). I wont say anymore because the temptation to also start a rant of my own on the subject is there. I think you pretty much covered it. Maybe one day pigs will fly and LL will go back to providing a Linux viewer. A. From malee at csu.edu.au Fri Feb 14 06:20:39 2020 From: malee at csu.edu.au (Lee, Mark) Date: Fri, 14 Feb 2020 14:20:39 +0000 Subject: [opensource-dev] Last day for paper submissions: IEEE Tech. Co-sponsored Immersive Learning Research Network (iLRN) Conference, San Luis Obispo, Calif., June 2020 Message-ID: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS AND PROPOSALS iLRN 2020: 6th International Conference of the Immersive Learning Research Network June 21?25, 2020, San Luis Obispo, California, USA Technically co-sponsored by the IEEE Education Society, with proceedings to be submitted for inclusion in IEEE Xplore? Conference theme: "Vision 20/20: Hindsight, Insight, and Foresight in XR and Immersive Learning" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Conference website: http://immersivelrn.org/ilrn2020 Full CFP available at: http://bit.ly/2ki4gzb (PDF), http://bit.ly/2lUcpdG (HTML) The Immersive Learning Research Network (iLRN) is a burgeoning global network of researchers and practitioners collaborating to develop the scientific, technical, and applied potential of immersive learning. Its annual conference is the premier scholarly event focusing on advances in the use of virtual reality (VR), augmented reality (AR), mixed reality (MR), and other extended reality (XR) technologies to support learners and learning. Leading scholars and professionals operating in formal education settings as well as those representing diverse industry sectors will converge on the historic and picturesque coastal city of San Luis Obispo, California for iLRN 2020, where they will share their research findings, experiences, and insights; network and establish partnerships to envision and shape the future of XR and immersive technologies for learning; and contribute to the emerging scholarly knowledge base on how these technologies can be used to create experiences that educate, engage, and excite learners. ##### TOPIC AREAS ##### XR and immersive learning in/for: - Serious Games - Medical & Healthcare - Workforce & Industry - Culture & Language - K-12 - Museums & Libraries - Special Education - Geosciences - Data Visualization With Special Tracks on: - Playful Immersive Learning Experiences - Place, Presence, & Perspective - Inclusion, Diversity, Equity, Access & Social Justice (IDEAS) - Self & Co-regulated Learning - Immersive & Engaging Educational Experiences - Digital Transformation & Humanities ##### SESSSION TYPES & SESSION FORMATS ##### *** Academic Stream *** (Refereed papers for proceedings) - Full or short paper for oral presentation - Short or work-in-progress paper for poster presentation - Work-in-progress paper for doctoral colloquium *** Practitioner Stream *** (No paper ? refereed on the basis of abstract) - Oral presentation - Poster presentation - Demo showcase *** Non-Traditional Formats *** - Pre-conference workshops - Special sessions - Panel sessions Please see the conference website for templates and guidelines. ##### IMPORTANT DATES ##### - Main submission deadline* - FINAL EXTENSION: 2020-02-14 - Main-round notifications: 2020-03-23 - Camera-ready papers (Main): 2020-04-06 - Late submission deadline*: 2020-03-30 - Late-round notifications: 2020-04-27 - Camera-ready papers (Late): 2020-05-11 - Conference: 2020-06-21 to 2020-06-25 *Full and short papers can only be submitted in the main round. ##### PUBLICATION & INDEXING ##### Accepted and registered papers presented at iLRN 2020 will be published in the conference proceedings and submitted to the IEEE Xplore? digital library. IEEE makes Xplore content available to its abstracting & indexing partners, including Elsevier (Scopus, Ei Compendex) and Clarivate Analytics (CPCI - part of Web of Science). In addition, the authors of selected papers may be invited to submit revised and expanded versions of their papers for possible publication in the IEEE Transactions on Learning Technologies (2018 JCR Impact Factor: 2.315), the Journal of Universal Computer Science (2018 JCR Impact Factor: 0.91), or another Scopus and/or Web of Science-indexed journal, subject to the relevant journal?s regular editorial and peer-review policies and procedures. ##### CONTACT ##### conference at immersivelrn.org | ALBURY-WODONGA | BATHURST | BRISBANE | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA | LEGAL NOTICE This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with Charles Sturt University may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at Charles Sturt University. The views expressed in this email are not necessarily those of Charles Sturt University. Charles Sturt University in Australia The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018 Consider the environment before printing this email. From sl.nicky.ml at googlemail.com Sat Feb 15 09:44:01 2020 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Sat, 15 Feb 2020 18:44:01 +0100 Subject: [opensource-dev] viewer-release vs The Penguins In-Reply-To: <8d2e35d2-3a9c-d7f6-7f22-cfcb9b4469d1@lindenlab.com> References: <20200206114417.1422a8ed235e0c31b423a9fe@free.fr> <8d2e35d2-3a9c-d7f6-7f22-cfcb9b4469d1@lindenlab.com> Message-ID: On Thu, Feb 6, 2020 at 11:51 PM monty wrote: > On 2/6/2020 6:05, Nicky D. wrote: > > > The main reason why this happened is LL not wanting to have their own > > Linux viewer depend on many 3Ps but rather use as much standalone > > that you can find on a Linux system. That led to either snap, flatpak or > > AppImage. > > I'm certainly interested in what you discover in containerizing the > viewer. Distribution size, edge cases where things go wrong. Dropping > it into a wsl2 instance on windows to see what happens... > > This is not really the scope of this viewer. It should provide an option to run the "official" viewer on Linux. For example FS support often asks if someone tried to reproduce their issue on the official viewer. To test if it's a problem specific to Firestorm or a generic one. Speaking about docker or WSL2 in general, both are not made for GUI application. And while\ you could do something by using a remote display, performance won't be something you have fun with. If the viewer starts at all and can use that display. Cheers, Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200215/5926800b/attachment.htm From oz at lindenlab.com Tue Feb 25 07:48:03 2020 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 25 Feb 2020 10:48:03 -0500 Subject: [opensource-dev] Viewer changes for Premium changes Message-ID: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> ** *As we mentioned at the last Third Party Viewer meeting, the upcoming changes to Premium levels will require some viewer updates to maintain full compatibility.* * Why are there changes? The viewer currently has some messages and costs hard coded that will need to be sensitive to the account type of the user. Rather than just telling the viewer the users? account level (which we will also do) and then putting code into the viewer to adjust based on that type, we have built a more general solution. A new key ('benefits') in the LLSD map returned by login identifies a map whose keys are "benefit tags" and whose values are what that benefit level is for the logged-in user. For example, one of the benefit tags is "texture_upload_cost"; its value is the number of L$ required for this user to upload a texture. The viewer displays that cost in the upload dialog so that dialog must be modified to use the value returned in the tag rather than the L$10 that is currently hard coded. Where are the changes? The changes are in the 'DRTVWR-481 ' branch in the viewer git repository. A viewer built from that branch will be available as a Release Candidate soon. When can we release these changes? We strongly encourage you to integrate these changes as soon as possible. You are free to begin incorporating the changes and releasing them any time (but please watch for updates to them). The login servers should already be returning the benefits information (the values are the same as those currently in the viewer; they'll change when we make the new Premium Plus level available and introduce other changes to Premium). The simulator support for benefits is still being finalized and deployed; they are just beginning to use the benefits information from login in the same way this new viewer branch does. In practice, both should arrive at the same numbers since the current benefits information from login matches the old hard coded values. If your testing shows any discrepancies, please report them via Jira as quickly as possible. What will happen with unmodified viewers when the Premium changes go into effect? Most Second Life usage should be fine without the updates, but there may be subtle problems. For example, an unmodified viewer may have the wrong cost for some action; if the viewer expects the cost to be lower than the simulator does, the simulator will reject the request. * -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200225/eb91be0f/attachment.htm From sldev at hotmail.com Tue Feb 25 12:17:10 2020 From: sldev at hotmail.com (Henri Beauchamp) Date: Tue, 25 Feb 2020 21:17:10 +0100 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> Message-ID: <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: > *As we mentioned at the last Third Party Viewer meeting, Oh yes, those meetings a non-English speaking developer cannot follow because they are held in voice chat... How nice and practical a way of communication ! > the upcoming changes to Premium levels will require some viewer > updates to maintain full compatibility.* This is not just "full compatibility", because sadly, the way you (LL) chose to implement the "benefits" rendered many old viewers incapable of login into SL. More on that below. > Why are there changes? > > The viewer currently has some messages and costs hard coded They are _*NOT*_ hard-coded. The cost is modified after login on receiving the EconomyData message (the process_economy_data() callback is implemented in indra/newview/llviewermessage.cpp). By the way, that's how OpenSIM grid can (and always could) deal with different costs than in SL. Granted, only the fixed upload cost (currently L$10 in SL) is transmitted by the server and used by the viewers, but extending the message with more costs (and/or changing that cost server side, based on the logged in avatar account level) would have kept old viewers compatible with the login process. > that will need to be sensitive to the account type of the user. Rather > than just telling the viewer the users? account level (which we will > also do) and then putting code into the viewer to adjust based on that > type, we have built a more general solution. A new key ('benefits') in > the LLSD map returned by login identifies a map whose keys are "benefit > tags" and whose values are what that benefit level is for the logged-in > user. Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) do not know what to do with such an array (they can only deal with simple key/value pairs, not with key/arrays); this was the case of my viewer (but I thankfully and by pure "luck" noticed the issue a few weeks before LL did stealthily modify the login server on the main grid, because the beta grid already had the changes which caused me to fail to login in it at that time, and I could diagnose and fix the issue). > For example, one of the benefit tags is "texture_upload_cost"; its value > is the number of L$ required for this user to upload a texture. The > viewer displays that cost in the upload dialog so that dialog must be > modified to use the value returned in the tag rather than the L$10 that > is currently hard coded. This particular usage is useless and redundant, since EconomyData/ process_economy_data() already can change that value in real time (and in fact, it could even occur on a per-sim basis if needed, and not just at login !). > Where are the changes? > > The changes are in the 'DRTVWR-481 > ' branch in > the viewer git repository. A viewer built from that branch will be > available as a Release Candidate soon. It would have been nice to give a sufficient forewarning to avoid breaking the login process on the main grid for many viewers (or viewer versions): Radegast, my viewer (all versions before v1.26.24.2 are unable to login in SL any more), OMV, etc, etc, etc. > When can we release these changes? > > We strongly encourage you to integrate these changes as soon as > possible. You are free to begin incorporating the changes and releasing > them any time (but please watch for updates to them). We don't have any choice, because of a poor design of the said changes. Beside the redundant aspect (with the EconomyData message), there was no backward compatibility guard. Even if you want to get rid of EconomyData (even if I don't see why), it would have been dead easy to implement the following protocol: - on login request by the viewer, the server looks at the requested_options map (see LLLoginInstance::constructAuthParams()). - if the said map contains the "benefits" keyword, then the server sends the benefits array in its reply, else it omits it. This way, old viewers (that don't know what to do with that array) are still able to connect, and new viewers needing that array can request it. > What will happen with unmodified viewers when the Premium changes go > into effect? > > Most Second Life usage should be fine without the updates, but there may > be subtle problems. For example, an unmodified viewer may have the wrong > cost for some action; if the viewer expects the cost to be lower than > the simulator does, the simulator will reject the request. Which is NOT an issue for most old viewers; e.g. I was using OMV (that just got broken), but never used paying services with it... Another super-useful (actually pretty much *essential*) use case for "deprecated" viewers is to find the origin of a bug: "what was the last viewer version which did not have that bug ?" is the first question I pose to myself whenever a regression bug is found.Was it pre-BOM, pre- Animesh, pre-Materials, pre-whatever-shader-or-render-pipeline-change ? As it is today, I cannot any more test old viewer versions in SL should I have a regression to diagnose and fix ! >:-( I am (yet again) extremely disappointed with LL: - No communication (a message in this list should have been posted even before the change would have gone live on Aditi !), - No forewarning (it's already too late for Agni as well !), - No anticipation of the problems induced by the planed change, - Not even a sane, simple, trivial precaution, such as respecting LL's own viewer protocols design (here via the requested_options mechanism) for something as essential as the login process ! Shame on you, LL ! A pissed off, Henri. From nathaniel.prugh at bellevuecollege.edu Tue Feb 25 13:10:50 2020 From: nathaniel.prugh at bellevuecollege.edu (Nathaniel Prugh) Date: Tue, 25 Feb 2020 21:10:50 +0000 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> Message-ID: <7598E9A6-B888-4E6E-A559-25D9D486B8D5@bellevuecollege.edu> Where is announcement of those features in sl blog? So we know what new stuff coming soon etc? Sent from my iPhone On Feb 25, 2020, at 7:48 AM, Oz Linden (Scott Lawrence) wrote: ? As we mentioned at the last Third Party Viewer meeting, the upcoming changes to Premium levels will require some viewer updates to maintain full compatibility. Why are there changes? The viewer currently has some messages and costs hard coded that will need to be sensitive to the account type of the user. Rather than just telling the viewer the users? account level (which we will also do) and then putting code into the viewer to adjust based on that type, we have built a more general solution. A new key ('benefits') in the LLSD map returned by login identifies a map whose keys are "benefit tags" and whose values are what that benefit level is for the logged-in user. For example, one of the benefit tags is "texture_upload_cost"; its value is the number of L$ required for this user to upload a texture. The viewer displays that cost in the upload dialog so that dialog must be modified to use the value returned in the tag rather than the L$10 that is currently hard coded. Where are the changes? The changes are in the 'DRTVWR-481' branch in the viewer git repository. A viewer built from that branch will be available as a Release Candidate soon. When can we release these changes? We strongly encourage you to integrate these changes as soon as possible. You are free to begin incorporating the changes and releasing them any time (but please watch for updates to them). The login servers should already be returning the benefits information (the values are the same as those currently in the viewer; they'll change when we make the new Premium Plus level available and introduce other changes to Premium). The simulator support for benefits is still being finalized and deployed; they are just beginning to use the benefits information from login in the same way this new viewer branch does. In practice, both should arrive at the same numbers since the current benefits information from login matches the old hard coded values. If your testing shows any discrepancies, please report them via Jira as quickly as possible. What will happen with unmodified viewers when the Premium changes go into effect? Most Second Life usage should be fine without the updates, but there may be subtle problems. For example, an unmodified viewer may have the wrong cost for some action; if the viewer expects the cost to be lower than the simulator does, the simulator will reject the request. -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences _______________________________________________ Policies and (un)subscribe information available here: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.secondlife.com%2Fwiki%2FOpenSource-Dev&data=02%7C01%7Cnathaniel.prugh%40bellevuecollege.edu%7C942e75979c6042d528a608d7ba0a21da%7Cf94c251c1347422eb3ea8ac56befd6cb%7C0%7C0%7C637182424989505340&sdata=cS4bbvJPjDkQOOi2cpqMyPXhNGLCPK5qJj3egwMr12c%3D&reserved=0 Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200225/acc9a384/attachment-0001.htm From signal at lindenlab.com Wed Feb 26 08:55:31 2020 From: signal at lindenlab.com (Signal) Date: Wed, 26 Feb 2020 08:55:31 -0800 Subject: [opensource-dev] Additional Git Migrations - llbase, llweb Message-ID: Python library repositories for llbase and llweb have been converted to git. If access to Mercurial versions of these sources is still needed it can be found by looking for repository name + *-hg for a short period of time. More generally, one may encounter smaller repositories such as llweb and llbase switching to git while retaining the same location as the previous repository. https://bitbucket.org/lindenlab/llbase https://bitbucket.org/lindenlab/llbase-hg https://bitbucket.org/lindenlab/llweb https://bitbucket.org/lindenlab/llweb-hg -Signal Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200226/a9c4ec26/attachment.htm From cinder at alchemyviewer.org Thu Feb 27 05:21:00 2020 From: cinder at alchemyviewer.org (Cinder Roxley) Date: Thu, 27 Feb 2020 05:21:00 -0800 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sldev at hotmail.com) wrote: On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: > *As we mentioned at the last Third Party Viewer meeting, Oh yes, those meetings a non-English speaking developer cannot follow because they are held in voice chat... How nice and practical a way of communication ! Agreed. Even as a native English speaker, the meetings are not accessible to those without access to voice. Summaries of the meetings on third party blogs don?t really suffice for api breaking updates. > Why are there changes? > > The viewer currently has some messages and costs hard coded They are _*NOT*_ hard-coded. The cost is modified after login on receiving the EconomyData message (the process_economy_data() callback is implemented in indra/newview/llviewermessage.cpp). By the way, that's how OpenSIM grid can (and always could) deal with different costs than in SL. Agreed on this point. When I implemented some of these same features in an OpenSim grid, it was by extending the EconomyData message combined with simulator cap. Won?t go into implementation issues with the way it was done because it?s already been done, outside of mentioning the rampant singletons-calling-singletons-calling-singletons pattern is problematic. :) Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) do not know what to do with such an array (they can only deal with simple key/value pairs, not with key/arrays); this was the case of my viewer (but I thankfully and by pure "luck" noticed the issue a few weeks before LL did stealthily modify the login server on the main grid, because the beta grid already had the changes which caused me to fail to login in it at that time, and I could diagnose and fix the issue). Lost a day out of my weekend diagnosing and resolving this in LibreMetaverse/Radegast-ng. It really is a death blow to the unmaintained OMV library. Heads up before this kind of deployment would be very appreciated. > For example, one of the benefit tags is "texture_upload_cost"; its value > is the number of L$ required for this user to upload a texture. The > viewer displays that cost in the upload dialog so that dialog must be > modified to use the value returned in the tag rather than the L$10 that > is currently hard coded. This particular usage is useless and redundant, since EconomyData/ process_economy_data() already can change that value in real time (and in fact, it could even occur on a per-sim basis if needed, and not just at login !). Very true. It also handles the case where a customer changes premium levels while logged in. They would only need a balance refresh not completely exiting the viewer and logging back in (including an out of sync state where an account is downgraded while the agent remains online.) > Where are the changes? > > The changes are in the 'DRTVWR-481 > ' branch in > the viewer git repository. A viewer built from that branch will be > available as a Release Candidate soon. It would have been nice to give a sufficient forewarning to avoid breaking the login process on the main grid for many viewers (or viewer versions): Radegast, my viewer (all versions before v1.26.24.2 are unable to login in SL any more), OMV, etc, etc, etc. Seconded. Always appreciated when API changes are documented on the wiki as well. I am (yet again) extremely disappointed with LL: - No communication (a message in this list should have been posted even before the change would have gone live on Aditi !), - No forewarning (it's already too late for Agni as well !), - No anticipation of the problems induced by the planed change, - Not even a sane, simple, trivial precaution, such as respecting LL's own viewer protocols design (here via the requested_options mechanism) for something as essential as the login process ! Agreeing with this. There?s a wealth of knowledge that can be tapped into via this mailing list that could have prevented some of these compatibility issues. Remember that many of us have been blackboxing the API and extending features without any access to the server side code for over a decade now. Those of us with that breadth of experience rarely attend the inworld meetings due to language, accessibility, and geographic constraints. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/13673b0b/attachment.htm From oz at lindenlab.com Thu Feb 27 08:10:19 2020 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 27 Feb 2020 11:10:19 -0500 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: On 2020-02-27 08:21 , Cinder Roxley wrote: > On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sldev at hotmail.com > ) wrote: >> On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: >> >> > Why are there changes? >> > >> > The viewer currently has some messages and costs hard coded >> >> They are _*NOT*_ hard-coded. The cost is modified after login on >> receiving the EconomyData message (the process_economy_data() callback >> is implemented in indra/newview/llviewermessage.cpp). >> By the way, that's how OpenSIM grid can (and always could) deal with >> different costs than in SL. > > Agreed on this point. When I implemented some of these same features > in an OpenSim grid, it was by extending the EconomyData message > combined with simulator cap. > The EconomyData message doesn't have all the dimensions that we needed to modify. In the new design, login supplies both the viewer and the simulators with the benefits data for each agent at login time (yes, this means that if you were to upgrade your account while you were logged in, the change would not take effect for any in-world purpose until your next login). This design allows us to have just one place where the benefits are established and everything gets the information from there either directly or indirectly. > > Won?t go into implementation issues with the way it was done because > it?s already been done, outside of mentioning the rampant > singletons-calling-singletons-calling-singletons pattern is > problematic. :) > I don't see how singleton usage is related to the benefits changes, and don't understand what problem you're describing, but I suggest that any followup for that be on a thread of its own. >> Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers >> (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) >> do not know what to do with such an array (they can only deal with simple >> key/value pairs, not with key/arrays); this was the case of my viewer >> (but I thankfully and by pure "luck" noticed the issue a few weeks before >> LL did stealthily modify the login server on the main grid, because the >> beta grid already had the changes which caused me to fail to login in it >> at that time, and I could diagnose and fix the issue). > > Lost a day out of my weekend diagnosing and resolving this in > LibreMetaverse/Radegast-ng. It really is a death blow to the > unmaintained OMV library. Heads up before this kind of deployment > would be very appreciated. > The definition of LLSD and our open source implementations of it have always included the possibility of arbitrary nesting in arrays and maps (and we use it extensively internally without problems). We're not able to constrain our designs to maintain compatibility with incomplete implementations we may not even know about, much less ones that are unmaintained. > > Where are the changes? >> > >> > The changes are in the 'DRTVWR-481 >> > ' branch in >> > the viewer git repository. A viewer built from that branch will be >> > available as a Release Candidate soon. >> >> It would have been nice to give a sufficient forewarning to avoid >> breaking >> the login process on the main grid for many viewers (or viewer versions): >> Radegast, my viewer (all versions before v1.26.24.2 are unable to login >> in SL any more), OMV, etc, etc, etc. > > Seconded. Always appreciated when API changes are documented on the > wiki as well. > I admit that I expected that an entry in a map that you didn't expect wouldn't be a problem; I assumed that it would be ignored (as it is in ours) and that it would be more useful to give you changes when there was something you could test against. I suggest that in the future your implementations be guided byPostel's Law. That having been said, we'll try to provide more advance warning for future changes when possible. Note that the further in advance the notice comes, the less specific and actionable it can be. -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/3fa8b0d9/attachment-0001.htm From oz at lindenlab.com Thu Feb 27 08:14:02 2020 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 27 Feb 2020 11:14:02 -0500 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <7598E9A6-B888-4E6E-A559-25D9D486B8D5@bellevuecollege.edu> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <7598E9A6-B888-4E6E-A559-25D9D486B8D5@bellevuecollege.edu> Message-ID: <73a6d288-dc9a-0ab4-bb0e-635edcd456cd@lindenlab.com> On 2020-02-25 16:10 , Nathaniel Prugh wrote: > Where is announcement of those features in sl blog? So we know what > new stuff coming soon etc? We don't normally use the blogs for communicating code changes; that's what this list is for. The fact that we're making changes to Premium and introducing a new Premium Plus upgrade has been extensively discussed on the blogs for months. -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/d7b0cdd7/attachment.htm From nathaniel.prugh at bellevuecollege.edu Thu Feb 27 08:26:14 2020 From: nathaniel.prugh at bellevuecollege.edu (Nathaniel Prugh) Date: Thu, 27 Feb 2020 16:26:14 +0000 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <73a6d288-dc9a-0ab4-bb0e-635edcd456cd@lindenlab.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <7598E9A6-B888-4E6E-A559-25D9D486B8D5@bellevuecollege.edu>, <73a6d288-dc9a-0ab4-bb0e-635edcd456cd@lindenlab.com> Message-ID: <45E28F17-59E9-40C7-ABD0-22E4C3FC60AC@bellevuecollege.edu> Sent from my iPhone On Feb 27, 2020, at 8:14 AM, Oz Linden (Scott Lawrence) wrote: ? On 2020-02-25 16:10 , Nathaniel Prugh wrote: Where is announcement of those features in sl blog? So we know what new stuff coming soon etc? [..] The fact that we're making changes to Premium and introducing a new Premium Plus upgrade has been extensively discussed on the blogs for months. Hey oz... Can you show me the links to announcement of new premium. Features like the plus? Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/f278da29/attachment.htm From oz at lindenlab.com Thu Feb 27 09:13:36 2020 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 27 Feb 2020 12:13:36 -0500 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <45E28F17-59E9-40C7-ABD0-22E4C3FC60AC@bellevuecollege.edu> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <7598E9A6-B888-4E6E-A559-25D9D486B8D5@bellevuecollege.edu> <73a6d288-dc9a-0ab4-bb0e-635edcd456cd@lindenlab.com> <45E28F17-59E9-40C7-ABD0-22E4C3FC60AC@bellevuecollege.edu> Message-ID: On 2020-02-27 11:26 , Nathaniel Prugh wrote: > > Can you show me the links to announcement of new premium. Features > like the plus? > We have not yet announced the specific changes, just that some are coming including the new Premium Plus level.? Those should be coming pretty soon, but a search at https://community.secondlife.com/blogs will find many references. -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/8f7fbee8/attachment.htm From sldev at hotmail.com Thu Feb 27 09:37:43 2020 From: sldev at hotmail.com (Henri Beauchamp) Date: Thu, 27 Feb 2020 18:37:43 +0100 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: <20200227183743.d06e9c1115d41a2cf43388c2@hotmail.com> On Thu, 27 Feb 2020 11:10:19 -0500, Oz Linden (Scott Lawrence) wrote: > The definition of LLSD and our open source implementations of it have > always included the possibility of arbitrary nesting in arrays and maps > (and we use it extensively internally without problems). We're not able > to constrain our designs to maintain compatibility with incomplete > implementations we may not even know about, much less ones that are > unmaintained. 1.- To be more precise, the issue is not even about an array in a LLSD, but about a "structure" (xmlrpc_type_struct) in the XML RPC reply. Such structures were never used before and therefore the code for dealing with them was never implemented in many viewers (this got implemented sometime in LL's v3 code, which did not need to be backported back then since the said code was unused). So, it's not about a flawed or deprecated implementation from the viewer developers' part, but just about a new type of parameter passed on login, that was not expected by them ! 2.- Had you *simply* (this is really trivial, since this is how the viewers and login server already work !) respected the normal protocol, not sending any "account_level_benefits" related info to the viewers not requesting that option on login, there would not have been *any* problem ! NOTE THAT IT IS NOT TOO LATE: you could *still* modify the login server code to comply with the list of the requested options and stop sending the "account_level_benefits" stuff when not requested. This would *instantly* restore the compatibility with the old viewers, and all you would have to change in the new viewer code is to add: requested_options.append("account_level_benefits"); in LLLoginInstance::constructAuthParams() > That having been said, we'll try to provide more advance warning for > future changes when possible. Note that the further in advance the > notice comes, the less specific and actionable it can be. The simple fact of announcing the change (and explaining it) in Aditi after it was done and asking for testing and feedback would have avoided the entire mess... Draw your own conclusions about LL's communication and QA processes, but I'd personally say, based on observation of the result, that they are flawed. And by the way: On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: > The changes are in the 'DRTVWR-481 > ' branch in > the viewer git repository. > .../... > When can we release these changes? > > We strongly encourage you to integrate these changes as soon as > possible. You are free to begin incorporating the changes and releasing > them any time (but please watch for updates to them). Too bad... The only parameters currently sent in Agni by the login server are "additional_listing_cost" and "num_free_listings", and nothing else (in particular, no upload cost, no max group membership). So, should someone backport the changes as currently implemented in the repository you point at (i.e with the LLGlobalEconomy removed), they would end up with a non-functionnal viewer in SL ! 'nuff said ! Henri. From oz at lindenlab.com Thu Feb 27 11:39:10 2020 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 27 Feb 2020 14:39:10 -0500 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <20200227183743.d06e9c1115d41a2cf43388c2@hotmail.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> <20200227183743.d06e9c1115d41a2cf43388c2@hotmail.com> Message-ID: On 2020-02-27 12:37 , Henri Beauchamp wrote: > 2.- Had you*simply* (this is really trivial, since this is how the > viewers and login server already work !) respected the normal > protocol, not sending any "account_level_benefits" related info > to the viewers not requesting that option on login, there would > not have been*any* problem ! > > NOTE THAT IT IS NOT TOO LATE: you could*still* modify the login > server code to comply with the list of the requested options and > stop sending the "account_level_benefits" stuff when not requested. > This would*instantly* restore the compatibility with the old > viewers, and all you would have to change in the new viewer code > is to add: > requested_options.append("account_level_benefits"); > in LLLoginInstance::constructAuthParams() That protocol works (and from time to time we employ it) when the change is one that can be compatible, but that's not the case here. The account levels are not an optional thing, and there never was any way we could maintain backward compatibility on the server for viewers that don't get it. The fact that some incomplete XMLRPC implementations not based on ours failed when they shouldn't have isn't something we could have anticipated or done anything about. -- OZ LINDEN | VP Second Life Engineering email: oz at lindenlab.com | Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/de954b42/attachment-0001.htm From sldev at hotmail.com Thu Feb 27 12:16:26 2020 From: sldev at hotmail.com (Henri Beauchamp) Date: Thu, 27 Feb 2020 21:16:26 +0100 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> <20200227183743.d06e9c1115d41a2cf43388c2@hotmail.com> Message-ID: <20200227211626.1e1998da604f9459899ee02c@hotmail.com> On Thu, 27 Feb 2020 14:39:10 -0500, Oz Linden (Scott Lawrence) wrote: > That protocol works (and from time to time we employ it) when the change > is one that can be compatible, but that's not the case here. The account > levels are not an optional thing, and there never was any way we could > maintain backward compatibility on the server for viewers that don't get it. You said yourself that: " What will happen with unmodified viewers when the Premium changes go into effect? Most Second Life usage should be fine without the updates, but there may be subtle problems. For example, an unmodified viewer may have the wrong cost for some action; if the viewer expects the cost to be lower than the simulator does, the simulator will reject the request. " I see no mandatory change there, and no breakage in SL server side, so no risk whatsoever for the grid or its services... At worst, the old viewers will not be able to upload assets. Beside, as I already explained: " Which is NOT an issue for most old viewers; e.g. I was using OMV (that just got broken), but never used paying services with it... Another super-useful (actually pretty much *essential*) use case for "deprecated" viewers is to find the origin of a bug: "what was the last viewer version which did not have that bug ?" is the first question I pose to myself whenever a regression bug is found.Was it pre-BOM, pre- Animesh, pre-Materials, pre-whatever-shader-or-render-pipeline-change ? " For the above use cases, there is no issue whatsoever when the viewer does not know about the account level ! > The fact that some incomplete XMLRPC implementations not based on ours LOL !!!! Too bad for you: the implementation I used was the one LL wrote for v1 viewers ! So, that's *your* code, not mine ! Beside, the implementation was "complete" (and worked for over 14 years) for the parameters that were in use till you implemented that change without even letting us, TPV developers, test it and give feed back. Instead of apologizing properly and fixing the login server code to *NOT* send the extra info when not requested, you keep trying to find excuses and specious, illogical reasons to justify your failure. So lame... Henri. From soft at lindenlab.com Thu Feb 27 12:44:31 2020 From: soft at lindenlab.com (Brian McGroarty) Date: Thu, 27 Feb 2020 12:44:31 -0800 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: On Tue, Feb 25, 2020 at 12:17 PM Henri Beauchamp wrote: > Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers > (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) > do not know what to do with such an array (they can only deal with simple > key/value pairs, not with key/arrays); this was the case of my viewer > (but I thankfully and by pure "luck" noticed the issue a few weeks before > LL did stealthily modify the login server on the main grid, because the > beta grid already had the changes which caused me to fail to login in it > at that time, and I could diagnose and fix the issue). > All else aside: In the future, if you notice something on aditi adversely affects your viewer, please don't be shy about raising it on this list or in a JIRA. An early heads up may be helpful to other viewer devs, or it will make it more feasible for the company to alter or postpone a change. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/ea2a133c/attachment.htm From sldev at hotmail.com Thu Feb 27 13:07:34 2020 From: sldev at hotmail.com (Henri Beauchamp) Date: Thu, 27 Feb 2020 22:07:34 +0100 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: <20200227220734.434ef143245d3da89e842079@hotmail.com> On Thu, 27 Feb 2020 12:44:31 -0800, Brian McGroarty wrote: > All else aside: In the future, if you notice something on aditi adversely > affects your viewer, please don't be shy about raising it on this list or > in a JIRA. An early heads up may be helpful to other viewer devs, or it > will make it more feasible for the company to alter or postpone a change. Frankly, given the data that was transmitted on login on Aditi in the additional parameters (just a few meaningless strings, including a couple in Russian), I thought it was just a test for some more serious, to-be-announced-and-properly-QAed change that would be implemented later on... There was also, no trace of changes to the login parameters in the viewer(s) code on LL's git repository (no new viewer branch announced either, that would use those new parameters). I won't have imagined that such an essential component as the login server would see its protocol modified on Agni so stealthily and quickly, without even *some* forewarning... O.O Now, I know by experience this actually can happen ! :-/ Henri. From hw at adminart.net Thu Feb 27 13:16:18 2020 From: hw at adminart.net (hw) Date: Thu, 27 Feb 2020 22:16:18 +0100 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> Message-ID: <4448064.tgiy0OP7ku@toy.adminart.net> So after stealing my money you make stuff more expensive for everyone and try to either get rid of the users that aren't signed up or force them to sign up so that you can steal their money, too. How about you finally fix other problems like the block list not being loaded and making use of graphics cards that aren't a decade old first? On Tuesday, February 25, 2020 4:48:03 PM CET Oz Linden (Scott Lawrence) wrote: > ** > > *As we mentioned at the last Third Party Viewer meeting, the upcoming > changes to Premium levels will require some viewer updates to maintain > full compatibility.* > > * > > Why are there changes? > > The viewer currently has some messages and costs hard coded that will > need to be sensitive to the account type of the user. Rather than just > telling the viewer the users? account level (which we will also do) and > then putting code into the viewer to adjust based on that type, we have > built a more general solution. A new key ('benefits') in the LLSD map > returned by login identifies a map whose keys are "benefit tags" and > whose values are what that benefit level is for the logged-in user. > > For example, one of the benefit tags is "texture_upload_cost"; its value > is the number of L$ required for this user to upload a texture. The > viewer displays that cost in the upload dialog so that dialog must be > modified to use the value returned in the tag rather than the L$10 that > is currently hard coded. > > Where are the changes? > > The changes are in the 'DRTVWR-481 > ' branch in > the viewer git repository. A viewer built from that branch will be > available as a Release Candidate soon. > > When can we release these changes? > > We strongly encourage you to integrate these changes as soon as > possible. You are free to begin incorporating the changes and releasing > them any time (but please watch for updates to them). > > The login servers should already be returning the benefits information > (the values are the same as those currently in the viewer; they'll > change when we make the new Premium Plus level available and introduce > other changes to Premium). > > The simulator support for benefits is still being finalized and > deployed; they are just beginning to use the benefits information from > login in the same way this new viewer branch does. In practice, both > should arrive at the same numbers since the current benefits information > from login matches the old hard coded values. If your testing shows any > discrepancies, please report them via Jira as quickly as possible. > > What will happen with unmodified viewers when the Premium changes go > into effect? > > Most Second Life usage should be fine without the updates, but there may > be subtle problems. For example, an unmodified viewer may have the wrong > cost for some action; if the viewer expects the cost to be lower than > the simulator does, the simulator will reject the request. > > * From cinder at alchemyviewer.org Fri Feb 28 03:58:25 2020 From: cinder at alchemyviewer.org (Cinder Roxley) Date: Fri, 28 Feb 2020 03:58:25 -0800 Subject: [opensource-dev] Viewer changes for Premium changes In-Reply-To: References: <673cb25e-35c9-3bc7-607a-04f7fa311652@lindenlab.com> <20200225211710.8cc21507d72bf95446e9a0d9@hotmail.com> Message-ID: On February 27, 2020 at 10:10:28 AM, Oz Linden (Scott Lawrence) ( oz at lindenlab.com) wrote: On 2020-02-27 08:21 , Cinder Roxley wrote: On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sldev at hotmail.com) wrote: On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) do not know what to do with such an array (they can only deal with simple key/value pairs, not with key/arrays); this was the case of my viewer (but I thankfully and by pure "luck" noticed the issue a few weeks before LL did stealthily modify the login server on the main grid, because the beta grid already had the changes which caused me to fail to login in it at that time, and I could diagnose and fix the issue). Lost a day out of my weekend diagnosing and resolving this in LibreMetaverse/Radegast-ng. It really is a death blow to the unmaintained OMV library. Heads up before this kind of deployment would be very appreciated. The definition of LLSD and our open source implementations of it have always included the possibility of arbitrary nesting in arrays and maps (and we use it extensively internally without problems). We're not able to constrain our designs to maintain compatibility with incomplete implementations we may not even know about, much less ones that are unmaintained. Understood. Naturally, the onus for compatibility is on the client developer. In this case, the failure happened because the XmlRpc library being utilized is poor quality? most C# XmlRpc libraries are. This has been remedied in LibreMetaverse/Radegast. I had only wanted to mention advanced warning is appreciated because these ?rouge? implementations do exist and people use them to connect. Seconded. Always appreciated when API changes are documented on the wiki as well. I admit that I expected that an entry in a map that you didn't expect wouldn't be a problem; I assumed that it would be ignored (as it is in ours) and that it would be more useful to give you changes when there was something you could test against. I suggest that in the future your implementations be guided by Postel's Law. Indeed. I have no commit access to OMV (which is why I forked Libremetaverse) and a lot of it hrmmmm? questionable to say the least. :) That having been said, we'll try to provide more advance warning for future changes when possible. Note that the further in advance the notice comes, the less specific and actionable it can be. Thanks kindly, Oz. I do appreciate the notice and communication you and the rest of the lab have and do provide via this list, open e-mail inboxes, meetings, and wiki articles. It?s a lot more developer support than I?ve had from Mojang and other companies writing third party addons and I don?t take that for granted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200228/40439f6e/attachment.htm From tonya.souther at gmail.com Sat Feb 29 08:33:52 2020 From: tonya.souther at gmail.com (Tonya Souther) Date: Sat, 29 Feb 2020 10:33:52 -0600 Subject: [opensource-dev] macOS Catalina notarization Message-ID: Apple has tightened up their criteria for notarizing apps. For those of you not familiar with the issue, the current version of macOS, 10.15 Catalina, makes the user jump through some scary hoops to run an application they've downloaded unless it's been notarized - signed with an Apple Developer ID key and then checked by Apple. When Catalina first came out, Apple relaxed several requirements for notarization Their announcement is at https://developer.apple.com/news/?id=09032019a . Those changes have now been reversed, and all of the requirements they list have been met. I've spent the morning making viewer-manifest.py sign everything that's needed signing (apparently codesign --deep --force doesn't do that job any more). Unfortunately, there's still one major problem: there are 309 libraries that were built with an SDK older than 10.9. As Apple's notice says, that will cause notarization to be rejected. 305 of those libraries are in llplugin, and five are in the SLvoice for OpenSim. I don't expect that LL has anything to do with the latter, but the former is the much bigger problem. Is the llplugin directory still needed? If so, is there a good way to rebuild the lot? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200229/104f617f/attachment.htm From sldev at hotmail.com Sat Feb 29 10:18:22 2020 From: sldev at hotmail.com (Henri Beauchamp) Date: Sat, 29 Feb 2020 19:18:22 +0100 Subject: [opensource-dev] macOS Catalina notarization In-Reply-To: References: Message-ID: <20200229191822.78b52271193ee50cb8f39efa@hotmail.com> On Sat, 29 Feb 2020 10:33:52 -0600, Tonya Souther wrote: > 305 of those libraries are in llplugin, and five are in the SLvoice > for OpenSim. I don't expect that LL has anything to do with the > latter, but the former is the much bigger problem. Is the llplugin > directory still needed? My bet is that those 305 non-signed libraries are in fact VLC's ones... One more reason not to use VLC and to use gstreamer instead: the user may install gstreamer separately on their system (with the proper signing by the gstreamer upstream provider), and you won't need to bundle a shitload of libraries with each binary package of your viewer. Henri. From tonya.souther at gmail.com Sat Feb 29 12:39:23 2020 From: tonya.souther at gmail.com (Tonya Souther) Date: Sat, 29 Feb 2020 14:39:23 -0600 Subject: [opensource-dev] macOS Catalina notarization In-Reply-To: <20200229191822.78b52271193ee50cb8f39efa@hotmail.com> References: <20200229191822.78b52271193ee50cb8f39efa@hotmail.com> Message-ID: I've now built a VLC 3.0.8 package, and it at least allows the app to be notarized. Haven't wrung it ot yet; not sure I know how, but our beta testers will, I'm sure, let me know if it's screwed up. On Sat, Feb 29, 2020 at 12:18 PM Henri Beauchamp wrote: > On Sat, 29 Feb 2020 10:33:52 -0600, Tonya Souther wrote: > > > 305 of those libraries are in llplugin, and five are in the SLvoice > > for OpenSim. I don't expect that LL has anything to do with the > > latter, but the former is the much bigger problem. Is the llplugin > > directory still needed? > > My bet is that those 305 non-signed libraries are in fact VLC's ones... > > One more reason not to use VLC and to use gstreamer instead: the user > may install gstreamer separately on their system (with the proper > signing by the gstreamer upstream provider), and you won't need to > bundle a shitload of libraries with each binary package of your viewer. > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200229/91309088/attachment.htm From geir.noklebye at dayturn.com Sat Feb 29 12:51:52 2020 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Sat, 29 Feb 2020 21:51:52 +0100 Subject: [opensource-dev] macOS Catalina notarization In-Reply-To: References: Message-ID: It is not only that you have unsigned libraries, but there are two other issues: 1. The Chromium Framework is not correctly structured, but must have the structure described in https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html to be properly signed for notarization. 2. The plugins must be signed with --options runtime or the notarization request comes back with the error status "The executable does not have the hardened runtime enabled." ...and you can sign it with that option - which will let the viewer be notarized, as I managed to do once before February 3 and they tightened the rules. The problem is then that the plugin (particularly the SL Plugin) does not communicate with the main application at all as they are both executing in their own sandboxes. I have an open issue with Apple Developer support on notarization, but the only thing they say are: build in Xcode, sign properly and enable hardened runtime on everything. They cannot provide any support for building with third party systems like cmake etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200229/61bc39e4/attachment.htm From geir.noklebye at dayturn.com Sat Feb 29 13:24:15 2020 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Sat, 29 Feb 2020 22:24:15 +0100 Subject: [opensource-dev] macOS Catalina notarization In-Reply-To: References: Message-ID: When it comes to deployment target, I see that in https://bitbucket.org/lindenlab/build-variables/src/master/variables which I suppose is the latest build variables used, you build with deployment target of 10.7 and with the 10.11 SDK??! LL_BUILD_DARWIN_BASE_SWITCHES="-fPIC -gdwarf-2 -stdlib=libc++ -mmacosx-version-min=10.7 -iwithsysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/" What gives? - You should not build with a deployment target of anything less than 10.12 for multiple reasons, the most important that Apple in 10.12.6 finally fixed an issue that was introduced in 10.11 that made the macOS version of the viewer crash constantly. Running the viewer on anything pre 10.12 is at this time pointless because every Apple system that can run 10.10 can also run 10.12, and 10.10 is out of support in the same manner as Windows 7 is out of support. If you build with Xcode 11.3 on Catalina you should build with the 10.15 SDK, or if on Xcode 10.3 on 10.14 with the 10.14 SDK. I assume the libs are built with the same target and even older SDKs (have not checked all of them). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200229/8aaabcad/attachment.htm From tonya.souther at gmail.com Sat Feb 29 13:34:40 2020 From: tonya.souther at gmail.com (Tonya Souther) Date: Sat, 29 Feb 2020 15:34:40 -0600 Subject: [opensource-dev] macOS Catalina notarization In-Reply-To: References: Message-ID: I was able to get a successful notarization. I did not have to do anything to CEF to get it to fly, though I did have to use the --options runtime flag. We'll see what testing reveals as the effect of that. That they tightened down things as of the beginning of February explains why the notarization I ran on January 15 worked but ones this week didn't. On Sat, Feb 29, 2020 at 2:52 PM Geir N?klebye wrote: > It is not only that you have unsigned libraries, but there are two other > issues: > > 1. The Chromium Framework is not correctly structured, but must have the > structure described in > https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html to > be properly signed for notarization. > > 2. The plugins must be signed with --options runtime or the notarization > request comes back with the error status "The executable does not have > the hardened runtime enabled." > > ...and you can sign it with that option - which will let the viewer be > notarized, as I managed to do once before February 3 and they tightened the > rules. > > The problem is then that the plugin (particularly the SL Plugin) does not > communicate with the main application at all as they are both executing in > their own sandboxes. > > I have an open issue with Apple Developer support on notarization, but the > only thing they say are: build in Xcode, sign properly and enable hardened > runtime on everything. They cannot provide any support for building with > third party systems like cmake etc. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200229/20d202d9/attachment.htm