Topic: Starting preliminary 0.94 testing - "Headless fullnode" (Read 15097 times)
Ok
No sorry. I can't reuse the existing 0.94 code, I'll have to put something together from the ground up.
Great. In early February I hope, as you stated before? 
There are some complications but I still intent to get something out in February. There will be an announcement shortly to clarify things up.
Is there any chance that the 0.94 version will be released soon ?
Late Jan/early Feb.
But we can't trust it anymore because it is closed source ...
or am I wrong?
That's an ETA for a fully open source release.
~120G "waste of space" is becoming real annoying in my 256G laptop's SSD, while I have tons of HDD space on my servers. Is there any chance that the 0.94 version will be released soon ?
Late Jan/early Feb.
But we can't trust it anymore because it is closed source ...
or am I wrong?
That's an ETA for a fully open source release.
Is there any chance that the 0.94 version will be released soon ?
Late Jan/early Feb.
But we can't trust it anymore because it is closed source ...
or am I wrong?
Counting down... 
oh boy, I'm in trouble now.
Is there any chance that the 0.94 version will be released soon ?
Late Jan/early Feb.
Counting down...
Is there any chance that the 0.94 version will be released soon ?
Late Jan/early Feb.
They made Armory closed-source, which is why you don't find the latest tree on github anymore. There won't be any open releases. As far as I noticed, this step was done without any public communication.
I am on Debian based Linux.
Is there a fix for this?
Code:
./autogen.sh
./configure
make
Code:
python ArmoryQt.py
File "ArmoryQt.py", line 2
exec python /usr/local/lib/armory/ArmoryQt.py "$@"
^
SyntaxError: invalid syntax
Is there a fix for this?
The advertised branch ffreeze is missing: https://github.com/etotheipi/BitcoinArmory/tree/ffreeze
In the similar gitian-ffreeze branch make is broken (no 'Makefile', Makefile.old doesn't work)
In the similar gitian-ffreeze branch make is broken (no 'Makefile', Makefile.old doesn't work)
Hey Armory folks,
In my occasional view of both bitcoin core and armory's code, I noticed that a recent commit to armory's ffreeze branch that put it in a gitian branch. I'm curious if this means that we are getting close to getting pre-built test builds of 0.94?
In my occasional view of both bitcoin core and armory's code, I noticed that a recent commit to armory's ffreeze branch that put it in a gitian branch. I'm curious if this means that we are getting close to getting pre-built test builds of 0.94?
Comment out this line:
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/ArmoryQt.py#L2619
It will prevent the ZC container from parsing any new tx. This is the most likely culprit atm.
Since the crash occurs intermittently, I commented out addNewZeroConfTx() in one system and
ran the second system unpatched. The patched system has not crashed so far, but the unpatched
system has crashed several times. So, it looks like the problem is in the "zero confirmations" code.
I will use the fix on both systems. Thanks for providing a good work-around patch.
What's the total size of your DB? The headers DB alone?
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588
Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588
Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.
I reduced MAX_MAPSIZE_INCEREMENT from 256MB to 16MB, re-compiled, and --rebuild.
The databases are now:
20819968 2015-08-31 00:57 blocks
107724800 2015-08-31 00:57 headers
After a couple of days of uptime I got the std::bad_alloc crash.
I'm running an identical copy of bitcoin-qt/Armory on a newer desktop that has 16GB dram.
I got the std::bad_alloc crash on that machine too, just like the laptop.
I also got the std::alloc crash when sending to a "normal" wallet.
In one instance so far, I started Armory at 23:50 and sent BTC at 00:10 and got std::alloc.
Is there any code in Armory that uses "current time - previous time" and doesn't handle
a negative value?
Comment out this line:
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/ArmoryQt.py#L2619
It will prevent the ZC container from parsing any new tx. This is the most likely culprit atm.
What's the total size of your DB? The headers DB alone?
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588
Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.
https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588
Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.
I reduced MAX_MAPSIZE_INCEREMENT from 256MB to 16MB, re-compiled, and --rebuild.
The databases are now:
20819968 2015-08-31 00:57 blocks
107724800 2015-08-31 00:57 headers
After a couple of days of uptime I got the std::bad_alloc crash.
I'm running an identical copy of bitcoin-qt/Armory on a newer desktop that has 16GB dram.
I got the std::bad_alloc crash on that machine too, just like the laptop.
I also got the std::alloc crash when sending to a "normal" wallet.
In one instance so far, I started Armory at 23:50 and sent BTC at 00:10 and got std::alloc.
Is there any code in Armory that uses "current time - previous time" and doesn't handle
a negative value?
Interesting idea. Admittedly, I'm not entirely sold on the idea of a separate package. There's too great a chance that people will be lazy and leave two copies on their system, potentially leading to weirdness down the road. For example, if somebody had 0.93-testing and tried to go back to 0.92, the Armory DB would keep getting nuked and lead to constant rebuilds.
Unfortunately, I don't think "But only people who know what they're doing will install it!" is correct. It wouldn't be hard for us to miss posts on, say, Reddit, and end up with somebody suggesting people try a test version that fixes one problem but introduces another.
Unfortunately, I don't think "But only people who know what they're doing will install it!" is correct. It wouldn't be hard for us to miss posts on, say, Reddit, and end up with somebody suggesting people try a test version that fixes one problem but introduces another.
Agreed. I'm looking at all these user complaints from 0.92-0.93 and trying to think of a way to wish them away without actual magic, but there is no good compromise (as the terminally pessimistic will tell you about everything
). It'd be nice if more people were accustomed to using virtualisation, but I guess it's not that time yet. I'll probably be waiting impatiently for everyone to adopt some other new sophistication by then 
(Just FYI, Reddit was just an example. Some of us do check Reddit on occasion. We typically prefer this forum, though.)
Really? Slightly amazed. I guess the Armory sub is much quieter than /r/bitcoin
Suggestion (possibly devs already thought this):
Create a package that isn't "armory" for the testing releases (armory-testing?).
Rationale: the majority of users still use a monolithic OS; only one instance of a package can be installed on such a machine. There are alot of people out there who might benefit from using this upcoming test release instead of the main release, and the process would benefit from as wide a potential testing base as can be. A separate package would allow those who run release Armory to see whether 0.94, for instance, alleviates their issues or not, without having to contemplate uninstalling "armory-testing" and re-installing Armory main release.
Create a package that isn't "armory" for the testing releases (armory-testing?).
Rationale: the majority of users still use a monolithic OS; only one instance of a package can be installed on such a machine. There are alot of people out there who might benefit from using this upcoming test release instead of the main release, and the process would benefit from as wide a potential testing base as can be. A separate package would allow those who run release Armory to see whether 0.94, for instance, alleviates their issues or not, without having to contemplate uninstalling "armory-testing" and re-installing Armory main release.
Interesting idea. Admittedly, I'm not entirely sold on the idea of a separate package. There's too great a chance that people will be lazy and leave two copies on their system, potentially leading to weirdness down the road. For example, if somebody had 0.93-testing and tried to go back to 0.92, the Armory DB would keep getting nuked and lead to constant rebuilds.
Unfortunately, I don't think "But only people who know what they're doing will install it!" is correct. It wouldn't be hard for us to miss posts on, say, Reddit, and end up with somebody suggesting people try a test version that fixes one problem but introduces another.
(Just FYI, Reddit was just an example. Some of us do check Reddit on occasion. We typically prefer this forum, though.)
That said, it's something to keep in mind moving forward. Pros and cons, as always.
Suggestion (possibly devs already thought this):
Create a package that isn't "armory" for the testing releases (armory-testing?).
Rationale: the majority of users still use a monolithic OS; only one instance of a package can be installed on such a machine. There are alot of people out there who might benefit from using this upcoming test release instead of the main release, and the process would benefit from as wide a potential testing base as can be. A separate package would allow those who run release Armory to see whether 0.94, for instance, alleviates their issues or not, without having to contemplate uninstalling "armory-testing" and re-installing Armory main release.
Create a package that isn't "armory" for the testing releases (armory-testing?).
Rationale: the majority of users still use a monolithic OS; only one instance of a package can be installed on such a machine. There are alot of people out there who might benefit from using this upcoming test release instead of the main release, and the process would benefit from as wide a potential testing base as can be. A separate package would allow those who run release Armory to see whether 0.94, for instance, alleviates their issues or not, without having to contemplate uninstalling "armory-testing" and re-installing Armory main release.
Jump to: