One extra step I needed to take was update libstdc++6 (I installed gcc++-8, I'm guessing I could've gotten away with just the lib)
That's surprising, I built the .deb on Ubuntu 16.04. My gcc says 7.2.0
Topic: Armory 0.96.5 RC1 (Read 437 times)
That's surprising, I built the .deb on Ubuntu 16.04. My gcc says 7.2.0
Thanks, I just went with the precompiled binary for now.
One extra step I needed to take was update libstdc++6 (I installed gcc++-8, I'm guessing I could've gotten away with just the lib), which I didn't have to do for 0.96.4. Took a few steps on Ubuntu 16.04.
Also thanks for getting to all the fixes already in the RC1!
One extra step I needed to take was update libstdc++6 (I installed gcc++-8, I'm guessing I could've gotten away with just the lib), which I didn't have to do for 0.96.4. Took a few steps on Ubuntu 16.04.
Also thanks for getting to all the fixes already in the RC1!
Looks like I botched the source file. You'd have to setup through git if you want to build this version.
Is /cppForSwig/fcgi empty?
I just extracted the tar.xz from here: https://github.com/goatpig/BitcoinArmory/releases/download/v0.96.4.99/armory_0.96.4.99_source.tar.xz
When I check that folder:
Code:
Armory Source/cppForSwig/fcgi> ls
aclocal.m4 cgi-fcgi configure.ac doc fcgi_config.h.in images java LICENSE.TERMS Makefile.am perl Win32
autom4te.cache configure debian examples fcgi_config.h.in~ include libfcgi m4 Makefile.in README
Is /cppForSwig/fcgi empty?
Trying to compile from source, and seeing the following error when running ./autogen:
I'm successfully compiled Armory 0.96.4 on this same Docker image, and I haven't tweaked anything in that image since then. Did the dependencies change? How should I debug this?
Compiling the tagged release from the .tar.xz, running on Ubuntu 16.04.
> ./autogen.sh
Preparing the BitcoinArmory build system...please wait
Found GNU Autoconf version 2.69
Found GNU Automake version 1.15
Found GNU Libtool version 2.4.6
./autogen.sh: 1: eval: Syntax error: Unterminated quoted string
./autogen.sh: 1: eval: Syntax error: Unterminated quoted string
I'm successfully compiled Armory 0.96.4 on this same Docker image, and I haven't tweaked anything in that image since then. Did the dependencies change? How should I debug this?
Compiling the tagged release from the .tar.xz, running on Ubuntu 16.04.
After testing this, it turns out signing a tx with a bech32 recipient using 0.96.4 will result in 0.96.4 extracting the pubkey from the script and paying to it using a standard p2pkh script. Obvioulsy cannot have that. I'll have to add versioning to the unsigned tx packet to stop previous versions from doing anything with these specific transactions.
not sure, didn't actually check (never used armoryd). Preview in online 96.4.99 shows a P2PKH address in place of bech32 address and script type as PKH, but only if signed using 96.4.0. If bech32 is signed using 96.4.99, address and it's script type is bech32 as expected. Well, it actually says P2SH segwit for the script type, but I assumed that's just cosmetic.
I haven't tried signing with an older version, I'll look into it.
Signing to bech32 addresses with 0.96.4.0 succeeds, but the transaction it signs substitutes P2PKH for the intended bech32. Presumably this can't be worked around, as you can't force 0.96.4 to understand it's doing something wrong. I'm assuming the result won't be what the user wanted.
Are you saying the output script is P2PKH instead of P2WPKH?
not sure, didn't actually check (never used armoryd). Preview in online 96.4.99 shows a P2PKH address in place of bech32 address and script type as PKH, but only if signed using 96.4.0. If bech32 is signed using 96.4.99, address and it's script type is bech32 as expected. Well, it actually says P2SH segwit for the script type, but I assumed that's just cosmetic.
Signing to bech32 addresses with 0.96.4.0 succeeds, but the transaction it signs substitutes P2PKH for the intended bech32. Presumably this can't be worked around, as you can't force 0.96.4 to understand it's doing something wrong. I'm assuming the result won't be what the user wanted.
Are you saying the output script is P2PKH instead of P2WPKH?
Signing to bech32 addresses with 0.96.4.0 succeeds, but the transaction it signs substitutes P2PKH for the intended bech32. Presumably this can't be worked around, as you can't force 0.96.4 to understand it's doing something wrong. I'm assuming the result won't be what the user wanted.
I'm looking at your PR and it makes me wonder how was the port ever passed before? I need to investigate this before doing anything with the PR. I'll let you know on the github page.
Dev is 0.97, if you gonna PR you should do it against the testing branch, with 0.96.5. If you want to build dev, you need to clone the libwebsockets repo, checkout v3.0.0 or higher, build it, then give that path to the configure script in this fashion:
Ironically, I originally had it relative to testing but then saw that dev was more advanced.
Anyway, I submitted the change required.
I spent way more time on this tiny change that I intended
, at least I have a 18.04 environment now, so the time isn't lost.Quote
Code:
./configure --with-own-lws=/my/path/to/lws
P.S:
The client in dev cannot speak to db, I have not updated that part yet. Considering dropping swig and moving to CFFI to ease to migration to py3.
I was 99% of the way there. I had it compiling but it couldn't find the shared library.
I was going to submit a PR about the port thing and this involved building against the dev branch.
This doesn't seem to be possible using Ubuntu 18.04 apt-get to get dependencies.
In addition to the packages in the linux build instructions, I used the following.
However, the libwebsockets-dev package in 18.04 (and 18.10) is not sufficiently advanced.
I get an error that "lws_fop_fd_t" due to not in the include file.
This typedef doesn't appear in the libwebsockets.h include file until version 2.2.0.
In Ubuntu-18.04, apt-get uses version 2.0.3-3build1.
Even in Ubuntu-18.10, apt-get still uses version 2.0.3-3build1.
I realize that this is the dev branch and things aren't stable yet, but I thought I would flag this.
Being able to build from source is an important feature for Armory. If websockets 2.2 functionality is required, would it be directly included in the repo, like some of the other dependencies?
This doesn't seem to be possible using Ubuntu 18.04 apt-get to get dependencies.
In addition to the packages in the linux build instructions, I used the following.
Code:
sudo apt-get install libprotobuf-dev protobuf-compiler python-websocket libwebsockets-dev libevent-dev
However, the libwebsockets-dev package in 18.04 (and 18.10) is not sufficiently advanced.
I get an error that "lws_fop_fd_t" due to not in the include file.
This typedef doesn't appear in the libwebsockets.h include file until version 2.2.0.
In Ubuntu-18.04, apt-get uses version 2.0.3-3build1.
Even in Ubuntu-18.10, apt-get still uses version 2.0.3-3build1.
I realize that this is the dev branch and things aren't stable yet, but I thought I would flag this.
Being able to build from source is an important feature for Armory. If websockets 2.2 functionality is required, would it be directly included in the repo, like some of the other dependencies?
Dev is 0.97, if you gonna PR you should do it against the testing branch, with 0.96.5. If you want to build dev, you need to clone the libwebsockets repo, checkout v3.0.0 or higher, build it, then give that path to the configure script in this fashion:
Code:
./configure --with-own-lws=/my/path/to/lws
P.S:
The client in dev cannot speak to db, I have not updated that part yet. Considering dropping swig and moving to CFFI to ease to migration to py3.
I was going to submit a PR about the port thing and this involved building against the dev branch.
This doesn't seem to be possible using Ubuntu 18.04 apt-get to get dependencies.
In addition to the packages in the linux build instructions, I used the following.
However, the libwebsockets-dev package in 18.04 (and 18.10) is not sufficiently advanced.
I get an error that "lws_fop_fd_t" due to not in the include file.
This typedef doesn't appear in the libwebsockets.h include file until version 2.2.0.
In Ubuntu-18.04, apt-get uses version 2.0.3-3build1.
Even in Ubuntu-18.10, apt-get still uses version 2.0.3-3build1.
I realize that this is the dev branch and things aren't stable yet, but I thought I would flag this.
Being able to build from source is an important feature for Armory. If websockets 2.2 functionality is required, would it be directly included in the repo, like some of the other dependencies?
[Edit]
I manually installed the package and looks like it needs v3.0 to work.
This doesn't seem to be possible using Ubuntu 18.04 apt-get to get dependencies.
In addition to the packages in the linux build instructions, I used the following.
Code:
sudo apt-get install libprotobuf-dev protobuf-compiler python-websocket libwebsockets-dev libevent-dev
However, the libwebsockets-dev package in 18.04 (and 18.10) is not sufficiently advanced.
I get an error that "lws_fop_fd_t" due to not in the include file.
This typedef doesn't appear in the libwebsockets.h include file until version 2.2.0.
In Ubuntu-18.04, apt-get uses version 2.0.3-3build1.
Even in Ubuntu-18.10, apt-get still uses version 2.0.3-3build1.
I realize that this is the dev branch and things aren't stable yet, but I thought I would flag this.
Being able to build from source is an important feature for Armory. If websockets 2.2 functionality is required, would it be directly included in the repo, like some of the other dependencies?
[Edit]
I manually installed the package and looks like it needs v3.0 to work.
I don't think I included the quotes when invoking things, but I may have messed up a copy/paste.
The end result is that the python code doesn't actually forward the parameter to the database process.
The end result is that the python code doesn't actually forward the parameter to the database process.
Do you mean this: --dbdir="G:\armory_data/database_dir --debug --satoshi-port=8500"
The quote marks for --dbdir aren't closed, so you end up with
"G:\armory_data/database_dir --debug --satoshi-port=8500"
as the entire argument for the --dbdir parameter
Edit: sorry, that's clearly exactly what you meant.
On top of goatpig's suggestion, I PRed a fix days ago.
And that's even better of course, although I should really have realised that the --satoshi-port option solved the problem in itself. Looking at the code for your patch, it's incredibly obvious
The log files that I included for the satoshi-port fix were unintentionally misleading.
Specifically:
It doesn't actually pass the satoshi-port parameter at all to the db. The dbdir parameter is actually merged together for some reason. I suspect windows decided to "help".
It ended up creating a directory with the name "database_dir --debug --satoshi-port=8500".
The parameter passed to the database is:
I don't think I included the quotes when invoking things, but I may have messed up a copy/paste.
The end result is that the python code doesn't actually forward the parameter to the database process.
Specifically:
Code:
2018-11-14 01:34:40 (WARNING) -- SDM.pyc:396 - Spawning DB with command: ./ArmoryDB.exe --db-type="DB_FULL" --cookie --satoshi-datadir="F:\bitcoin_data_dir\blocks" --datadir="G:\armory_data" --dbdir="G:\armory_data/database_dir --debug --satoshi-port=8500"
It doesn't actually pass the satoshi-port parameter at all to the db. The dbdir parameter is actually merged together for some reason. I suspect windows decided to "help".
It ended up creating a directory with the name "database_dir --debug --satoshi-port=8500".
The parameter passed to the database is:
Code:
--dbdir="G:\armory_data/database_dir --debug --satoshi-port=8500"
I don't think I included the quotes when invoking things, but I may have messed up a copy/paste.
The end result is that the python code doesn't actually forward the parameter to the database process.
works on mainnet, but ArmoryDB doesn't connect to testnet bitcoin nodes. Maybe something to do with the satoshi-port option?
On top of goatpig's suggestion, I PRed a fix days ago.
yeah, that works. The log tells you loud and clear what the error is, who would've guessed that would happen!
Jump to: