Armory in Fedora 18

[AliceWonder]

I did a search and the only results don't look like they apply.

Running Armory in Fedora 18, built an RPM. The spec file needs work but anyway -

First - Fedora does python bytecompile when building python packages. They check for syntax during that.
If you have SELinux enabled (as it should be on any Linux box running bitcoin) you have to bytecompile at package time or SELinux pukes when python tries to when run.

To get it to bytecompile I had to apply the following patch:

Code:

diff -ur BitcoinArmory-0.87.2/googlecode_upload_release.py BitcoinArmory-0.87.2-patched/googlecode_upload_release.py
--- BitcoinArmory-0.87.2/googlecode_upload_release.py	2013-07-12 01:50:56.000000000 -0700
+++ BitcoinArmory-0.87.2-patched/googlecode_upload_release.py	2013-07-12 03:46:56.956465040 -0700
@@ -288,10 +288,10 @@
              ['_win32.msi',         'Version %s for Windows 32- and 64-bit', ['WindowsMSI',    'OS-Win32']], \
              ['_OSX.dmg',           'Version %s for Mac/OSX 10.8+',          ['MacosxDMG',     'OS-MacOSX']], \
              ['_sha256sum.txt.asc', 'Version %s SHA256 hashes of installers',['HashesSHA256']]]
-             ['_OfflineBundle_Ubuntu-10.04-32bit.tar.gz',     'Version %s Offline Bundle for Ubuntu 10.04-32bit', \
-                                                                             ['DebianPackage', 'OS-Linux32', 'Offline']], \
-             ['_OfflineBundle_Ubuntu-10.04-64bit.tar.gz',     'Version %s Offline Bundle for Ubuntu 10.04-64bit', \
-                                                                             ['DebianPackage', 'OS-Linux64', 'Offline']], \
+             #['_OfflineBundle_Ubuntu-10.04-32bit.tar.gz',     'Version %s Offline Bundle for Ubuntu 10.04-32bit', \
+             #                                                                ['DebianPackage', 'OS-Linux32', 'Offline']], \
+             #['_OfflineBundle_Ubuntu-10.04-64bit.tar.gz',     'Version %s Offline Bundle for Ubuntu 10.04-64bit', \
+             #                                                                ['DebianPackage', 'OS-Linux64', 'Offline']], \
              # Actually, we can just include the hashes of the offline bundles in the sha256sums file
              #['_OfflineBundle_Ubuntu_10.04_32bit.tar.gz.sig', 'Detached Signature for %s 32-bit offline bundle', \
                                                                              #['DetachedSig', 'OS-Linux32', 'Offline']], \

The complaint was indentation error. I figured (hoped) the _OfflineBundle_Ubuntu stuff really didn't matter to Fedora but if it does, someone familiar with python might want to look at the indentation of the lines I commented out.

-=-

Got it installed and launched, and got an error reported in the client:

Code:

/sbin/bitcoind: line 21: /etc/bitcoin/bitcoin.conf: Permission denied

bitcoind is owned by the bitcoin-server package installed, and I'm not sure what armory wants with that file, but I do not have the server enabled so it looks like armory is trying to start the server but doesn't have permission to. Is that case?

What does armory do with the server? Would setting the server to start at system boot give armory what it needs? I've been using bitcoin-qt which does not use the server, it seems that the bitcoin-qt rpm I have actually runs its own server within the user directory to avoid issues of permissions.

Is that something I am going to need to do with armory?

I do not want to have un-install the bitcoin-server rpm.

Thanks for suggestions. I'll look at this more tomorrow.
I really like the creation of paper backup at the start, that's awesome.

[AliceWonder]

oh - it's 88.1 not the 87.2 that the patch says.

I did a fresh git checkout but when making tarball for rpm I re-named directory and the tarball with wrong version, that's all.

[AliceWonder]

Changing the setting so it doesn't try to run bitcoin for me and then starting the daemon does seem to work.
What are the potential negatives of that?

[AliceWonder]

OK - I'm zoned. Last post before I go to sleep.

