Well, as we all well know, the primary contingent of bearded hipsters who've switched to Linux from Mac over the past few years never made it much further than Ubuntu. This is problematic because they are responsible for top-level standards, like NPM and Electron, but they really only test on Ubuntu. This often doesn't create a problem with Electron apps, but in the documentation is where the devlish details compound and actually serve to limit user choice by making it more difficult for people to leave an allegedly free ecosystem. This is not a rant about bad documentation, though.

I've been continually having a problem with GPU Mining and Ubuntu, over the years. Now and then a driver update will happen, and this annoying login loop occurs. You have to do some debugging, and this last time, I just decided to quit Ubuntu again. I did it for my primary desktop, now I'm doing it in mining rigging. So I just dumped everything and started from scratch with Fedora 22. Quickly learned that I needed to get updated to 24 or later just to have CUDA. So I did that, which took a few hours. Got the GPU miner up, got the external ASICs running, now just for some storage farming and plotting on this omni-mining prototype rig of mine (I foresee having several rigs just like it, all earning more than one type of currency at a time).

Snap still isn't great for Fedora and other non-Ubuntu systems, so there's a current bug that prevented me from simply running Storjshare's snap package. No matter, I installed node.js, npm, and the rest, and got Storjshare GUI running without a hitch.

But then I noticed a problem.

Storjshare showed me as connected to the test network. Some quick searching revealed that this was a problem with not completing the final step, but that the thing would still be actually on the network. Fine, fine. But why can I not complete that final step?

Having been a Debian world guy most of my life, I had no idea that over in RHEL/CentOS/Fedora world, they've been utilizing our packaging system for years in conjunction with their own. So when NPM and Electron made it easy to package for Linux, they only integrated the Debian packaging. The process doesn't, apparently, automatically include a Yum or any other type of release. Yet, the last step in the process, the one that kills that error and tells Storjshare you're on a stable client, is to command:

npm run release

This runs a "release" script which packages everything. I kept running into an error regarding "dpkg-deb." This seemed out of place, so I figured there must be a flag or something I need to do. Nope, here is the solution, if you're having trouble with the last (npm run release) step of the install process for storjshare-gui in Fedora:

sudo dnf dpkg

That's (almost) it. If you read over it, it shows the package includes the functionality I was missing. And then you get the joy of a package that doesn't properly install in Fedora. So now you have to convert this newly created package, or you can simply force-all, not sure, I didn't try that.

For this, we're going to use a tool from Debian called Alien. It eases the process of translating from Debian to Fedora. After installing alien (sudo dnf alien), traverse to the directory (cd /storjshare-gui), and then run alien on the debian package: sudo alien -r storj.deb

Then you simply run

sudo alien -i releases/storj*.rpm

The end result is a working Storjshare-GUI on Fedora, with no test network activity:

Now to see if you actually make anything in this opaqe mess. I wrote this post because their developers are kind of busy, see here.