I'd rather not run a deb with this software. Any chance you will pull this to github so anybody who clones it has it all set up already?
I'll keep fooling with it in the meantime, although it's not just line 26, but I think also line 29 that might cause problems. There were several libpython files I found in the /usr/share/lintian/overrides/ directory. So, I'm just crapshooting right now.
Topic: Armory - Discussion Thread - page 122. (Read 521761 times)
I've just switched from Fedora to Ubuntu and am trying to install Armory again, but I'm running into a similar problem as I did with Fedora. I received an error after running the make command and I believe it comes down the the fact that I do not have:
/usr/lib/python$(PYVER)/config/libpython$(PYVER).a
There simply is no /config/ directory and likewise no config/libpython.
I'm running Ubuntu 13.04.
/usr/lib/python$(PYVER)/config/libpython$(PYVER).a
There simply is no /config/ directory and likewise no config/libpython.
I'm running Ubuntu 13.04.
Ay. I forgot, 13.04 puts the python-dev files in a different place. I just ran into this problem on my new laptop (with 13.04), and I forgot exactly how I fixed it... but a search of the /usr dir for libpython2.7 should turn up the correct prefix to use. Then you can replace that line appropriately.
Sorry for the inconvenience. I'm battling a few other crises at the moment. Alternatively, now that you're on Ubuntu again, you can use the .deb package (which will give you a "bad package quality" warning, but it's legit, I promise
). It is even signed with my offline GPG key, so you can check it to be sure, before you install it.
I've just switched from Fedora to Ubuntu and am trying to install Armory again, but I'm running into a similar problem as I did with Fedora. I received an error after running the make command and I believe it comes down the the fact that I do not have:
/usr/lib/python$(PYVER)/config/libpython$(PYVER).a
There simply is no /config/ directory and likewise no config/libpython.
I'm running Ubuntu 13.04.
/usr/lib/python$(PYVER)/config/libpython$(PYVER).a
There simply is no /config/ directory and likewise no config/libpython.
I'm running Ubuntu 13.04.
Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
This is what the "heartbeat" functions are for
-- Add a widget somewhere that will show the price (we'll call it self.goxWidget = QLabel(''))
-- Create a function like below
-- Add it to the extraHeartbeatAlways list (extraHeartbeatAlways.append(getGoxPrice))
Code:
def getGoxPrice():
# Return instantly if current time is not a multiple of 900 sec
if not (RightNow() % (15*MINUTE)) == 0:
return
try:
import urllib2
import ast
theData = urllib2.urlopen('http://data.mtgox.com/api/1/BTCUSD/ticker').read()
dataMap = ast.literal_eval(theData)
lastValueStr = dataMap['return']['last']['display']
self.goxWidget.setText(lastValueStr)
except:
self.goxWidget.setText('???')
LOGEXCEPT('Could not access Gox data') # dumps exception to log
You could set the modulo to 10*SECOND for testing.
Nice one. I did see the heartbeat function but didn't play with it much.
I'll have a look to see if I can get it working.
Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add timers which work in the background (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
This is what the "heartbeat" functions are for
-- Add a widget somewhere that will show the price (we'll call it self.goxWidget = QLabel(''))
-- Create a function like below
-- Add it to the extraHeartbeatAlways list (extraHeartbeatAlways.append(getGoxPrice))
Code:
def getGoxPrice():
# Return instantly if current time is not a multiple of 900 sec
if not (RightNow() % (15*MINUTE)) == 0:
return
try:
import urllib2
import ast
theData = urllib2.urlopen('http://data.mtgox.com/api/1/BTCUSD/ticker').read()
dataMap = ast.literal_eval(theData)
lastValueStr = dataMap['return']['last']['display']
self.goxWidget.setText(lastValueStr)
except:
self.goxWidget.setText('???')
LOGEXCEPT('Could not access Gox data') # dumps exception to log
You could set the modulo to 10*SECOND for testing.
Any chance of being able to add the option to show the mtgox price in the tray?
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add threaded timers (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
I know it's not the role of Armory, but it would be useful to have.
I've been trying to add it myself, I've got the code to grab the current price, but with a lack of python/QT knowledge I have little idea on how to add threaded timers (i.e. to update every 5 minutes, without stalling the program whilst the update function runs).
Just as Info:
Bitcoin-qt was ready rereading the complete blockchain at 11:55 PM
Started new installed Armory-win64, worked now, ready 10 minutes later.
Bitcoin-qt was ready rereading the complete blockchain at 11:55 PM
Started new installed Armory-win64, worked now, ready 10 minutes later.
Using Windows 7/64, 8 GB RAM, 100 Mbps Internet
I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.
My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.
After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/
I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.
Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.
Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.
I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.
My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.
After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/
I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.
Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.
Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.
This has been discussed many times. There was a nice robustness and simplicity by not saving data between loads. But obviously not sustainable, and it's becoming too much trouble for users.
I'm working on it now. It should be done in a couple weeks.
Using Windows 7/64, 8 GB RAM, 100 Mbps Internet
I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.
My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.
After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/
I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.
Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.
Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.
I like Armory very much, but its "speed" when starting (Synchronizing and Scanning transaction history) is really not tolerable.
My Armory-win32 version crashed also, first hanging around, then after killing and restart runtime error.
After trying quite a lot I deleted the bitcoin AppData dir (blockchain...) as described in the
outdated(!)
https://bitcoinarmory.com/troubleshooting-armory/
I shouldn't have done that, since as I see here, the new instruction is to use Armory-win64 only.
So I try that. Download and installation is done within seconds.
Now I restart Armory-win64 and cannot believe it.
Armory is Reading/saving not even 100 bytes of the 10 GB blockchain etc. in a minute.
Can see this using Total Commander for my dir management.
Even bitcoin-qt (very,very slow also) is much faster doing the same.
So I stopped armory and now bitcoin-qt is reloading the deleted blockchain.
40000 blocks left in moment. 07:39:45 PM
Compared with that, Electrum doing nothing like that is a dream.
Sorry, I meant online Armory, offline read only wallet.
I am running 64bit Armory.
If I get another crash, I will export an Armory log after the event.
Thank you for the great work...
I am running 64bit Armory.
If I get another crash, I will export an Armory log after the event.
Thank you for the great work...
Wait... you're running this on the offline computer? You don't need Bitcoin-Qt on the offline computer. Please uninstall it so Armory isn't even tempted to try to run it. You only need Armory on the offline computer, and the offline computer can be any PoS with 256 MB of RAM or more. The online computer is the one that needs all the RAM and bitcoin-qt.
Running offline Armory, unexpected crash, Bitcoind closes sometimes
Ram:16GB
64bit
i7 processsor
Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------
Hope this helps
Ram:16GB
64bit
i7 processsor
Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------
Hope this helps
Unfortunately, that error isn't terribly useful, except for noting that bitcoind.exe seems to have triggered the error. Can you run Bitcoin-Qt standalone?
Also, have you downloaded the 64-bit version of Armory? I've noticed a lot of these crashing issues go away with the latest 64-bit version. I actually just removed the 32-bit link from the webpage for that reason.
Running offline Armory, unexpected crash, Bitcoind closes sometimes
Ram:16GB
64bit
i7 processsor
Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------
Hope this helps
Ram:16GB
64bit
i7 processsor
Faulting application name: bitcoind.exe, version: 0.0.0.0, time stamp: 0x4d44aa00
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0x40000015
Fault offset: 0x0006680c
Faulting process id: 0x15ec
Faulting application start time: 0x01ce4c4f259cdee0
Faulting application path: C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: bad46c8f-b842-11e2-9b76-005056c00008
--------------------------------------------------------
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: _CppBlockUtils.pyd, version: 0.0.0.0, time stamp: 0x5171c531
Exception code: 0xc0000005
Fault offset: 0x000e0508
Faulting process id: 0xf34
Faulting application start time: 0x01ce4c37e500f4be
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\_CppBlockUtils.pyd
Report Id: 5c030b55-b82f-11e2-9af5-005056c00008
--------------------------------------------------------
Hope this helps
Just theoretically, it may be that the block chain has just grown so much that one of the arrays in Armory is now over 2 GB. Such an object cannot be addresses in a 32-bit executable, and if that is the case all 32-bit versions of Armory have just stopped working. That would be pretty bad, so let us hope I am wrong.
Good morning,
today, Armory 0.88.1, 32bit+64bit, Windows 8 (64bit), stopped working for me. It just terminates with a runtime error after scanning 98% of the blockchain.
I have tried a couple of things including reinstalling it, doing a fresh install on a fresh Win8 VM (8GB RAM if it matters), redownloading the blockchain and so on.
There seems to be only ONE solution to this for me : Using the 64bit ONLY Version of Armory.
May this helps someone with the same problem!
today, Armory 0.88.1, 32bit+64bit, Windows 8 (64bit), stopped working for me. It just terminates with a runtime error after scanning 98% of the blockchain.
I have tried a couple of things including reinstalling it, doing a fresh install on a fresh Win8 VM (8GB RAM if it matters), redownloading the blockchain and so on.
There seems to be only ONE solution to this for me : Using the 64bit ONLY Version of Armory.
May this helps someone with the same problem!
In bitcoind appdata dir is a file "bitcoin.conf"
containing:
rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)
Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?
containing:
rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)
Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?
This "rpcuser" and "rpcpassword" is for bitcoin-qt and bitcoind, it sets which other users/computers/programs may connect to bitcoin-qt and bitcoind. Everyone connected via rpc may send bitcoins from bitcoind's (!) wallet.
Armory uses its own wallet(s). So you may remove all original bitcoind wallets.
As Armory depends on bitcoind's blockchain-handling, it must be able to connect via rpc.
Any random user and password will enable bitcoind to be connectable, and Armory will simply read the right user and password right from that config.
That's how I understand it, anyway :-)
tl:dr:
It's perfectly safe and normal. Don't leave bitcoins in bitcoin-qt's original wallet though.
Ente
In bitcoind appdata dir is a file "bitcoin.conf"
containing:
rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)
Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?
containing:
rpcuser=generated_by_armory
rpcpassword= (an alphanumeric string, length 44 bytes)
Found no explication for that.
May a ask wether this is my (encrypted) password and a security risk?
In the long run, I'd like to have a server version that uses a real database. By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server. Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory. LevelDB is a great choice for the end-user version of the software. But for the server version, I can have something more heavyweight. And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.
This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.
I plan to keep the full version. And keep it "encouraged,", but there's gotta be a lighter version of it for the non-power-users. There's only so much impact Armory can have in its current incarnation of making users wait 8+ hours to download the blockchain (and it will be much longer as time goes on). I have a few directions I want to go with it, but there will always be a full-node version of it. And the server/super-node is for the radix-tree stuff, so it can act as an oracle for arbitrary wallets, much like Electrum servers do right now.
Also, the radix-tree stuff has the goal of eventually improving the network in a lot of different ways. It will make lite nodes almost as secure as full nodes. And it looks like it may not be an excessive amount of extra work for full (but pruned) nodes. If it's successful, I think it can change the network. amiller/socrates actually believes there's a way to expand it to allow lite-nodes to do full verification.. I'm not sure I believe him, but I haven't had the time to try to grok his proposal. I just know it's something I'm looking forward to looking into when I get all the immediate priorities out of the way.
Just curious, do you see any unusual growth in the number of downloads/pageviews in the last two days? The state-controlled television in China did a half-hour program on bitcoin, which may have driven the daily bitcoin-qt download count of China to go up by about 20 times, putting it ahead of U.S, by a 1000% margin, I wonder if the impact can also be felt by Armory.
In the long run, I'd like to have a server version that uses a real database. By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server. Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory. LevelDB is a great choice for the end-user version of the software. But for the server version, I can have something more heavyweight. And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.
This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.
I plan to keep the full version. And keep it "encouraged,", but there's gotta be a lighter version of it for the non-power-users. There's only so much impact Armory can have in its current incarnation of making users wait 8+ hours to download the blockchain (and it will be much longer as time goes on). I have a few directions I want to go with it, but there will always be a full-node version of it. And the server/super-node is for the radix-tree stuff, so it can act as an oracle for arbitrary wallets, much like Electrum servers do right now.
Also, the radix-tree stuff has the goal of eventually improving the network in a lot of different ways. It will make lite nodes almost as secure as full nodes. And it looks like it may not be an excessive amount of extra work for full (but pruned) nodes. If it's successful, I think it can change the network. amiller/socrates actually believes there's a way to expand it to allow lite-nodes to do full verification.. I'm not sure I believe him, but I haven't had the time to try to grok his proposal. I just know it's something I'm looking forward to looking into when I get all the immediate priorities out of the way.
In the long run, I'd like to have a server version that uses a real database. By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server. Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory. LevelDB is a great choice for the end-user version of the software. But for the server version, I can have something more heavyweight. And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.
This scares me a lot. The reason I like armory so much is that it was the closes thing to a full node we currently have for home users. I hope you can still keep it as much as to a trust-less system as possible.
Jump to: