Can do. Is autotools not a dependency for gitian, or is that wrong?
It is, and that's end game here. But autotools itself is a messy thing, that got me spending the best part of a week just to get Armory back into the state it was with plain makefiles. So... baby steps =) |
|
|
|
Both the Create Wallet button and dropdown selection yields this: Traceback (most recent call last):
File "ArmoryQt.py", line 3456, in startWalletWizard
walletWizard = WalletWizard(self, self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 103, in __init__
self.walletBackupPage = WalletBackupPage(self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 307, in __init__
WalletBackupFrame(wizard, wizard.main, wizard.tr("Backup Wallet")))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 807, in __init__
self.featuresLbls[F.ProtGen] = MkFeatLabel(self.tr('Protects All Future Addresses'))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 806, in <lambda>
MkFeatLabel = lambda x: QRichLabel(tr(x), doWrap=False)
NameError: global name 'tr' is not defined
...and no Create Wallet dialog Will go over these once the autotools branch is ready. On that note, would you mind pulling that branch and trying it out? You need to setup git submodules this way once you check out the branch: git submodule init
git submodule update
Then you can build the usual autotools way: sh autogen.sh
./configure
make
make dist works, but make install doesn't yet. |
|
|
|
OK.
Do you know how the block data get corrupted? I'd think there's some kind of verification process after the block has been downloaded, for example a hash of the block that can be verified, and if it's not adding up, then it should be downloaded over again?
And there is not some kind of repair tool that can fix only the blocks that are wrong? Would save a lot of bandwidth for the bitcoin network.
Core downloads blocks, verifies them, then appends to disk. It does not verify what goes on disk, and this is where you are having trouble. It is possible your machine is unstable as well. I would suggest you try to rebuild the database with a lower thread count (--thread-count) and record where/if the build fails again. If it always hits the same spot, then your blockchain data is damaged. If it doesn't, then your system is not stable enough to handle a heavy CPU load. |
|
|
|
Hi, I just wrote it down by hand, maybe thats the most secure anyway  Sure I can help you debugging, so I am in for beta. Don't forget to write down the wallet ID and version as well. |
|
|
|
|
This is a bug. You can either try to print from a different OS (say some Ubuntu flavor will prolly get it right), or participate to the 0.96 testing phase to help me fix the issue for the next version.
|
|
|
|
More of the same. I get some kind of hex number on 192.168.2.32:80 showing the HTTP daemon is working I guess but ArmoryQT is still throwing the same error. EDIT: After looking through the forum, I found this which is the exact same setup I have but nginx is listening on port 80 instead of 9002. https://bitcointalk.org/index.php?topic=1617087.20His issue was specifically *nix server to Windows client No? I thought it was only required for many client. I might have misunderstood the release notes.
Will put behing nginx and report back.
DB only has a fcgi layer (this is what PHP uses, as an example). You need consider the DB as something like a MySQL server. It isn't meant to be exposed to the WAN directly, nor an insecure LAN, because it does not have the necessary code to allow users to setup networking rules nor load balancing. That's what the public facing daemons are for. The DB is hardcoded to listen to localhost. You can change the FCGI listen port but not the IP. You need to run the daemon in front of it to allow clients to access it remotely. Since this is FCGI, the client uses HTTP over the socket, which is why it is fairly easy to setup a daemon on top of it (and one of the advantages of CGI in general). As a convenience feature, I also implemented FCGI at the client level, so that it may speak with a local DB without the need for the HTTP daemon in between. The client will only speak FCGI if you let it run the default IP:port to connect to the DB. If you change any of those, it will revert to pure HTTP, which the expected daemon on the other side will convert to FCGI for the server's benefit. The server only speaks FCGI (which basically decorates HTTP packets with some meta data). I guess this is an unresolved bug? Will try to run ArmoryQT from a Linux VM tonight as this guy seem to say that it works from Linux ArmoryQT to a Linux ArmoryDB/nginx/bitcoind setup.
Your best course of action is to participate to the 0.96 testing rounds to help me isolate and fix any bug on that front. |
|
|
|
|
Did you put your ArmoryDB behind an http daemon?
|
|
|
|
1) Delete C:\Users\Priit\AppData\Roaming\Armory\databases (ONLY that folder, please don't nuke anything else) 2) Download 0.95.1 https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.13) Start BitcoinQt, let it do it's thing 4) Install 0.95.1, start in offline mode, in File -> Settings, turn off auto bitcoind. 5) With BitcoinQt still running, start Armory the regular way. Let it do its thing. Once it is synced, you are good to go. |
|
|
|
EDIT: Okay, I think I found it. The Python code relies on code in BlockDataViewer.h/cpp. However, that code goes into ArmoryDB. SwigClient.h/cpp appears to have its own BlockDataViewer. This is what Python accesses. The Python BDV doesn't have the code required for the Tx exporting. I'll look into that and see if how easy it would be to copy the code over.
That most likely means this is data that needs to be pulled from the DB. You would have to populate the director with the method, write ser/deser routines and get the client to pull the data. |
|
|
|
Shouldn't just running with -server=1 from bash work? It's not.
Should be fixed now. |
|
|
|
Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.
Fixed. Should DB being shutting down when Client closes even though I run DB separately?
Won't do it anymore now. Test suite is broken. Submitted a PR.
Merged. Also merged the translation PR, have fun with that. Edit: If your PR adds a feature or fixes something I missed from previous versions, please update the changelog as accordingly as well. |
|
|
|
|
0.92 can sign for 0.95, sure.
|
|
|
|
I see. Will I need to enter the command line manually every time I use armory or is there a way for it to save this change?
In 0.95, yes. For the next version I'm introducing config files for DB and client. |
|
|
|
Should DB being shutting down when Client closes even though I run DB separately?
DB now uses a cookie file setup to authorize special commands like shutdown. Any local client can read that cookie file, which the DB creates under any circumstances. I guess I could add some cli magic in there to make it a bit more intuitive. |
|
|
|
You can use 0.92.
Where can I download 0.92 window version? can't find !! I've got no idea, I never hosted this version myself. What OS is running on your offline signer? |
|
|
|
|
Did you delete the old DB before running then new one?
|
|
|
|
Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf
It looks for .bitcoin/testnet3/bitcoin.conf in testnet. At any rate, it should work if the RPC is off as well. That's a bug that needs fixing. Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in <datadir>/testnet3 instead of in <datadir> as I'm pretty sure Core still uses the one in <datadir> I did this on purpose. I am aware of the reason why it should use the .conf in the parent bitcoin folder, but it's weird enough that I'd rather not introduce weird edge cases in my own path discovery code. I will move RPC detection to simply probing the socket soon enough. Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one. Already have a fix for that locally. I'm going through the PRs first then pushing this fix. Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it.
That has to do with the dashboard snafu, will fix it soon. |
|
|
|
|
Any error on the db side?
|
|
|
|
Which distribution do you use with your setup that's working?
Raspbian should it be easy enough for someone with CLIphobia?
How has anything Linux not given you a heart attack yet? It's unrealistic to expect a Windows experience on Linux, let alone RPi. Have you considered offering an official image that contains a basic Linux distribution with Armory already built in to make it dead easy for people to use Armory as a cold wallet on a raspberry pi by just flashing an SD card?
I don't think that's necessary. NOOBS makes setting up Raspbian really easy. Then it's just a matter of installing the .deb offline packet, which should be a single command: I made the current offline bundle when Raspbian was based off of Wheezy. I'm pretty sure they moved to Jessie now, so I can see how the old offline package would be broken. Your best bet is to wait for 0.96, where I'll making a new batch of offline signer bundles to support the new signer code. |
|
|
|
|
Show Posts
