Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to install on Fedora/openSUSE via any method #317

Closed
GeoDerp opened this issue Feb 2, 2022 · 12 comments
Closed

Unable to install on Fedora/openSUSE via any method #317

GeoDerp opened this issue Feb 2, 2022 · 12 comments

Comments

@GeoDerp
Copy link

GeoDerp commented Feb 2, 2022

Greetings,
I have had a lot of issues trying to install sunshine using Fedora. Have attempted to create my own rpm, however there is no known version of gcc and gcc-c++ that is low enough to support this the sunshine cmake build.

[   40s] -- Found Boost: /usr/lib64/cmake/Boost-1.78.0/BoostConfig.cmake (found suitable version "1.78.0", minimum required is "1.53.0") found components: system thread 
[   40s] -- Found OpenSSL: /usr/lib64/libcrypto.so (found version "1.1.1m")  
[   40s] CMake Error at /usr/lib64/cmake/Boost-1.78.0/BoostConfig.cmake:141 (find_package):
[   40s]   Found package configuration file:
[   40s] 
[   40s]     /usr/lib64/cmake/boost_log-1.78.0/boost_log-config.cmake
[   40s] 
[   40s]   but it set boost_log_FOUND to FALSE so package "boost_log" is considered to
[   40s]   be NOT FOUND.  Reason given by package:
[   40s] 
[   40s]   No suitable build variant has been found.
[   40s] 
[   40s]   The following variants have been tried and rejected:
[   40s] 
[   40s]   * libboost_log.so.1.78.0 (shared, Boost_USE_STATIC_LIBS=ON)
[   40s] 
[   40s] Call Stack (most recent call first):
[   40s]   /usr/lib64/cmake/Boost-1.78.0/BoostConfig.cmake:262 (boost_find_component)
[   40s]   /usr/share/cmake/Modules/FindBoost.cmake:594 (find_package)
[   40s]   CMakeLists.txt:27 (find_package)
[   40s] 

