User:Dale Glass

Introduction

Greetings!

I'm a software developer. I live in Europe. I've been using Second Life for more than 13 years and finally started looking for something that worked better with VR and was suffering less from stagnation, and found HiFi.

My GitLab page is at https://gitlab.com/daleglass and has some HiFi related projects.

 

HiFi Community Philosophy

Given the recent developments in which HiFi the company distanced itself from running public domains and is changing track to some sort of corporate meeting oriented product, my view is that the community should strive for collaborative independence.

This doesn't mean completely ignoring the company, but not expecting nor requiring any assistance from it to go forward. Cooperation is certainly a good thing and should be kept up for as long as it lasts, but should the company pull away, everything must be ready to continue the work.

 

Projects

HiFi build server

I'm working on a build server for HiFi. It's based on Jenkins Pipeline with Docker containers. The idea here is to have HiFi be automatically built and packages be uploaded somewhere. Currently I'm working on Linux builds, and Oculus Quest is hopefully coming next.

Currently I am building the official repository, but the long term idea is to build any community forks, including my own.

The project files are at https://gitlab.com/hifi-packaging.

Lessons learned

This has been an interesting experience, so I'll document here what I learned so far.

The initial attempt was to make packages for distributions, with the aim of having HiFi be included in distributions. This so far seems to have failed, due to the inclusion of a specific and modified Qt into the build requirements.

Attempt #2 was to write my own library packaging script, to imitate what Second Life was doing. This proved to be a bit troublesome, and rather pointless since there multiple projects working on solving that problem.

Attempt #3 was to use flatpak. In this model, apps are build inside a VM containing a fixed runtime environment, packaged, and distributed. This hit a bit of a snag in that cmake doesn't complete under it.

Attempt #4 is to use AppImage. This works better, but uses the system glibc, which required downgrading the build container to Ubuntu Xenial. This has finally produced a package that starts up.

 

Flatpak vs AppImage

 

Flatpak	AppImage
Uses a Flatpak provided build environment.	Uses the libraries of the system it was installed on
Uses a fixed build environment and so will only pick up changes to it when the official image is updated	Can pick up updated libraries by just rebuilding the project
Has a base runtime which only needs to be downloaded once per application	Includes everything but glibc, so every single dependency must be included in the package.