| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
In a Windows build tree, we don't actually have an app-named top directory, so
don't package its containing directory -- just the app dir itself, e.g.
"newview/Release".
In a Mac build tree, though we do have "Second Life Mumble.app", its parent
directory also contains other large stuff. Try posting a temp directory
containing a symlink to the .app.
Ditch the "!*.bat" exclusion: the presence of a second path (even an
exclusion) changes how upload-artifact nests its contents.
|
|
See 7dd1149e3649057f0962b85bdc467f4e9299b235.
The attributes only needed to be moved from LLWindowMacOS X to LLWindowSDL.
|
|
|
|
|
|
wip
|
|
|
|
|
|
until we're ready with CPack for it.
|
|
|
|
|
|
|
|
|
|
So that, especially modern, GL implementations that do have vertex array
but don't have the legacy GL_ARB_vertex_array_object defined have such
code compiled too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously we posted Windows-exe, macOS-exe artifacts that were a little
inconsistent: Windows-exe contained just the Windows executable, whereas
macOS-exe contained the whole .app tree (but without the .app directory).
Change to post Windows-app, macOS-app artifacts that each contain the whole
viewer install image, including the top-level application name directory. This
is what we'll need to codesign and notarize.
|
|
|
|
|
|
replacing their legacy ARB counterparts.
|
|
replacing their legacy ARB counterparts.
|
|
(cherry picked from commit 3d2da2b2c09fc637c2eaccac1607e3480bede145)
|
|
at the same time revert to less difference from upstream.
|
|
in the path passed as the macOS viewer_exe GitHub output.
|
|
On Mac, in the CMake USE_BUGSPLAT logic, we created both xcarchive.zip (which
is what BugSplat wants to see) and secondlife-symbols-darwin -64.tar.bz2 (which
we don't think is used for anything). The tarball was posted to codeticket --
but why? If the point is to manually re-upload to BugSplat in case of failure,
we'll do better saving xcarchive.zip to codeticket.
For SL-19243, posting xcarchive.zip directly supports the goal of breaking out
the upload to BugSplat as a separate step.
Anyway, since xcarchive.zip is a superset of the tarball, the tarball can be
recreated from the zip file, whereas the zip file can't be recreated from the
tarball without opening the .dmg installer and extracting the viewer executable.
If the xcarchive.zip file exists (that is, on Mac), post that to codeticket or
GitHub, as applicable, instead of the tarball. In fact, in the USE_BUGSPLAT
case, don't even bother creating the tarball since we're going to ignore it.
Make the new build.sh logic that insists on BUGSPLAT_USER and BUGSPLAT_PASS
conditional on BUGSPLAT_DB.
|
|
|
|
|
|
Use a retry loop very like the code-signing retry loop.
|
|
Upload a new Windows-exe artifact containing just the executable (needed by
BugSplat) separately from the artifact containing the whole NSIS installer.
This requires a new viewer_exe step output set by viewer_manifest.py.
Define viewer_channel and viewer_version as build job outputs.
Set viewer_channel in build.yaml when tag is interpreted.
Set viewer_version in build.sh at the point when it would have posted
viewer_version.txt to codeticket.
Add a post-windows-symbols job dependent on the build job that engages
secondlife/viewer-post-bugsplat-windows, which in turn engages
secondlife/post-bugsplat-windows. We keep the actual upload code in a separate
repo in case we need to modify that code before rerunning to resolve upload
errors. If we kept the upload code in the viewer repo itself, rerunning the
upload with modifications would necessarily require rerunning the viewer
build, which would defeat the purpose of SL-19243.
Because of that new upload job in build.yaml, skip Windows symbol uploads
in build.sh.
Use a simple (platform name) artifact name for metadata because of
flatten_files.py's filename collision resolution.
Use hyphens, not spaces, in remaining artifact names: apparently
download-artifact doesn't much like artifacts with spaces in their names.
Only run the release job when in fact there's a tag. Without that, we get
errors. We need not create flatten_files.py's output directory beforehand
because it will do that implicitly.
|
|
|
|
The line that enables it in when on external TOS was only present in a
similar scope which doesn't seem to be reachable. It must have been missed
when the condition checking was moved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://secondlife.com/corporate/third-party-viewers
Section 5.c
|
|
First, in order for launch_url.sh to be executable, it needs to be
installed as a program.
Secondly, the spawn browser command path needs to be adjusted
accordingly.
And last, add chrome (applies to chromium too on FBSD), to the list of
browser commands to try (so chrome wasn't there :/, but dillo has always
been XD, and that's why it kept opening Dillo here haha).
|
|
When I tried using, for example, FBSD system's ca-root-nss.crt, at
runtime, the viewer would fail at downloading textures, avatar names,
and so on. So for now we're still relying on LLCA, it's just get
installed automatically without having to track the file in the viewer
project.
|
|
|
|
Since we could use the dynamic versioning from the configuration phase
of CMake, the inclusion is put in BuildVersion.cmake.
Other CPACK variables are usually static so can be set when running
cmake.
CPack somehow doesn't pick up the DESTINATION values in ViewerInstall
(slplugin & libvlc too) from UnixInstall, so they're they're partially
hardcoded again there.
|
|
|
|
|