It looks to me like what Armory is doing, if bitcoind is installed - that's what it wants to try to use if you let armory control the backend. Hence the permissions problems.

So I think what it probably needs on fedora is a patch to look for bitcoin-qt binary first and start that, at least if using bitcoin installed from http://linux.ringingliberty.com/bitcoin/

That's the bitcoin that common users can start and stop without being root.

I assume there are no problems having it share a blockchain with bitcoin-qt ??

[etotheipi]

Changing the setting so it doesn't try to run bitcoin for me and then starting the daemon does seem to work.
What are the potential negatives of that?

Sorry for the delay in responding.  Got distracted by a bunch of things and missed this.

There is no negative.  The auto-bitcoind was intended to make things easier and smoother for less-experienced users, especially those with Bitcoin-Qt/bitcoind in standard locations or with it not installed yet (it will download and install it for you, in a cryptographically-secure manner).

The only difference running it yourself and letting Armory do it for you is convenience (and auto-bitcoind can definitely be less convenient if you have a non-standard setup).

I haven't tried it on Fedora, but you should see if the download&install works. I'm intensely curious to find out if it does.  I'm not aware of the regular version requiring root to run on Fedora. 

And yes, Armory currently latches onto the same blk*.dat files that bitcoin-qt/bitcoind is using.  However, indexing those files in RAM takes a lot of time and memory, which is why I hope to have a disk-based version in the next week or two.

[AliceWonder]

No problem on delay.

I use the Fedora RPMs for bitcoind and bitcoin-qt from http://linux.ringingliberty.com/bitcoin/

Normally I run bitcoind as a system system, I do not run a bitcoin client in my normal user accounts because even on linux malware is a potential problem. I run the daemon just to be another peer.

When I want to use a client, I turn off the daemon and then log into another user account where I have the clients and browsers set up to disable both flash and java.

This is a problem with armory as it then wants to start bitcoind which it doesn't have permission to do. But it might not be a problem if bitcoind is left running, I'll have to do some testing. I shut bitcoind down because bitcoin-qt can't run while the daemon is running.

What I might do is attempt to patch armory for fedora so that it tries to start bitcoin-qt before bitcoind if both are present.

The other issue I am having is with the rpm I built -

Code:

BitcoinArmory.x86_64: E: arch-dependent-file-in-usr-share /usr/share/armory/_CppBlockUtils.so

I'm not sure what the best place is for that file on a Fedora system but I'm guessing /usr/lib64/armory

My goal is to produce an RPM spec file that would pass Fedora packaging guidelines.
The maintainer of the bitcoind / bitcoind-qt RPMs I use wants to get his into Fedora as soon as Fedora fixes their openssl RPM so building an armory RPM that works with his reference client RPMs is best so that armory can then get into Fedora as well.

I haven't worked on the RPM since the night I started this thread, but I probably will this week.

If the watch wallet does what I think it does (generate addresses w/o needing the seed that generates private keys??), it is what I want to use for my paper wallets as that allows me to hide how much I have saved from blockchain snooping.

[AliceWonder]

One possible solution to the /usr/share issue would be on Fedora systems to put it all in /usr/lib{,64}/armory and not use /usr/share - multilib installs of armory don't make sense anyway.

[ekkis]

Running Armory in Fedora 18, built an RPM

any chance you could share the spec file? I'd like to build on Fedora 20

[Carlton Banks]

Did we ever get an rpm package for Armory? I'm not seeing anything on bitcoinarmory.com

[goatpig]

Did we ever get an rpm package for Armory? I'm not seeing anything on bitcoinarmory.com

Oh boy... not quite there yet, wait till we get a Debian package out first o.o

[Carlton Banks]

Any 0.9x release would be great, don't think there's anything in 0.92 that I need as much as just a working 0.90-0.91 on Fedora. I guess I'll have to keep trying the command line wrangling...

[goatpig]

Any 0.9x release would be great, don't think there's anything in 0.92 that I need as much as just a working 0.90-0.91 on Fedora. I guess I'll have to keep trying the command line wrangling...

With the upcoming change to the messaging format to support multisig, anything 0.92 and above will be incompatible with older versions.