Topic: [ANN] [DRZ] [DROIDZ] [ANTI-INSTAMINE] - A FRESH NEW START - WALLET UPDATES!!! - page 29. (Read 48442 times)

wow ...

i sleep for one night and all this happens ( 2 pages worth ) ... hehehe ...

@drays ... i know ubuntu is the more widely used now - and also know that these things in the code are required ...

BUT - the fact that centos IS the os thats being used AND that without redhat based compilation will mean that users and redhat professionals will be REQUIRED to move to a debian based os is not a good thing ... the wider the distribution - the better ...

btw - kudos on the compilation ... as ive mentioned earlier - on ubuntu - it does have a more mature openssl implementation that redhat based systems due to the thickheadedness ( yes - i made that word up ) of redhat legal team ... so under ubuntu ( or almost any debian based os ) it is a more straightforward compile ...

that is not what my issue is ... redhat is STILL the number one os used in corporates and businesses worldwide - which means if a compiled system runs in it - there will be a much wider use than 'just' the crypto and 'hobby' users ... and that is more the goal of the larger picture ...

you have done an awesome job though with the debian compile - dynamic build im guessing? ... is it os / gcc specific if that is the case? ...

and tanx so much for sharing the code changes - but the paths are only a part of the issue in redhat based systems unfortunately mate ...

which does frustrate me ... a little ... :| ...

#crysx

Sorry, I misread what you were saying.  I'm not well versed on the different OS's or Architectures yet.  I know the Rpi2 is ARM, but my logic was based off what you were saying:

* I believe the vast majority of Linux users use Ubuntu nowadays.
* but currently Ubuntu seems to the best and most mature option, especially taking into account the fact it runs well on ARM devices (like Raspberri PI2 or other ARM devices I use)
* BTW, I have compiled the new DRZ.V3 QT wallet on Ubuntu

That's how I came to think the wallet you compiled would run on my Rpi2.    

Has anyone got a sort guide?

As too, what I need to do to keep supporting Droidz?

Yes. And it currently has two connections. which are not on the same network ie Lan so it should work

Is this node (92.233.105.4) running now? Cannot connect to that, neither from wallet, nor via "telnet 92.233.105.4 5914"...

I have an Rpi2, and tried to run it.  Didn't work.

However, could be that I'm running a messed up version right now anyways.  I had Raspbian installed, and everyone was saying use Jessie.  So I tried it.  (This was early last year) and my usage monitor was constantly stuck at 25%.  (One thread locked?) So basically what I did is go back to Raspbian and just took bits and pieces of Jessie.  I compiled 5 wallets (HYP, BALLS, BUCKS, CIRC, and DRZ) and they all worked great.  Never looked back...

I can certainly try the full blown version again tomorrow and see what happens, and see if that makes a difference in running your files.

Issue's Connecting. Then Follow.

Create a file called droidz.conf
inside paste the following

listen=1
server=1
daemon=1
rpcuser=YOUR USER NAME HERE
rpcpassword=YOUR PASSWORD HERE
rpcport=5915
port=5914
rpcallowip=127.0.0.1
addnode=92.233.105.4

Save the file as droidz.conf make sure the extension at the end is .conf not .txt
Then place it inside AppData/Roaming/Droidz2 Windows and Inside the folder called ./droidz2 on Linux
Then Re Open wallet and you should be good to go

I believe the vast majority of Linux users use Ubuntu nowadays. I was using Redhat, then Centos (liked it a lot), but currently Ubuntu seems to the best and most mature option, especially taking into account the fact it runs well on ARM devices (like Raspberri PI2 or other ARM devices I use), unlike Centos, which is purely x86-oriented...

BTW, I have compiled the new DRZ.V3 QT wallet on Ubuntu - the only modification needed was to fix the path to the secp256k include files (it should be
"INCLUDEPATH += src src/json src/secp256k1/include src/qt src/qt/plugins/mrichtexteditor" instead of "INCLUDEPATH += src src/json src/secp256k1 src/qt src/qt/plugins/mrichtexteditor" in the "Droidz-V3.pro". I can put the compiled wallet on Mega if someone needs.

Am compiling the daemon now. Had to modify the "makefile.unix":
1. Replaced spaces with tab in every line where the target compile ru7les are specified. Otherwise my compiler tells "makefile.unix:187: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop." and stops.
2. Also had to add "DEFS += $(addprefix -I,$(CURDIR)/secp256k1/include)" for it to find the embedded SECP version.

And of course, had to "chmod 777 build_detect_platform" as (almost) always

Its compiling now (my server is not the fastest), but I expect it to finish well soon.

EDIT: finished compiling the daemon. Seems to run well, waiting for connections
EDIT2: https://mega.nz/#!u9sVxAaK!TOUsXyjOXkhidBwbY8wmowQ4bbj6HdPc2ypToXKrw38 (both the daemon and the QT wallet), in case anyone wants to test

EDIT: finished compiling the daemon. Seems to run well, waiting for connections
EDIT2: https://mega.nz/#!u9sVxAaK!TOUsXyjOXkhidBwbY8wmowQ4bbj6HdPc2ypToXKrw38 (both the daemon and the QT wallet), in case anyone wants to test

this has actually changed from the original compilation - as it only required that for the daemon compile ...

now the code is a little different - as it uses its own implementation of secp256k1 ecc - and as far as i know - ubuntu ( debian based os ) does actually have a solid implementation of the elliptical curve cryptography within openssl ... fedora ( and most redhat based system ) do not ... with fedora 22 / 23 being the exceptions - being the first to have a 'limited' implementation of this ecc ...

so for those that are redhat people ( like me ) - we need to figure out what it is that will allow this to compile properly with the current status quo of the os ...

in the case of centos 7 x64 ( which almost all my vps's are based ) - these required the building of ALL the components as static builds ( from openssl to bdb ) - and then implementing those static results into a static build of the daemon ...

this no longer works with the current code - unfortunately ... let alone the qt5 build ( which is a dynamic build ) under fedora 23 x64 ... also a redhat based system ...

but - we are well underway to getting things sorted - it will just take time ...

im working closely with the devs on the linux compiles anway - to ensure that the majority of linux and windows systems are covered ... so that as a community - you can rest assured that it WILL work with the os of your choosing ...

when the daemons are running and functional - we will make sure the permanent seednodes are as well ... and if all is well - will have them hardcoded also ... that is determined by the core dev of course ...

tanx for you help in any case ... i really appreciate it ...

#crysx

Yes the wallet is Functional at the moment with Masternodes due to start the 14'th of Jan. Which is why we wan't most coins swapped by the 12'th the latest hopefully. The Ratio will be 1:1 yes.



Also we have had a response from Richie at Bittrex. Does not look to good on that front if i'm honest. We will still see what we can do. I have just messaged back in response to this.

After swap , wallet will be fully functional with all promised features?
Masternodes/Darksend, 1:1 ration...

Hey,

So this looks pretty straight forward but we have started charging for swapping services just because they are very time consuming and cause all sorts of logistics and support nightmares. 

Is the swap something you can support yourselves?  It looks like you have other exchanges already doing it... can we just have users withdraw there and be done with?

Also, is there a reason why you are doing a full swap instead of just using the same blockchain?  We've seen people rebase and still use the existing blockchain so a swap wasn't needed?

We're here to help, but swapping the blockchain is usually a last resort and i'm personally not a big fan of it.

Thanks,
richie