I'd be happy to help out, it'd be great if everyone who wanted to use Qubes OS had access to a maintained Armory package. I think the security model is robust enough to use the way I described, and not as much hassle as having a separate physical machine for your offline Armory.
I don't think catering for Qubes is much more difficult in practice than what standalone Fedora needs; I'm running Armory from it's standard location, and it syncs up with Bitcoin Core just fine (still issues with letting Armory run bitcoind itself, although I don't believe that's Armory related)
Topic: Building Armory on Fedora 20 (Read 1420 times)
Kind of a nice setup. Armory Offline runs in a VM with no network connectivity, and I can use the Xen hypervisor based special copy-paste function to move the unsigned/signed transactions between the Armory Offline and Armory with a network connection. The only thing that won't work now is the in-app updates, but I'm hoping Armory devs might find this easy to implement given how easy it was to get this up and running.
Thanks for the info. You can always submit a pull request and let us know what you did. No guarantees, as always, but we'll certainly take a look at it.
Ok, so it's working seamlessly now, as well as it ever worked on Debian.
I'm using Qubes OS R2, which sounds complicated on the face of it, but in practice is little different to what's needed for Fedora 20. I installed swig, qt4.8.5, python-psutil, and I think that was it (all packages are available from the standard repo for Fedora 20). Rewrote the desktop config files slightly for all the Armory apps, then used the command line to put them where they should be in the system area (to get menu launching from the GUI in the overall hypervisor).
Kind of a nice setup. Armory Offline runs in a VM with no network connectivity, and I can use the Xen hypervisor based special copy-paste function to move the unsigned/signed transactions between the Armory Offline and Armory with a network connection. The only thing that won't work now is the in-app updates, but I'm hoping Armory devs might find this easy to implement given how easy it was to get this up and running.
I'm using Qubes OS R2, which sounds complicated on the face of it, but in practice is little different to what's needed for Fedora 20. I installed swig, qt4.8.5, python-psutil, and I think that was it (all packages are available from the standard repo for Fedora 20). Rewrote the desktop config files slightly for all the Armory apps, then used the command line to put them where they should be in the system area (to get menu launching from the GUI in the overall hypervisor).
Kind of a nice setup. Armory Offline runs in a VM with no network connectivity, and I can use the Xen hypervisor based special copy-paste function to move the unsigned/signed transactions between the Armory Offline and Armory with a network connection. The only thing that won't work now is the in-app updates, but I'm hoping Armory devs might find this easy to implement given how easy it was to get this up and running.
What you want to delete is /cppForSwig, which has all the C++ code and compiled intermediary files. You can also get rid of /pytest and /extras, and the obivous windows and osx build folders.
I believe you delete just about everything, really. On Linux, you'll see a file called _CppBlockUtils.so. You need to keep it so that Armory can run the C++ code. I believe everything else can be deleted. If I'm wrong, someone on the team will correct me.
It seems that alot of the .py files in the base dir are needed, not to mention the armoryengine directory, ui directory, and to keep it quiet, the BitTornado directory. Plus anything else that will make it crash from using a feature I've not tried yet... still dl-ing bitcoin blockchain to the VM though.
Also learned new things about Qubes Linux: How to get a desktop launching file synced onto the desktop menu! In a hacky way, of course, there's surely some better way, but it works
Oh, I should've clarified. You definitely need a lot more than what I mentioned! To be safe, you should use run "make install" or read it. That shows exactly what you need.
I believe you delete just about everything, really. On Linux, you'll see a file called _CppBlockUtils.so. You need to keep it so that Armory can run the C++ code. I believe everything else can be deleted. If I'm wrong, someone on the team will correct me.
It seems that alot of the .py files in the base dir are needed, not to mention the armoryengine directory, ui directory, and to keep it quiet, the BitTornado directory. Plus anything else that will make it crash from using a feature I've not tried yet... still dl-ing bitcoin blockchain to the VM though, so I've not tested anything really.
Also learned new things about Qubes Linux: How to get a desktop launching file synced onto the desktop menu! In a hacky way, of course, there's surely some better way, but it works
That did it. Good man!
Turns out that 91.2 compiles very fast, I was expecting a half hour job, kind of why I thought the build environment or the dependencies were wrong.
Turns out that 91.2 compiles very fast, I was expecting a half hour job, kind of why I thought the build environment or the dependencies were wrong.
Oh no, it's quite fast. Now if you were building on OS X, where we force everybody to build Qt, Python, etc....
Quote
One more question...
Which parts of the build directory structure can I get rid of? It weighs in at 1.9 GB, I'm pretty sure most of that isn't needed to run.
Which parts of the build directory structure can I get rid of? It weighs in at 1.9 GB, I'm pretty sure most of that isn't needed to run.
I believe you delete just about everything, really. On Linux, you'll see a file called _CppBlockUtils.so. You need to keep it so that Armory can run the C++ code. I believe everything else can be deleted. If I'm wrong, someone on the team will correct me.
That did it. Good man!
Turns out that 91.2 compiles very fast, I was expecting a half hour job, kind of why I thought the build environment or the dependencies were wrong.
One more question...
Which parts of the build directory structure can I get rid of? It weighs in at 1.9 GB, I'm pretty sure most of that isn't needed to run.
Turns out that 91.2 compiles very fast, I was expecting a half hour job, kind of why I thought the build environment or the dependencies were wrong.
One more question...
Which parts of the build directory structure can I get rid of? It weighs in at 1.9 GB, I'm pretty sure most of that isn't needed to run.
Thanks doug.
Here's what happens when you run what does get built:
I have no idea what that module is! (I'm guessing it's in the code somewhere, would be much easier to search if I could get the project file up in the IDE you all use, but it seems like you guys don't put it on git?)
Here's what happens when you run what does get built:
Code:
[/quote]$ python ArmoryQt.py
Traceback (most recent call last):
File "ArmoryQt.py", line 26, in
import psutil
ImportError: No module named psutil
I have no idea what that module is! (I'm guessing it's in the code somewhere, would be much easier to search if I could get the project file up in the IDE you all use, but it seems like you guys don't put it on git?)
You'll need to download and install this.
Thanks doug.
Here's what happens when you run what does get built:
I have no idea what that module is! (I'm guessing it's in the code somewhere, would be much easier to search if I could get the project file up in the IDE you all use, but it seems like you guys don't put it on git?)
Here's what happens when you run what does get built:
Code:
[/quote]$ python ArmoryQt.py
Traceback (most recent call last):
File "ArmoryQt.py", line 26, in
import psutil
ImportError: No module named psutil
I have no idea what that module is! (I'm guessing it's in the code somewhere, would be much easier to search if I could get the project file up in the IDE you all use, but it seems like you guys don't put it on git?)
Hello. I'm not quite sure what the official policy is regarding Fedora. I do remember delivering some code months ago that allowed Armory to be built on Fedora 20. However, the Makefile system has undergone quite a few changes since then. I'm pretty sure my original delivery is completely gone now.
Anyway, I think I still have a VM kicking around here somewhere. If I have time, I'll fire it up and see this can be fixed quickly. If not, well, see my earlier statement about Fedora support.
Anyway, I think I still have a VM kicking around here somewhere. If I have time, I'll fire it up and see this can be fixed quickly. If not, well, see my earlier statement about Fedora support.
One thing I'm spotting is that the DESTDIR variable in the base level Makefile declares an empty line as it's value, is that what it's choking on?
Ok, It shouldn't be... because if the script treats DESTDIR as an empty string then all the places where the variable is referenced correspond to a location that exists.
But... the script definitely dies at around that point (somewhere after CppForSwig is finished) as the mkdir commands haven't taken place (definitely running make as root)
Okay, so I think I have all the dependencies listed from the Armory website, but I still have an inexplicable build problem. sudo make exits with no apparent errors, it just writes a line about leaving the cppForSwig directory, then kaput.
One thing I'm spotting is that the DESTDIR variable in the base level Makefile declares an empty line as it's value, is that what it's choking on? Or is there supposed to be something else happening to build before the make command is run (something that passes the value to the top-level Makefile)?
Here's a sample of the output, from the last "leaving directory" line up until the last line before it quits to the command line:
One thing I'm spotting is that the DESTDIR variable in the base level Makefile declares an empty line as it's value, is that what it's choking on? Or is there supposed to be something else happening to build before the make command is run (something that passes the value to the top-level Makefile)?
Here's a sample of the output, from the last "leaving directory" line up until the last line before it quits to the command line:
Code:
make[2]: Leaving directory `/home/user/BitcoinArmory-0.91.2-rc1/cppForSwig/leveldb'
mv leveldb/libleveldb.a .
g++ -O2 -pipe -fPIC -Icryptopp -Ileveldb/include -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -c -o sighandler.o sighandler.cpp
swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
Language subdirectory: python
Search paths:
./
./swig_lib/python/
/usr/share/swig/2.0.11/python/
./swig_lib/
/usr/share/swig/2.0.11/
Preprocessing...
Starting language-specific parse...
EncryptionUtils.h:178: Warning 362: operator= ignored
Processing types...
EncryptionUtils.h:133: Warning 402: Base class 'BinaryData' is incomplete.
BtcUtils.h:83: Warning 402: Only forward declaration 'BinaryData' was found.
C++ analysis...
Generating wrappers...
BlockObj.h:604: Warning 472: Overloaded method TxIOPair::TxIOPair(TxRef,uint32_t,TxRef,uint32_t) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockObj.h:648: Warning 472: Overloaded method TxIOPair::setTxIn(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockObj.h:650: Warning 472: Overloaded method TxIOPair::setTxOut(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:317: Warning 472: Overloaded method StoredHeader::setHeightAndDup(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:709: Warning 472: Overloaded method StoredTxHints::setPreferredTx(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:197: Warning 472: Overloaded method AddressBookEntry::AddressBookEntry(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:301: Warning 509: Overloaded method ScrAddrObj::addTxIO(TxIOPair &) effectively ignored,
BlockUtils.h:300: Warning 509: as it is shadowed by ScrAddrObj::addTxIO(TxIOPair *).
BlockUtils.h:300: Warning 509: Overloaded method ScrAddrObj::addTxIO(TxIOPair *,bool) effectively ignored,
BlockUtils.h:301: Warning 509: as it is shadowed by ScrAddrObj::addTxIO(TxIOPair &,bool).
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:698: Warning 509: Overloaded method BlockDataManager_LevelDB::SetDatabaseModes(int,int) effectively ignored,
BlockUtils.h:695: Warning 509: as it is shadowed by BlockDataManager_LevelDB::SetDatabaseModes(ARMORY_DB_TYPE,DB_PRUNE_TYPE).
g++ -I/usr/include/python2.7 -I/usr/include/python2.7 -O2 -pipe -fPIC -Icryptopp -Ileveldb/include -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -c CppBlockUtils_wrap.cxx
g++ -shared -fPIC -lpthread -Lleveldb -O2 -pipe -fPIC UniversalTimer.o BinaryData.o leveldb_wrapper.o StoredBlockObj.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a libleveldb.a sighandler.o CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
pyrcc4 -o ../qrc_img_resources.py ../imgList.xml
make[1]: Leaving directory `/home/user/BitcoinArmory-0.91.2-rc1/cppForSwig'
Jump to: