v15.0 Testing

codablock

codablock

Active member
Release candidate v0.15.0.0-rc4 is ready for testnet!

Github release candidate: https://github.com/dashpay/dash/releases/tag/v0.15.0.0-rc4
Release notes are not ready yet and will be prepared in the next few days. Post will be updated.
Gitian sigs can be found here: https://github.com/dashpay/gitian.sigs

Before testing:
Make sure you made a backup of your mainnet datadir somewhere or at least a backup of wallet.dat/dash.conf;
Or use the -datadir and -conf parameters to use completely different directories.

This release contains many maintenance related changes. Largest part is the backporting of Bitcoin 0.15 (excluding features we do not want) and the removal of a lot of legacy code (remains of the legacy masternode list code and all of the legacy InstantSend code). Governance is mostly untouched. PrivateSend got slightly improved. Details will follow in the release notes.

We expect this upgrade to be quite seamless compared to the v13 or v14 release, as there are no on-chain consensus related changes involved. Effort for integration partners should be minimal, as only a few RPC parameters and return codes changed.

The usual testing should be performed to make sure everything works as expected:
- Check if normal transactions are still working, perform some automated load testing if you want. All transactions should get InstantSend locked
- Check if ChainLocks are happening on new blocks
- Check if creating and voting on proposals work. Also check if winning proposals get paid and other don't.
- Test if PrivateSend is working. Make sure to use the recently added ability to mix in many sessions in parallel (note that this feature requires you to also enable multi session support which is off by default).
- Run a masternode or two, make sure it is paid. Instructions can be found here: https://docs.dash.org/en/stable/masternodes/setup.html

What else you can do:
- Report serious issues (crashes/hangs/GUI glitches) : https://github.com/dashpay/dash/issues/new

Testnet tools (explorers, faucets, pools): https://www.dash.org/forum/threads/testnet-tools-resources.1768/
For now, only the faucet at http://test.faucet.masternode.io/ is known to be well funded. It should have enough for everyone.

MNOs:
Wiki: https://docs.dash.org/en/stable/developers/testnet.html#masternodes
Sentinel : https://github.com/dashpay/sentinel/tree/develop

NOTE: Make sure you pulled Sentinel from `develop` branch and changed network to `testnet` in `sentinel.conf`. If you already have a mainnet masternode on the same server, do NOT run testnet masternode in the same datadir as your mainnet masternode (i.e. `.dashcore`). Create new folder specifically for testing (e.g. `.dashcore_test`) and make sure you use `-datadir=<yourtestnetdatadirhere>` cmd-line parameter for dashd and dash-cli. You'll also need a separate crontab line for testnet Sentinel. If you are not 100% sure what you are doing, I'd recommend setting up a new machine/instance for testing purposes only instead of reusing your mainnet server.
 
Last edited:
In order to safely do the testing on a Windows machine, you can follow the guide from last time.
https://www.dash.org/forum/threads/v14-0-testing.44047/#post-208638
You can also add the parameter -windowtitle="My Custom Title" in the target dialogue box which is handy when running multiple instances of the GUI.

upload_2019-12-14_17-10-8.png


We are also updating this faucet and adding a bunch of tDASH to it soon, so check it in a while if you need some coins.
http://faucet.test.dash.crowdnode.io/
 
GUI updates looking really good, all artefacts related to HiDPI screens seem to be almost completely resolved! Just one issue with bold text being cut off in my GUI:

uO5vmKM.png
 
Last edited:
rc1 compile is not working. (Linux from Scratch - GCC-9.2.0)
stacktraces.cpp:48:10: fatal error: backtrace.h: No such file or directory

Which source is needed to get the backtrace.h file?
dash-0.14.0.5 compiled with no problem.
 
@netkeeper I had the same issue. Now, I can't recall the precise set of circumstances that led to it, but ... it is probably associated to either (a) you aren't allowing the depends build system to download and build the libbacktrace tarball, or (b) that does happen, but your build is forgetting where the lib and include directories are after it is built.

I need a bit more information about how you are building this. Is this via a packaging system? Like RPM or a DEB? (I am not familiar with Linux from Scratch). The reason I ask is because when you build an RPM, the system locks down the environment far more strictly than if you were to just build the application from the commandline (DEB is probably less strict). And if you use a OS build environment like I do (mock) the conditions get even more strict.

My source builds are here. The RPM specfile is rather complex (and there are a bunch of stub-instructions still left in), but if you are savvy, you can maybe figure out what I do. I am successfully building on Fedora 29, 30, 31 and EL8 ... no network connection needed (which is the standard requirement for most OS native packaging systems), but only if OS-supplied libraries are leveraged. BUT I haven't gotten builds to work precisely how the DCG blesses the process, not in an RPM build environment. I do this by pre-downloading the stuff that the OS doesn't supply (bls-signatures, libbacktrace, and for EL8 miniupnpc and db4), including them in the source RPM, and feeding that into the depends build tree at the right time.

I'm t0dd#9866 on the various discord chat servers.
 
Last edited:
netkeeper said:
did it! thank's for the infos :)
Linux from Scratch has no packaging system. All packages compiled from source.
GCC has no rules for installing "libbacktrace" libs and includes. (recompile didn't work)
so, I used this source: https://github.com/ianlancetaylor/libbacktrace
Click to expand...

Well, the packaging is in tarball form. ;)
Reminds me of Slackware from back in the day.

If you want to use the exact tarball requested by the system, it is this:
https://github.com/rust-lang-nurser.../libbacktrace-rust-snapshot-2018-05-22.tar.gz
with sha256sum of ...
8da6daa0a582c9bbd1f2933501168b4c43664700f604f43e922e85b99e5049bc
 
I have a problem when import private key with the version running on Linux (Ubuntu). The program suddenly quit during scanning blockchain after import private key.
 
Last edited:
netkeeper said:
did it! thank's for the infos :)
Linux from Scratch has no packaging system. All packages compiled from source.
GCC has no rules for installing "libbacktrace" libs and includes. (recompile didn't work)
so, I used this source: https://github.com/ianlancetaylor/libbacktrace
Click to expand...

How are you getting gcc on Linux from Scratch? (I have never messed w/this.) Do you have glibc installed? If so the backtrace libs are likely already installed as part of glibc. There should be no need to install any extra libs (other than glibc). The include is execinfo.h, and again, if using glibc I don't think the -lexecinfo is required.

Here is more info:

https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
 
Yes i have glibc compiled. It has no rules for installing backtrace, same gcc.
And I see no backtrace in the glibc sources. I think if a package needs backtrace they use their own implementation like gcc.
Same in other Linux Systems as well. Arch Linux for example used also a separate Package for installing the backtrace libs.
https://aur.archlinux.org/packages/libbacktrace-git/
 
netkeeper said:
Yes i have glibc compiled. It has no rules for installing backtrace, same gcc.
And I see no backtrace in the glibc sources. I think if a package needs backtrace they use their own implementation like gcc.
Same in other Linux Systems as well. Arch Linux for example used also a separate Package for installing the backtrace libs.
https://aur.archlinux.org/packages/libbacktrace-git/
Click to expand...

The backtrace funcs in glibc are part of execinfo. You can find them here (this is an unofficial GitHub mirror of the glibc source):

https://github.com/bminor/glibc/blo...d39bde15bea9daf3e271/debug/execinfo.h#L27-L38

You would use -lexecinfo and include the execinfo.h header for this.

You can install an external version, some have been developed for drop-in compatibility, e.g. for non-glibc environments like musl. But the depends system as configured without any other installations as per the documentation uses the glibc one.


edit: I just saw the missing backtrace.h error, didn't realize that was the one. You are right that this lib is installed separately. Looks like this is installed as a depends package. FWIW there is a comment in the source:

Code: 
// FYI, this is not using libbacktrace, but "backtrace()" from <execinfo.h>

I'm not sure what part of the Dash code calls to the external lib and what calls to the execinfo one.
 
Last edited:
bhkien said:
I have a problem when import private key with the version running on Linux (Ubuntu). The program suddenly quit during scanning blockchain after import private key.
Click to expand...

Are you getting an out of memory error, or do you have any other info that would help debug? And are you able to reproduce this consistently?
 
Always interesting to see a v0.15 release notes draft pull request emerging on Github. I am guessing we are waiting for a few more translations and then its show time.
 
qwizzie said:
Always interesting to see a v0.15 release notes draft pull request emerging on Github. I am guessing we are waiting for a few more translations and then its show time.
Click to expand...
Aye, it looks ready to be deployed, have you seen the 16.0 PRs flooding the github? Things are moving along quickly.
 
You must log in or register to reply here.
Back
Top