This also makes creating a container (or using toolbox) to build quite a challenge. (And I don't have the skillet to convert this tool into a flatpak yet)

I have also attempted to use alien to convert the deb into a rpm and have had no success with this also:

error: File must begin with "/": docker/sunshine-0.11.1/usr/lib/.build-id
error: File must begin with "/": docker/sunshine-0.11.1/usr/lib/.build-id/91
error: File must begin with "/": docker/sunshine-0.11.1/usr/lib/.build-id/91/39db1c825b5dbb22ce36edf92a621602bc786a

Some ideas:

  • find a way to build and run the application in a container
  • upgrade application to support latest gcc and gcc-c++ to increase newer repo support
  • add support and create a flatpak

Any ideas?
Happy to help,
Thanks

@ReenigneArcher
Copy link

If you have experience making an rpm, we would very much appreciate your assistance.

LizardByte/Sunshine#7

We already are building on Fedora 33 and 35 using dockerfiles and this is tested during PR checks. https://github.com/SunshineStream/Sunshine/tree/master/scripts

Note: This repo is separate from Loki's.

@okkiv
Copy link

okkiv commented Feb 4, 2022

If it is of any help, I can build sunshine on fedora 35 through toolbox, which creates a podman container with access to your filesystem but doesn't clutter your system with development libs:

toolbox create sunshine-build-f35
toolbox enter sunshine-build-f35

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install gcc g++ cmake boost-devel boost-static openssl-devel ffmpeg-devel libopusenc-devel libXfixes-devel libX11-devel libevdev-devel pulseaudio-libs-devel libXrandr-devel libdrm-devel libcap-devel wayland-devel

echo git clone https://github.com/loki-47-6F-64/sunshine.git --recurse-submodules && cd sunshine
mkdir build && cd build
cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ ..
make -j ${nproc}

exit

cd build
sudo setcap cap_sys_admin+p sunshine

I can then start it on my host with ./sunshine
I haven't looked up creating an rpm, yet. I might give building an appimage a try, though

@ReenigneArcher
Copy link

I might give building an appimage a try, though

We do have an AppImage over at the SunshineStream repo. Well to clarify, it is building and will be published as a release on our first release (should be relatively soon). It may or may not work on all distros though, might need some attention in that area. I've already created an issue for it (LizardByte/Sunshine#8)

@GeoDerp
Copy link
Author

GeoDerp commented Feb 5, 2022

I have been making a rpm over the last few days (with a little help while I'm going), however last night I have gotten stuck on yet another issue (different ones on both Fedora and openSUSE)

https://build.opensuse.org/package/show/home:GeoDerp:Sunshine/Sunshine

I believe with some help (or more testing) I may be able to get it working.

Fedora error: (tried via OBS and local build)

/usr/bin/ranlib libenet.a
/usr/bin/ranlib libminiupnpc.a
gmake[2]: Leaving directory '/var/home/Geo/rpmbuild/BUILD/sunshine-main/redhat-linux-build'
gmake[2]: Leaving directory '/var/home/Geo/rpmbuild/BUILD/sunshine-main/redhat-linux-build'
[ 41%] Built target enet
[ 41%] Built target libminiupnpc-static
cc1: some warnings being treated as errors
gmake[2]: *** [third-party/cbs/CMakeFiles/cbs.dir/build.make:107: third-party/cbs/CMakeFiles/cbs.dir/cbs_av1.c.o] Error 1
cc1: some warnings being treated as errors
gmake[2]: *** [third-party/cbs/CMakeFiles/cbs.dir/build.make:93: third-party/cbs/CMakeFiles/cbs.dir/cbs_h2645.c.o] Error 1
gmake[2]: Leaving directory '/var/home/Geo/rpmbuild/BUILD/sunshine-main/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:237: third-party/cbs/CMakeFiles/cbs.dir/all] Error 2
gmake[1]: Leaving directory '/var/home/Geo/rpmbuild/BUILD/sunshine-main/redhat-linux-build'
gmake: *** [Makefile:94: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.ul5UpW (%build)

openSUSE 15.4error: (higher up in the build)

[  117s] -- Found Boost: /usr/include (found suitable version "1.66.0", minimum required is "1.53.0") found components: system thread chrono date_time atomic 
[  117s] -- Found OpenSSL: /usr/lib64/libcrypto.so (found version "1.1.1l")  
[  117s] CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
[  118s]   Could NOT find Boost (missing: log filesystem) (found version "1.66.0")
[  118s] Call Stack (most recent call first):
[  118s]   /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
[  118s]   /usr/share/cmake/Modules/FindBoost.cmake:2345 (find_package_handle_standard_args)
[  118s]   CMakeLists.txt:27 (find_package)
[  118s] 
[  118s] 
[  118s] -- Configuring incomplete, errors occurred!
[  118s] See also "/home/abuild/rpmbuild/BUILD/sunshine-v0.11.1.r0.ge4c9c29/build/CMakeFiles/CMakeOutput.log".
[  118s] See also "/home/abuild/rpmbuild/BUILD/sunshine-v0.11.1.r0.ge4c9c29/build/CMakeFiles/CMakeError.log".
[  118s] error: Bad exit status from /var/tmp/rpm-tmp.CQgW3m (%build)

openSUSE Tumbleweed error

[   19s] CMake Error at /usr/lib64/cmake/Boost-1.78.0/BoostConfig.cmake:141 (find_package):
[   19s]   Found package configuration file:
[   19s] 
[   19s]     /usr/lib64/cmake/boost_log-1.78.0/boost_log-config.cmake
[   19s] 
[   19s]   but it set boost_log_FOUND to FALSE so package "boost_log" is considered to
[   19s]   be NOT FOUND.  Reason given by package:
[   19s] 
[   19s]   No suitable build variant has been found.
[   19s] 
[   19s]   The following variants have been tried and rejected:
[   19s] 
[   19s]   * libboost_log.so.1.78.0 (shared, Boost_USE_STATIC_LIBS=ON)
[   19s] 
[   19s] Call Stack (most recent call first):

note: in OBS (openSUSE Build Service) I have a project config with rpm substitutes. As the naming conventions and some packages are different with Fedora then openSUSE: https://build.opensuse.org/projects/home:GeoDerp:Sunshine/prjconf

If this spec file works, the project repo can be installed on peoples systems, and they can install the rpm via OBS (if they have a supported distribution).
Alternately, you could possibly build the RPM in something like GitHub actions (happy to help with this). you could create routines to auto build and test RMP's per tag or release.

Feel free to pull the spec file and run it locally: if you do so, you will need to clone ... --recurse-submodules the repo manually and change the header from:

Name:           sunshine
Version:        @SERVICE@
Release:        %{version}
Summary:        Sunshine is a Gamestream host for Moonlight
License:        GPL-3.0 License
Group:          System/GUI/Other
URL:            https://github.com/SunshineStream/Sunshine
Source0:        %{name}-%{version}.tar.xz

to

Name:           sunshine
Version:        v0.11.1 #the tag your using... or just main would work
Release:        %{version}
Summary:     Sunshine is a Gamestream host for Moonlight
License:        GPL-3.0 License
Group:          System/GUI/Other
URL:            https://github.com/SunshineStream/Sunshine
Source0:       %{name}-%{version}.tar.gz #what you use to compress the repo

(this is because my project on OBS uses _service to pull from the repo every time I run)
note when using the repo locally you will need to git clone, then rename to something like sunshine-main, then compress to something like a .tar.gz in your SOURCES dir.

I can also give maintenance access to the project itself on OBS, or someone could branch my project if they want to go off and do their own work via openSUSE build service.

Once/if we have this working for Fedora and openSUSE, I can also enable more Linux distributions and see if we can get it working on more distros (OBS supports a few types besides the Fedora and openSUSE)

obviously I can't promise ill maintain the RPM's leading the future however

@GeoDerp
Copy link
Author

GeoDerp commented Feb 5, 2022

If it is of any help, I can build sunshine on fedora 35 through toolbox, which creates a podman container with access to your filesystem but doesn't clutter your system with development libs:

toolbox create sunshine-build-f35
toolbox enter sunshine-build-f35

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install gcc g++ cmake boost-devel boost-static openssl-devel ffmpeg-devel libopusenc-devel libXfixes-devel libX11-devel libevdev-devel pulseaudio-libs-devel libXrandr-devel libdrm-devel libcap-devel wayland-devel

echo git clone https://github.com/loki-47-6F-64/sunshine.git --recurse-submodules && cd sunshine
mkdir build && cd build
cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ ..
make -j ${nproc}

exit

cd build
sudo setcap cap_sys_admin+p sunshine

I can then start it on my host with ./sunshine I haven't looked up creating an rpm, yet. I might give building an appimage a try, though

This may be the best option if this just gets all too hard. Personally, I like the ability to install and uninstall the project easily via rpm's. And the knowledge that once set up right, if I uninstall the rpm all program files get removed is nice. Also adding the custom openSUSE repo (which created for the project), then receiving all updates automatically is also very nice.

What would also be amazing (but I don't have the knowledge to do it yet), is have the whole program running in a container and be containerised.

It could also be converted to a flatpak and added to flathub if anyone is smart enough to achieve it???

Personally: I believe Flatpaks are the future and having it on flathub would open up the program to many people (I believe). But I'm bias.
Running the whole program in a container will also allow for many people to use the program without many issues. it looks like it could possibly be done:
- https://medium.com/geekculture/run-a-gui-software-inside-a-docker-container-dce61771f9
- https://developer.nvidia.com/blog/gpu-containers-runtime/
- https://blog.jessfraz.com/post/docker-containers-on-the-desktop/
*However, I have no idea how the program itself will go (with permissions of viewing the screen and such) *

@ReenigneArcher
Copy link

What would also be amazing (but I don't have the knowledge to do it yet), is have the whole program running in a container and be containerised.

Games on Whales is sunshine in a container. https://games-on-whales.github.io/gow/

@banks047
Copy link

banks047 commented Feb 7, 2022

@ReenigneArcher
I've been able to successfully build Sunshine for Fedora 35 using Dockerfile but unfortunately the asset path seems to be hardcoded and Sunshine stops working once the directory is moved to another location. Would it be possible to make Sunshine use relative path (to the sunshine executable)?

@ReenigneArcher
Copy link

@ReenigneArcher I've been able to successfully build Sunshine for Fedora 35 using Dockerfile but unfortunately the asset path seems to be hardcoded and Sunshine stops working once the directory is moved to another location. Would it be possible to make Sunshine use relative path (to the sunshine executable)?

The assets directory should be /etc/sunshine ... what is the reason for moving it?

@banks047
Copy link

banks047 commented Feb 7, 2022

@ReenigneArcher I've been able to successfully build Sunshine for Fedora 35 using Dockerfile but unfortunately the asset path seems to be hardcoded and Sunshine stops working once the directory is moved to another location. Would it be possible to make Sunshine use relative path (to the sunshine executable)?

The assets directory should be /etc/sunshine ... what is the reason for moving it?

After building the app with default options using Fedora dockerfile, it searches for assets in the folder where the binary was initially built in and reports an error in terminal saying that assets couldn't be located in that path

@ReenigneArcher
Copy link

@ReenigneArcher I've been able to successfully build Sunshine for Fedora 35 using Dockerfile but unfortunately the asset path seems to be hardcoded and Sunshine stops working once the directory is moved to another location. Would it be possible to make Sunshine use relative path (to the sunshine executable)?

The assets directory should be /etc/sunshine ... what is the reason for moving it?

After building the app with default options using Fedora dockerfile, it searches for assets in the folder where the binary was initially built in and reports an error in terminal saying that assets couldn't be located in that path

Do you mind sharing all the terminal commands that you're using for building?

@banks047
Copy link

banks047 commented Feb 7, 2022

@ReenigneArcher I've been able to successfully build Sunshine for Fedora 35 using Dockerfile but unfortunately the asset path seems to be hardcoded and Sunshine stops working once the directory is moved to another location. Would it be possible to make Sunshine use relative path (to the sunshine executable)?

The assets directory should be /etc/sunshine ... what is the reason for moving it?

After building the app with default options using Fedora dockerfile, it searches for assets in the folder where the binary was initially built in and reports an error in terminal saying that assets couldn't be located in that path

Do you mind sharing all the terminal commands that you're using for building?

git clone https://github.com/SunshineStream/Sunshine.git --recurse-submodules
cd scripts
./build-container.sh -f Dockerfile-fedora_35
./build-sunshine.sh -s ..

@ReenigneArcher
Copy link

./build-sunshine.sh -s ..

Try changing the last one:
./build-sunshine.sh -c <path where you want the binary on the host> -s ..

If that doesn't work, I'm not sure (and don't have a Fedora system to test on) until we get an rpm package generated. Currently build-sunshine.sh doesn't have the logic for this. You can always use the Dockerfile as reference to see what the required dependencies are for Fedora 35. Then build using the standard method (not the scripts directory).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants