Topic: Armory 0.96.1 is out! - page 2. (Read 6701 times)

Your CPU is old, you'll have to build from source.

Installed 0.96.1.
Logos not appearing Applications.
When I try armory or ArmoryDB in the command line (in the /usr/bin directory) it keeps saying 'Illegal instruction (core dumped)'
Also tried 'sudo apt autoremove' which didn't make any difference.

It is, and it shouldn't trigger a freeze. Post your logs for investigation.

is Coin Control enabled?  GUI freezes whenever i click it.

Updating armorydb to 0.96.1.2 fixed this.

Cheers,

Ente

..a bit late to the show here:
I upgraded armoryqt to 0.96.1.2, armorydb (another machine) is still on 0.96 or 0.96.1 though.
Installing runs fine.
Executing armoryqt gives
in the terminal. And I see no tx entries in the tx history window.
Didn't look around more yet. I should upgrade armorydb and/or checkout 0.96.2 tomorrow I guess?

Thanks and cheers,

Ente

The Transaction info dialog [GUI, bottom panel, Transactions tab, context menu, View Details] shows "not in the blockchain yet" for all incoming transactions that arrived during the current session (even after 20+ confirmations). Confirmations and balance are all updated in real time, as expected. Restarting the GUI helps, then it gives me a block and tx #. Probably just the UI not updating.
(No anomalies for outgoing transactions, AFAICT.)

Yeah, I seem to recall Alan stating at one point or another that, at a certain point, he just went with whatever worked, especially for user-donated code to get things like Armory on Macs running. There's quite a bit of leftover technical debt. (Not knocking Alan, just stating facts.)

I used the word complain in the sense that no one raised an issue with the build dependency, therefor I never gave it much attention. I simply grand fathered it from the legacy Makefile when I reworked the build process in autotools. I seriously have no idea why it was preferred over more common calls to copy files around, but when you've battled autohell for 2 weeks in a row, your bar for acceptable code has long moved from "ideal" to "if it works I'll take it". I'm guessing this is the state of mind etotheipi was in when he wrote his Makefile.

As for the updated build dep instructions, that was PR'ed in, and that's more symptomatic of my build setup than anything else: My machines have had all the stuff I need to build for years now, therefor are dark areas of the build system in the sense that I just have no idea if the dependency is common to most distros or if it's something I'm shoe horning by negligence.


For whatever reason, the images in for the deck of cards are being read from the file system instead of the pyqt image resource. It's an easy fix, but again a symptom of stuff I overlook cause my build system is set in such a manner I just don't get to see this bugs. That and the small test coverage I get for GUI.

I certainly didn't mean to complain, sorry if it sounded that way. FWIW, I'm really happy with the direction Armory is going and the pace it's going there is incredible, especially for a one-man show.

That's something I inherited from the previous maintainer. I want to move to libbtc.


Inherited that too, no one has complained about it either. As for the stuff being built by make install, blame SWIG, or Python in general.


Will have to look into it.

I suppose the same rationale goes for the local copy of crypto++? I'm a bit weary of whole projects of source copied in verbatim in general -- it tends to either remain in the initial imported state forever or drain resources from the importing project (which has just one man, as it stands). Case in point, even Debian stable looks to have a newer version.

A couple of observations / buglets:
* build docs: add pkg-config and rsync, remove python-twisted as build-deps
The build process is a bit byzantine, why does it need rsync at all and why is there so much code being built during make install ...
* pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)?
* pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?

libfcgi is statically linked in, and I've modified some of it. I'm looking to do web sockets at some point and get rid of fcgi eventually, so I don't want to struggle through dynamic linking it and all the build process mods.

As for the --without-online part, that's kinda tricky with autotools. It would make the DB compilation part optional as well, and you need a constant baseline to do that optional compilation switching without large headaches.

On the other hand, the DB is pure C++ and shares a few code files with the GUI, so if you can build the GUI, you can build the DB. Therefor, in terms of build process, the DB does not introduce more dependencies so it's the natural baseline.

For offline systems, you'd want to remove the client with --offline anyways, therefor the effort required to allow this at the configure script level is not justified to begin with.

Thank you for --without-gui! That gets rid of all the QT and Python deps in one fell swoop.
And since you're already fiddling with the build system, how about --without-online to build just the GUI part, for offline systems? ^^ That'd probably also make it easier to keep supporting older systems for offline-only use.

Oh, and why do you maintain your own version of libfcgi? Is it just build fixes or is there more? Since libfcgi is pulled in as a submodule after the fact it presumably isn't covered by the main repos signature checks, so if it works I'd rather install libfcgi-dev and be done with it.

Its impossible to test a software on every system.
There are testing branches what you could build and report bugs or other issues.
Or you just wait before installing newer releases till others reported bugs/issues.


I'll test this version once the BitcoinABC split is done, lot work atm because of that.

I downloaded armory and started it. It never went online.

Then i dowloaded Bitcoin core and had it resync the blockchain. Core is working fine.

Then i started armory again.

Armory does not go online at all even after hours. Also no indication in the user interface or popups that anything is ongoing or wrong.


got this in the log

2017-07-30 23:51:09 (INFO) -- SDM.pyc:169 - Found bitcoind in the following places:
2017-07-30 23:51:09 (INFO) -- SDM.pyc:171 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:173 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2017-07-30 23:51:09 (INFO) -- SDM.pyc:337 - Called startBitcoind
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=C:\\Users\\denni\\AppData\\Roaming\\Bitcoin\\']
2017-07-30 23:51:09 (INFO) -- SDM.pyc:450 - PID of bitcoind: 6192
2017-07-30 23:51:09 (INFO) -- SDM.pyc:451 - PID of armory:   13616
2017-07-30 23:51:09 (INFO) -- ArmoryUtils.pyc:667 - Executing popen: ['.\\guardian.exe', '13616', '6192']
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 1
2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1913 - Setting netmode: 0
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:1895 - loadBlockchainIfNecessary
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode
2017-07-30 23:51:09 (INFO) -- ArmoryQt.py:4644 - Dashboard switched to "Scanning" mode


You need to do path arithmetic with OS specific calls :  2017-07-30 23:51:09 (ERROR) -- BDM.pyc:200 - DB error: C:\Users\denni\AppData\Roaming/Bitcoin/blocks is not a valid path

also, i had thought armory was tested before launch.  i'll get me another wallet.

I'm not telling you to build GCC from source but Armory. If you insist on upgrading GCC, that's actually a complicated task on Debian. You'll want to look at the debian-backport repo instead, but I doubt they have a GCC recent enough in there.


Armory cannot build in 32bit on Windows atm, and I do not intent to do anything about it. The last native 32bit Windows is XP, and Microsoft themselves have dropped support for that OS some years ago.

thanks for the quick response and all the great work goatpig.

i'm sure building GCC from source is easy but as you know, Debian is notoriously lacking in backportability (sp?)  Do you think simply upgrading GCC will be enough or are there further dependencies or issues i should anticipate?

How to export the private key of the certain address from the cold (offline) ARMORY 0.96.1 ? Address Book does not show any addresses/ Under P2PKH is just one word - NONE, nothing else/ The watching only wallet shows list of addresses but is not capable to extract private keys , only public

P. S Found how to do it. All you need is to click backup and then export private keys