I plan, sometime after its final release (next week) to add Ubuntu 17.10 packages (Artful) and then Debian 10 (Buster) sometime after that. Both platforms are compiling proper and I’m tuning up the packaging scripts etc etc + more testing. Beyond that I have OpenSuse Tumbleweed compiling as well, but, will be a while (if ever) for it as I haven’t developed skills with its packaging and package manager system well enough yet.
Great to hear some Debian10 packages may be on their way at some point. I have been tempted to cross to Ubuntu just to use your packages and save myself the hassle/frustration of self-compiling but for me the benefits/deficiencies* of Debian slightly outweigh the benefits/deficiencies* of Ubuntu so I was never quite able to justify the switch for myself.
.* both distros’ approaches have various pros and cons in different areas.
Well - hopefully Deb10 packages will work out - all the requirements currently exist without need to use third party packages so I figured might as well try (same as Ubuntu 17.10 – the first in a while that will need no PPA additions(s))… and I already have the packaging skills from Ubuntu so it’s pretty much, for me, same process. Bit more testing to be sure - then will see.
Would you mind sending me the required dependencies on Ubuntu?
Version? Basically though - to compile… build-essential, cmake, git and Qt5.9. If U16.04 then Qt will need to be locally installed or via a PPA. When you run cmake if you’re missing anything it’ll tell you then you can dig out any missing dependencies. It’s reasonably simple to compile and run from where it builds… moving it from built location to other location is where it gets complicated as it hard paths to where built for many things.
Wow I didn’t realize it was so simple. I just assumed your repositories had heaps of libssl, yaddayaddya… Thanks.
Well you’ll need dev packages for all that, but, the big problem child is Qt5.9 along with its dev packages. There’s a linux build guide in github - it should be your first stop - 2nd would be the multiple step by step threads on how to compile on Linux. If you’re reasonably proficient with compiling and digging up dep libs you should get more than enough from just the build guide in git – keep in mind, read the general and linux specific docs.
I would strongly suggest NOT updating to RC57 build that was recently posted – it seems to have a number of issues. Wait for 57.1 – I didn’t have time to prequalify it before it was posted or it would never have hit my Ubuntu repository.
Updated. Read this. Awesome.
Isn’t this a fix Linux needed though, “Fix DQT_CMAKE_PREFIX_PATH being overwritten”?
You’re the perfect person to ask this, I realized. I’m …trying… to use Hifi for commercial purposes but step one is obviously a working domain. I’ve built on Linux, and used the sandboxes on both MacOS and Windows. They all seem to need the domain reset every few hours, is that a correct assumption? Do you find that one system is best for the sandbox in terms of reliability otherwise?
Seems to me Linux is the obvious build given there is no overhead for resources for the OS…
Problem of course being that it’s Ubuntu and something always seems to go wrong.
That fix really only applies if you were using an environment variable setting Qt path ($QT_CMAKE_PREFIX) and specifying
-DQT_CMAKE_PREFIX_PATH as an option to cmake. Basically you could end up with odd things if you only used 1 or, worst case, env var was wrong and -D option was right as it totally ignored -D if env var was set.
I’ve been running stack (the name “Sandbox” once had) for 3 years and there’s little cookie cutter/simple about it. The apparent need to reset assignment-clients seems to come into play if you have entity server scripts or the old server script (like acAudioSearchAndInject.js) - they seem to leak memory like crazy, a long standing and often refreshed issue in the bug tracker.
On my domain that I finally decided to take down after nearly 3 years continuous running – I would reset AC/DS every few days assuming it didn’t update before as I ran the devel version where it might update many times per day vs “stable” that can go weeks. Since I had no scripts running on AC side I seldom saw issue and restarting it was just insurance. Also it had like zero visitors other than myself so there’s that too.
As far as Linux in general is concerned - there should be zero problem running it on Ubuntu 16.04 – if you want to use the premade packages I have – or CentOS (another thread has an automated approach to CentOS). I can provision a digital ocean droplet and have it configured + running stack in about 4 minutes or less if D.O. isn’t lagging on droplet creation. So I don’t know where the problem with Ubuntu comes in. It’s pretty much automatic unless you want to self-compile – then it’s a chore. It also doesn’t help that HiFi’s Linux build guide is totally out of date still referring to installing their Qt5.6.1 package.
You can get the -dev packages for Qt5.9.x from the PPA I specify for my packages. Then you just point Qt path to Qt5.9 in /opt (I’m not in a place where I can really look at my setup now to give exact paths). If you’re going to build your own you’ll have to get really comfortable sorting these things out as HiFi has a nasty habit of deciding they want to use some just released lib that’s not in any package repo).
That’s an iterative process. Run cmake - it spits out an error about some missing package… Off to google searching for whatever it is that cmake complains about + Ubuntu Xenial. That’ll lead you to a package, usually, that you then install -dev version of to get the includes/headers… Run cmake again and repeat until it quits complaining. I pretty much have spent countless errors sorting this all out and repeating said process over and over as HiFi breaks what used to work.
Also it takes a machine with at least 4 Gigs RAM to compile now - a 2G + 2G swap will do in a pinch. My compile machine is an i7 with 64G RAM and SSDs which takes about 15 minutes to compile Stack and Interface. Doing so on a 2 CPU D.O. droplet takes a “bit” longer.
I used to document all of this in a verbose set of instructions, but, honestly – it was a lot of work answering questions (mostly the same) over and over as even with a step by step “cheat sheet” you still need to have some pretty heavy comfort level with Linux, compiling and finding packages. So… I started compiling packages - mainly because I used to think I’d need them for deploying large numbers of AC servers. After becoming increasingly dubious I’ll have that need I decided… what the hell - I’ll post my packages and let anyone who wants use them.
RC57.1 with fixes aimed at fixing issues introduced by RC57 has been posted to stable repository. If you’re using unstable variant there’s no need to do anything as you’re already effectively running 57.1+. If you’re on stable and held off updating from RC56 then RC57.1 seems ok.
It’s (remotely) possible that scripts served via ATP could be in a “bad” state from RC57 if you ran it - If you have scripts that fail to run there’s a couple of things you can do. Uncheck box for use baked by script (It’s now disabled by default in 57.1 until fixed). If that doesn’t restore script to functioning you should probably delete ATP script and upload again.
Package building is down for the foreseeable future. Perhaps, someday, HiFi will actually release Linux packages, at least for Ubuntu 16.04, versus it having to be done by a third party.
It’s just becoming too much headache trying to keep up with the million and one dev versions and then manually setting up compiles for RC versions – those can’t be automated without trying to scrape data from numerous places, all subject to changing.
Even so, I want to thank you for your great work in the past!
Thank you so much.
Also see this for more background and hints on how to do it, potentially, right.
I meant to post that before but things are hectic in 'mega lands.
I knew this day would come but like everyone else here, thank you so much for keeping in the trenches for so long you made a lot of peoples lives must easier!
You are a god send I just wish I could get this to compile on Arch again. Anyone here interested in using one of these scripts to do a Flatpak or Appimage?