These are chat archives for highfidelity/hifi

26th
Apr 2018
Christoph Haag
@ChristophHaag
Apr 26 2018 18:20
does the website show the current beta release number somewhere? it's been removed from the download site
i mean the specific tag you should use to connect to the current "stable" domains. it's not in the steam news either..
Christoph Haag
@ChristophHaag
Apr 26 2018 18:27
maybe git tags like beta-66 could be added
Clément Brisset
@Atlante45
Apr 26 2018 18:29
To connect to stable domain, you should use the tip of the stable branch.
We're also changing the release process, probably with the next release.
Christoph Haag
@ChristophHaag
Apr 26 2018 18:30
oh cool, didn't see that. thanks
btw it was said all activity from gitter is to be migrated to the forums but the github readme still advertises the gitter channel
Clément Brisset
@Atlante45
Apr 26 2018 18:31
master builds won't get tags anymore, they'll have a version number and a small SHA to be able to find the commit.
And the RCs will be the only ones getting tags on the form v0.Y.Z
Oh, thanks for the info.
@themelissabrown ^
Christoph Haag
@ChristophHaag
Apr 26 2018 18:35
let's see if that quazip issue is still happening...
still make[3]: *** No rule to make target 'ext/makefiles/quazip/project/lib/libquazip5.so', needed by 'plugins/hifiSdl2/libhifiSdl2.so'. Stop.
someone theorized it could be automagically required by qt to pack some resources like fonts...
Christoph Haag
@ChristophHaag
Apr 26 2018 18:48
Oh I get it, ext/makefiles/quazip/project/lib/libquazip5d.so
Clément Brisset
@Atlante45
Apr 26 2018 18:49
No, quazip is one of our dependencies.
But it should be taken care of automatically by cmake.
That's odd, there must be a bug in cmake for linux.
Christoph Haag
@ChristophHaag
Apr 26 2018 18:50
I think it happens when you build with -DCMAKE_BUILD_TYPE=Debug. then libquazip5.so is called libquazip5d.so instead
I think libglew did the same thing
Christoph Haag
@ChristophHaag
Apr 26 2018 18:56
yea it had two different library names and presumably the cmake files somewhere else referencing glew had to choose the right one based on build type https://github.com/highfidelity/hifi/blob/RELEASE-7607/cmake/externals/glew/CMakeLists.txt#L33-L34
Christoph Haag
@ChristophHaag
Apr 26 2018 19:14
bad sign when I have to remove the dust from my vive controllers before usage :/
Clément Brisset
@Atlante45
Apr 26 2018 19:15
=/
Christoph Haag
@ChristophHaag
Apr 26 2018 19:16
ah I remember, I wanted to try debugging why renderContext->args->getViewFrustum() is null
and that's why I built with -DCMAKE_BUILD_TYPE=Debug, because it's a bit annoying when every value is being optimized out
Christoph Haag
@ChristophHaag
Apr 26 2018 19:22
looks like git bisect will be easier
Christoph Haag
@ChristophHaag
Apr 26 2018 19:40
I'll try later
Christoph Haag
@ChristophHaag
Apr 26 2018 20:55
turns out bisecting doesn't work so well when you have to apply a couple of patches that have to change over the revision history. and applying the patches on the good commit and merging the bad one, just doesn't bisect right. the "most correct" way would probably to rebase the bad commit on the good commit with applied patches, but that just creates masses of unrelated merge conflicts...
Christoph Haag
@ChristophHaag
Apr 26 2018 21:22
yea debug works with that patch
#4  0x00005555574c4df7 in DebugSubsurfaceScattering::run (this=0x5555640e1108, renderContext=std::shared_ptr (count 1, weak 0) 0x555559387280, inputs=...)
    at /home/chris/oldhome/build/hifi/hifi/libraries/render-utils/src/SubsurfaceScattering.cpp:511
511         assert(renderContext->args->hasViewFrustum());
somewhere between RELEASE-7995 and RELEASE-8108 there was a change that got this viewfrustrum to be null when enabling the openvr plugin to linux. people wouldn't by chance happen to know about this here?
Christoph Haag
@ChristophHaag
Apr 26 2018 22:13
there has to be some code related to the openvr plugin that only runs on windows and sets the frustum but I don't see it... maybe tomorrow...