I'm hoping giving as much information as possible will help. I am not a python guru.
Here is the rpm spec file I am using to build it :
http://awel.domblogger.net/7/libre/bitcoin-armory.spec
Spec File Notes:
The source tarball. I seemed unable to find "official" source tarball releases, which is something I find to be a wee bit odd.
Usually projects I am use to packaging for CentOS have versioned source tarballs with a signed sha256 checksum to verify the tarball. I could not find that for armory.
If someone downloads my src.rpm how are they suppose to validate the tarball inside if there isn't an official signed checksum?
Not providing official source tarballs w/ signed checksum is a trend that seems to be growing with the popularity of git, but it is lazy and isn't a good practice. But maybe they do exist and I was just too stupid to find them.
RPM really likes to start with a versioned source tarball so I did the following to create it :
git clone git://github.com/etotheipi/BitcoinArmory.git
cd BitcoinArmory
git checkout v0.93.3
git tag -v v0.93.3
cd ..
mv BitcoinArmory BitcoinArmory-0.93.3
tar -Jcf BitcoinArmory-0.93.3.tar.xz BitcoinArmory
Subpackages. Those just have desktop files in them. I don't plan to use Armory in offline mode or testnet mode, so putting those into separate packages means I don't need to have the menu items.
/usr/libexec/armory
In Red Hat based systems, /usr/lib is generally for 32-bit libraries - /usr/libexec seems to be where stuff like this is put. I know that differs from other distros, it's just a packaging convention thing, I don't believe it has anything to do with the error on startup I am receiving.
%files
It seems that the make install script is broken. It installs some python scripts that have a shebang with 0644 permissions which is wrong. If there is a shebang it really should be 0755 permissions. That's why the %files is so bl00dy detailed, it makes sure they are packaged with the correct permissions.
default_bootstrap.torrent - I'm not sure why armory packages that
It should not be trying to use it, bitcoind is faster than bittorrent, and I don't think the torrent has been updated in ages. Not a problem, just a curiosity as to why it is there.-=-=-
Build Notes:
Here is the build log from building the package inside the mock build environment :
http://awel.domblogger.net/7/libre/bitcoin-armory.build.log
I did not see anything in that build log that looks funny.
-=-=-
Environment Notes:
I am running bitcoin core 0.11.2 linked against LibreSSL and not linked against OpenSSL.
The stock OpenSSL in CentOS 7 is missing a lot of the EC stuff and does not work for building bitcoin.
As I already have LibreSSL for apache / postfix / dovecot / etc. purposes - I prefer to just use it for bitcoin as well rather than also maintain a separate OpenSSL from the OS vendor OpenSSL.
Bitcoin built against LibreSSL works just fine, it has no problems validating blocks or creating transactions that the network accepts. I don't think that's the issue here, but just in case it is I thought I would mention it. Maybe the python in armory expects something OpenSSL does when validating stuff that LibreSSL doesn't do?
I seem to remember some people complaining it was a bad idea to use LibreSSL because it could weaken network consensus or some such nonesense (if it really does, that's a bug in bitcoin core) so maybe there is something different?
I doubt it, but I thought I would mention it.
-=-=-
Anyway - I really really REALLY like Armory and I would love to figure out why it is not working on CentOS 7.
Thanks for any suggestions.