Snowglobe is the name of a new viewer (in development) for Second Life. --- Attached there is a first attempt ebuild for feedback and suggestions.
Hey Mauro, can you attach the ebuild? I'll give it a try. Oh, and is tut required, or just nice to have for snowglobe?
Assign to maintainer-wanted and adding as depend xmlrpc-epi amd64 keywording. I know this bug is not really a depend as the ebuild can be keyworded for something else but it will recall xmlrcp-epi should be used.
Created attachment 197073 [details] games-simulation/snowglobe-1.0.2.ebuild
Created attachment 197075 [details, diff] snowglobe-1.0.2-flags.patch
Created attachment 197076 [details, diff] snowglobe-1.0.2-gcc-4.3.patch
Created attachment 197077 [details, diff] snowglobe-1.0.2-test.patch
Created attachment 197081 [details] games-simulation/snowglobe-1.0.2.ebuild
some sparse notes: 1) despite of what the SecondLife Wiki tells, there are only two optional dependencies: - openal; - fmod; all the other dependencies are required, some of which are not documented, for example the Wiki declare Vivox[1] as a dependency but do not specify that it's a prebuild 32bit binary that requires emul-linux on 64bit machine. 2) I'm quite sure that there are some missing DEPENDS as this ebuild is just a preliminary work, later I'll do a more deeper test on a clean stage3. 3) Tut is required as a dependency to run the unit tests, but unfortunately they are always executed, so I have done a quick-&-dirty workaround to make them optional with the use 'test'; later I'll do a proper fix to the CMake files (it's a huge task and not urgent now so it's on the bottom of my TODO). 3) the ebuild requires the patch named: files/snowglobe-1.0.2-linden.patch, but is missing on this bugreport as it's a work (quite unstable) in progress of reverted patches from Linden SVN; to test the ebuild just create an empty file. 4) @lavajoe, all the SL viewers needs Vivox[1] for voice chat support, so the games-simulation/secondlife package lacks it and it's the cause of the problems you reported me by email. 5) games-simulation/snowglobe can be used as a skel for games-simulation/secondlife, mainly the part regarding CMake configure/compilation. [1] http://vivox.com
Created attachment 197096 [details] games-simulation/snowglobe-1.0.2.ebuild this is an improved version with proper support for dev-games/libndofdev from bug 276945 (cleaned up some redundant DEPENDS).
Mauro, I tried this on my amd64 machine, and once I got it built, it seemed to hang at high CPU usage - I only let it go a few minutes. Do you know what might be happening? Also, a few things: 1) Why do we need to download slviewer-libs? I didn't look into it here, but it is not needed for the secondlife ebuild. 2) If the versioning is similar to the slviewer (secondlife) src, should it really be 1.0_rc2 instead? 3) RDEPEND is usually a superset of DEPEND (since in theory, RDEPENDS can be emerged after the package - although that is not done). Anything that is needed to compile this package should be in DEPEND and not just RDEPEND, so we should reverse the sense of this. 4) with USE flag "fmod", the compile fails - wrong path to includes (cannot find, e.g., fmod.h, which is down in /opt)? Note it compiles with USE="-fmod". 5) Rather than using an empty linden patch file, why not just comment out that epatch for now? 6) What about the bit about chgrp'ing to group 'games' and needing to be part of group 'games' (as in the secondlife build)? Note: I'm not sure this is "mandatory", but seems usual for games. 7) Need to put snowglobe in /usr/bin, not in /usr/games/bin (won't run - script could not find /usr/bin/snowglobe, plus /usr/games is a non-gentoo area) 8) Along the same lines, you want to put /usr/share/ files in /usr/share/snowglobe, and not in /usr/share/games/snowglobe
> Mauro, I tried this on my amd64 machine, and once I got it built, it seemed to > hang at high CPU usage - I only let it go a few minutes. Do you know what > might be happening? Joe, can you start snowglobe in console and nopaste me all the logs of the client? thank you. > 1) Why do we need to download slviewer-libs? I didn't look into it here, but > it is not needed for the secondlife ebuild. Yes, it's required, without it the client do not start: http://wiki.secondlife.com/wiki/Source_downloads > 2) If the versioning is similar to the slviewer (secondlife) src, should it > really be 1.0_rc2 instead? I have better watched the Wiki and I'll rename the ebuild today, together with some more enhancements. > 3) RDEPEND is usually a superset of DEPEND (since in theory, RDEPENDS can be > emerged after the package - although that is not done). Anything that is > needed to compile this package should be in DEPEND and not just RDEPEND, so we > should reverse the sense of this. Check yourself the RDEPENDS: qlist snowglobe | scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -C | sort -u as you can see, the RDEPENDS are right, but as I have told in my previous comment, DEPENDS are not been checked; I need to compile/deploy the application on a clean stage3 to do it and until now all the DEPENDS has been reversed by me just reading the CMake/C++ code, so surely there are missing/redundant DEPENDS (i need to find some free time to create two new chroot for testing). > 4) with USE flag "fmod", the compile fails - wrong path to includes (cannot > find, e.g., fmod.h, which is down in /opt)? Note it compiles with USE="-fmod". can you send me the log of the compilation with all the errors? fmod is a required dependency, so it can be the cause of your high cpu usage. > 5) Rather than using an empty linden patch file, why not just comment out that > epatch for now? today I'll add a non empty patch with some fix reverted by the main trunk. > 6) What about the bit about chgrp'ing to group 'games' and needing to be part > of group 'games' (as in the secondlife build)? Note: I'm not sure this is > "mandatory", but seems usual for games. Yesterday, before to sleep, I was pondering the same thing until I hit this page: https://lists.secondlife.com/pipermail/sldev/2008-November/012296.html so I suggest to move away secondlife from the category 'games-simulation' as it's not a game, indeed it's a 3D Instant Messanger[1][2]; "net-im/snowglobe" and "net-im/secondlife" can be a good solution? > 7) Need to put snowglobe in /usr/bin, not in /usr/games/bin (won't run - script > could not find /usr/bin/snowglobe, plus /usr/games is a non-gentoo area) obiovously, changing the ebuild category means also changing the installation path, which should be: /usr/share/snowglobe > 8) Along the same lines, you want to put /usr/share/ files in > /usr/share/snowglobe, and not in /usr/share/games/snowglobe see previous point. I have just done all the ebuild modifications for point 6, 7, 8 and if you have other considerations or suggestions about them, tell me, so I can change the ebuild before to submit here. Thank you very much for the precious suggestion Joe. [1] https://jira.secondlife.com/browse/WEB-330 [2] http://secondlife.com/whatis/faq.php#02
(In reply to comment #11) > Joe, can you start snowglobe in console and nopaste me all the logs of the > client? thank you. Hmm, well there was no console output during this period. I do not see any log files created... > > 3) RDEPEND is usually a superset of DEPEND (since in theory, RDEPENDS can be > > emerged after the package - although that is not done). Anything that is > > needed to compile this package should be in DEPEND and not just RDEPEND, so we > > should reverse the sense of this. > > Check yourself the RDEPENDS: > qlist snowglobe | scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -C | > sort -u Ah, good. Well, in practice, I would typically consider that most things anything in RDEPEND must also be in DEPEND, since if you need the lib at runtime, you probably had to link with it. There are exceptions, but in general, it should be safe to do something like I did in the secondlife build. Of course, some of those are overkill... It might be a good 'gentoo philosophy' question to ask. > > 4) with USE flag "fmod", the compile fails - wrong path to includes (cannot > > find, e.g., fmod.h, which is down in /opt)? Note it compiles with USE="-fmod". > > can you send me the log of the compilation with all the errors? fmod is a > required dependency, so it can be the cause of your high cpu usage. OK, I'll attach this. BTW, if it is a "required dependency", then you may not want to let the user remove it via the USE flag. > > 6) What about the bit about chgrp'ing to group 'games' and needing to be part > > of group 'games' (as in the secondlife build)? Note: I'm not sure this is > > "mandatory", but seems usual for games. > > Yesterday, before to sleep, I was pondering the same thing until I hit this > page: https://lists.secondlife.com/pipermail/sldev/2008-November/012296.html > > so I suggest to move away secondlife from the category 'games-simulation' as > it's not a game, indeed it's a 3D Instant Messanger[1][2]; "net-im/snowglobe" > and "net-im/secondlife" can be a good solution? Well, although I agree that most do not consider SL a "game", for the purposes of selecting a gentoo category, it probably fits. Another option that I considered is "app-simulation", but the other packages in there do not seem to fit as well as games. I would definitely *not* say this is a "net-im" package. SL is a lot more than an instant messenger. Even though you can IM people in the world, there are many, many other things you can do in SL. > > 7) Need to put snowglobe in /usr/bin, not in /usr/games/bin (won't run - script > > could not find /usr/bin/snowglobe, plus /usr/games is a non-gentoo area) > > obiovously, changing the ebuild category means also changing the installation > path, which should be: /usr/share/snowglobe Ah, I was wrong about /usr/games/bin - assuming we keep it in games-simulation, this is correct. Just need to change the script to use the right path. > > 8) Along the same lines, you want to put /usr/share/ files in > > /usr/share/snowglobe, and not in /usr/share/games/snowglobe This one, however, should not be /usr/games/share - should be in /usr/share/${PN}, as you've done. Thanks for all of your efforts! This is a lot of work.
Created attachment 197166 [details] Build log showing failure when USE="fmod"
> Hmm, well there was no console output during this period. I do not see any log > files created... very strange behaviour, here I have a lot of console logs when i start the client. > Ah, good. Well, in practice, I would typically consider that most things > anything in RDEPEND must also be in DEPEND, since if you need the lib at > runtime, you probably had to link with it. There are exceptions, but in > general, it should be safe to do something like I did in the secondlife build. I disagree, cmake, elfio, expat are not RDEPENDS, indeed you can safely run snowglobe/secondlife without them; the purpose of the shell command that I have pointed out above is to figure out all the runtime dependencies, this mean that all the other dependencies required during compilations are just DEPENDS. > > > 4) with USE flag "fmod", the compile fails - wrong path to includes (cannot > > > find, e.g., fmod.h, which is down in /opt)? Note it compiles with USE="-fmod". Very good, it's a CMake macro error (just fixed now,later i'll upload a new ebuild revision) as on the binary distros the headers of fmod are usually installed in /usr/include; however I have seen now that there is a new fmod release (4.26) with a FLAC fix for linux[1], maybe it's worth to do a bump request and test the new release with secondlife/snowglobe. > OK, I'll attach this. BTW, if it is a "required dependency", then you may not > want to let the user remove it via the USE flag. sorry, the "required" word was a bad choice; I was meaning another thing, that is you enable sounds effects but the viewer is compiled without fmod, probably the load on cpu is more higher than with fmod. > [CUT]a lot of stuff about ebuild categoring[/CUT] I agree, the right defition for SL is: MMO, and there is not a portage category that fits it. Keeping secondlife/snowglobe into games-simulations is ok for me, we need just to fix the installation paths and the *.desktop file as it's broken (point to the wrong binary). the desktop file issue give me up another question: the binary name of snowglobal is "secondlife-bin", can be possibly conflicts/collisions with the games-simulation/secondlife packages? If there are, still exists an undocumented option to change the binary name: -DBINARY_NAME:STRING= (just in case), so people can have multiple viewers installed and concurrent viewers executed. > Thanks for all of your efforts! This is a lot of work. ... and there is more to do (unfortunately)! [1] http://www.fmod.org/files/revision_stable.txt
(In reply to comment #14) > very strange behaviour, here I have a lot of console logs when i start the > client. Ah!! OK, duh... I did not realize the name of the binary. I simply changed /usr/bin/snowglobe (last line of the script) to /usr/games/bin/snowglobe, cause an infinite loop in the script! Haha... mystery solved. Works now. > I disagree, cmake, elfio, expat are not RDEPENDS, indeed you can safely run > snowglobe/secondlife without them; the purpose of the shell command that I have > pointed out above is to figure out all the runtime dependencies, this mean that > all the other dependencies required during compilations are just DEPENDS. Yes, true enough. I totally agree about cmake, etc. And good point about the others. Now, if, say, a package provides a static lib, that would only be needed at build, but should the package "stay on the system" while the running package is installed? Not sure the ramifications of portage in terms of how deep dependencies are dealt with, depclean, etc... > Very good, it's a CMake macro error (just fixed now,later i'll upload a new > ebuild revision) as on the binary distros the headers of fmod are usually > installed in /usr/include; however I have seen now that there is a new fmod > release (4.26) with a FLAC fix for linux[1], maybe it's worth to do a bump > request and test the new release with secondlife/snowglobe. Sure, except the latest fmod in the tree installs in /opt, and I'm sure the newer one will be kept that way as well (bug #252400). So if you get snowglobe working with it, hopefully it will work with the newer one, too. > the desktop file issue give me up another question: the binary name of > snowglobal is "secondlife-bin", can be possibly conflicts/collisions with the > games-simulation/secondlife packages? If there are, still exists an > undocumented option to change the binary name: -DBINARY_NAME:STRING= (just in > case), so people can have multiple viewers installed and concurrent viewers > executed. Well, currently, the package secondlife-bin installs /usr/games/bin/secondlife-bin, and secondlife installs /usr/games/bin/secondlife. So at the moment, there is no collision. However, I think we should force the binary to be "snowglobe". Now, how to resolve the fact that there is a starup script and an actual binary...not sure, since to me "-bin" implies it's a binary *package*. For "secondlife", I resolved this by having the actual binary in the library area with the rest of the libs. The scripts then sets that as the working dir and executes the binary there. But I do not let the default install process run - I do it manuall in that ebuild. Let me know what you think will work to remain consistent. Clearly, using /usr/bin/secondlife-bin is not good, since it is confusing regarding the secondlife-bin pkg, and it is not consistent with putting game bins either in /usr/games or elsewhere (like inthe library area as in the secondlife builds).
> Sure, except the latest fmod in the tree installs in /opt, and I'm sure the > newer one will be kept that way as well (bug #252400). So if you get snowglobe > working with it, hopefully it will work with the newer one, too. I have forced >=fmod-4.25.00 as a minimun requirement and passed the option: -DFMOD_SDK_DIR:STRING=/opt/fmodex to CMake (yeah, another undocumented SL cmake option), plus a little patch to the CMake macro to lets find fmod libraries (since v4.x the libraries name are changed). Here, on a 32bit, the configuration process is working, compilation too and *finally* the viewer sound stopped to be laggy (I'm able to get ~10FPS on a cheap Intel G3100 and the viewer is usable/smoother, which is a great result if you think that with the same hardware, but on Windows, the viewer never go over ~2FPS and it's not usable at all). p.s.: i'm using the new fmod-4.26: bug 277039 > Well, currently, the package secondlife-bin installs > /usr/games/bin/secondlife-bin, and secondlife installs > /usr/games/bin/secondlife. > > So at the moment, there is no collision. However, I think we should force the > binary to be "snowglobe". Well no, the collision there is, as also snowglobe have "secondlife-bin" as binary name, so i suggest to rename binaries from both the clients with: -DBINARY_NAME:STRING=${PN}. > Now, how to resolve the fact that there is a starup > script and an actual binary...not sure, since to me "-bin" implies it's a > binary *package*. For "secondlife", I resolved this by having the actual > binary in the library area with the rest of the libs. The scripts then sets > that as the working dir and executes the binary there. But I do not let the > default install process run - I do it manuall in that ebuild. Let me know what > you think will work to remain consistent. Clearly, using > /usr/bin/secondlife-bin is not good, since it is confusing regarding the > secondlife-bin pkg, and it is not consistent with putting game bins either in > /usr/games or elsewhere (like inthe library area as in the secondlife builds). > the script that wrap the 'secondlife-bin' binary come out from the game-utils eclass and now that we have decided to let the ebuild inside the category 'games-simulation' but install it without the game eclass the script is gone; forcing the renaming of the bins, with the CMake option, solved also the problem of the confusing -bin suffix, and I agree with you, the suffix must be used only for the pre-built release.
Created attachment 197226 [details] games-simulation/snowglobe-1.0.2.ebuild
Mauro, Can you attached the cmake and linden patch files? I got the ebuild - ready to test as soon as I have these.
Created attachment 197286 [details] games-simulation/snowglobe-1.0_rc2.ebuild sorry for the delay, I had DSL problems.
Created attachment 197288 [details, diff] snowglobe-1.0_rc2-cmake.patch
I'm still getting an issue finding fmod headers: [ 3%] In file included from /var/tmp/portage/games-simulation/snowglobe-1.0_rc2/work/linden/indra/llaudio/audioengine_fmod.cpp:35: /var/tmp/portage/games-simulation/snowglobe-1.0_rc2/work/linden/indra/llaudio/audioengine_fmod.h:41:18: error: fmod.h: No such file or directory /var/tmp/portage/games-simulation/snowglobe-1.0_rc2/work/linden/indra/llaudio/audioengine_fmod.cpp:43:25: error: fmod_errors.h: No such file or directory I have media-libs/fmod-4.25.07-r1 installed. Could it be different than the 4.26 you are testing against? Is there a way to make it work with 4.25.07-r1?
I'm at fmod-4.26.00 now... still cannot build. See attachment.
Created attachment 197749 [details] Build failure with new fmod
