search

mastercoin-MSC / mastercore

mastercore info
mastercoin.org
MIT License
24 stars 11 forks source link

Release: binaries and release process #292

Closed dexX7 closed 9 years ago

dexX7 commented 9 years ago

Ideally binaries would be created deterministically via Gitian, which is feasible to some degree.

Due to the rebranding from Bitcoin Core to Master/Omni Core, some adjustments need to be made though.

I basically see three options in general:

Option 1 would be anything but trivial (#289), and I really don't like option 3 for a lot of reasons, so I'm going to focus on 2, and how the release could be handled:

  1. Finalize 0.0.9.1
  2. Merge into upstream (mastercoin-MSC/mastercore or OmniLayer/omnicore?)
  3. Tag the release
  4. Setup build environment in a VM (see: slightly outdated tutorial, which I could update)
  5. Locally revert the file name changes (see: 419045f8a022b9dfd482cd3245331fbe34aa6a24)
  6. Create binaries for Unix, Windows, and ideally Mac
  7. Rename binaries back to mastercored, mastercore-qt, ...
  8. Check that at least two parties come up with identical results
  9. Create file checksums and ideally GPG sign the files
  10. Publish binaries, checksums and signatures
  11. Announce release (blog, forums, mailing lists, ...)

I'd prefer a release based on Bitcoin Core 0.9.4, especially because 0.9.3 misses the BIP 66 switch over logic etc. for the upcoming soft-fork, but this seems to be out of the scope of this issue.

Going this route would provide at least deterministically build binaries for Unix and Windows, and given that the UI release seems to target the end user base instead of integrators, stepping up here seems reasonable and justified to me.

@CraigSellars: I agree that option 2 is the most expedient/reasonable (and let’s use mastercoin-MSC/mastercore for this).

@zathras-crypto: Not sure where my notes ended up here - perhaps wrong thread or a missed click on comment :(

TL:DR; option 2 sounds most viable for me also. Had a few other comments, most not terribly important but one thing I was interested in is trust related to GPG keys - eg I have a GPG key I setup with Faiz a while ago, but how does Joe Q end user know it's my key?

dexX7 commented 9 years ago

@zathras-crypto: average Joe on Reddit will tell you to use 2 factor authorization and no web wallets, otherwise you're risking to loose your coins. Average Joe will also tell you to not use closed source software.

It's not far fetched, and you should not underestimate the average user. In the case of Gitian building GPG signing is part of the process, more or less. Upstream there is a whole repo for "Gitian build signatures" and GPG keys of developers are available in the main repo:

But you may also try git log --show-signature, and you'll see @m21's and most of mine commits are signed, so the identitify is already established. Upstream there is no commit without signature.

Anyway, this is nice to have, but not strictly necessary, so let's focus on the goal:

  1. File checksums and to some degree GPG signed files should be provided so that the user can be sure he or she gets what he should and no one replaced the binaries or alike.
  2. Deterministic building is done to ensure the builder didn't include backdoors (willingly or unwillingly).
  3. Ideally any user can follow the deterministic building route and confirm everything by coming up with exactly the same results. Given that, at least at this point, following this build route involves a hack (namely reverting back to bitcoin file names instead of mastercore), this is probably something for the future.

In the other thread you mentioned the release is mostly overdue, but ping me, if you need support (e.g. how to sign commits, use Gitian, ...).

dexX7 commented 9 years ago

Well, I have good and bad news. And the later is pretty frustrating.

I'm pretty much done with the build guide, and anyone who likes to, can follow the guide step by step to build binaries for Windows:

https://gist.github.com/dexX7/7bca4f21141acaa0ec65

But git cherry-pick/... commit hashes are not deterministic, so the initial route needs a refinement, and I did not notice the implications until now..

The relevant part:

11. Clone and prepare mastercore:

git clone https://github.com/mastercoin-MSC/mastercore.git bitcoin

Note: We are going to use a workaround to use Bitcoin Core's Gitian descriptors, so be sure you don't forget bitcoin at the end of the line.

[image]

Because Omni Core's binaries were renamed to mastercored, mastercore-cli and mastercore-qt, but the build descriptors are intended to be used with Bitcoin Core, the file renaming is temporarily reverted.

Enter the following lines:

cd bitcoin
git remote add workaround https://github.com/dexX7/bitcoin.git
git fetch workaround mscore-revert-rename
git cherry-pick 419045f8a022b9dfd482cd3245331fbe34aa6a24

[image]

Then enter:

git log

Copy or write down the latest commit hash. It might be different from case to case, ... << !

Because that last commit hash is not deterministic, neither will be the build result. :(

A fix for this, which would be another workaround, could be to merge the name revert commit into a special gitian-release-workaround branch and use that as basis for the Gitian builds instead of the current tip/0.0.9.1 release + file name workaround commit.

zathras-crypto commented 9 years ago

On initial thought the workaround branch seems the most prudent, mainly because it's extremely easy (github provides the tools) to compare that workaround branch with the main branch to ensure there is only the file name workaround commit that differs. Certainly less than ideal, but at least it provides a deterministic and repeatable process - ideal we can work towards :)

dexX7 commented 9 years ago

If this is an option, then it should definitely work. :)

zathras-crypto commented 9 years ago

Alrighty, if you submit a pull against https://github.com/mastercoin-MSC/mastercore/tree/github-release-workaround I'll merge it :) We'll want the readme for that branch to reflect what it's for too...

dexX7 commented 9 years ago

The branch should probably reflect the version. I'm going to update the guide tomorrow, and finalize it once the release is tagged, so we have some reference hashes. From this point on it should be pretty straight forward.

zathras-crypto commented 9 years ago

Ah, I was thinking along the lines of that branch would always contain our last tagged/released version so the instructions can stay static and the user would thus always build the latest release.

dexX7 commented 9 years ago

Ah, yeah, this should work as well. I assume there is going to be an explicit tag on that branch?

CraigSellars commented 9 years ago

@dexX7 this https://gist.github.com/dexX7/7bca4f21141acaa0ec65 is fantastic

dexX7 commented 9 years ago

@CraigSellars: thanks! :)

I tested the 32 bit build, and to my surprise it worked to some degree, but crashed around block height 301386 - not sure, if the results until then were correct or not, but I conclude we can only consider 64 bit builds as stable.

I suggest to provide zipped packages, including:

... with a name such as omnicore-v0.0.9.1-rc1-win.zip. Ideally, such a package would also include a README.txt file, maybe also CHANGELOG.txt and COPYING.txt, as well as a sha1sum.txt file with:

85a97cdc1230e53316fd57d6cdabf2c762e05fd7  mastercore-qt.exe
52e068e059e764977b8e6fe9cf3b22e5f164dbb7  mastercore-cli.exe
bcad90d8d157111defbaca807ddda52fcc55ff2b  mastercored.exe

... where the file hashes are those of the build result.

Once a release (in the Gitian branch) is tagged, everyone is welcomed to follow the build path, to compare results. From -rc1 to -rel (release) the guide could be further refined, where necessary, and then uploaded to github.com/.../omnicore-docs or alike, so ambitious end users can a) confirm the build results, b) build binaries on their own.

Given that bitcoin-spock is pretty easy to use from Windows (see https://github.com/mastercoin-MSC/mastercore/issues/294#issuecomment-76881790), this place might further be used to provide additional information, for example with a simple "How to test Omni Core" or "How to use Omni Core" guides.

As alternative, instructions could be hosted on a website, e.g. omnilayer.org -- which should also be the "central location" where binaries are hosted (instead of GitHub).

CraigSellars commented 9 years ago

We weren’t planning on having 32-bit builds at this point in time anyway, so focusing on 64-bit is perfect.

CraigSellars commented 9 years ago

Also, with regards to instructions, we agreed during the all-hands that we’ll deep link from omnilayer.org to individual github pages

zathras-crypto commented 9 years ago

I have some 0.0.9.1-rc1internal builds done outside gitian (mingw) but I'm wondering if we shouldn't just go straight to a tag and use gitian for this release (and skip a release candidate stage as I get the impression we won't have much of an audience until we release).

What are your thoughts @dexX7 around tagging this as 0.0.9.1-rel and publishing, and then moving straight onto 0.0.10 (unless anything crucial comes up on the 9 branch where we need to issue a patch).

CraigSellars commented 9 years ago

I have no objection to this - I also have no objection with a public release of a release candidate, named as such.

dexX7 commented 9 years ago

@zathras-crypto: sorry for the late response. If -rc1 was intended as internal release, and this step is done already, then the next one should be the release imho. There would also be not much harm in pushing a 0.0.9.2-rel, if there appears to be a flaw (which I hope is not ... :)

Gitian can use either a release tag, branch name or commit hash:

URL=/home/debian/bitcoin
COMMIT=v0.0.9.1-rel
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
URL=/home/debian/bitcoin
COMMIT=github-release-workaround
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
URL=/home/debian/bitcoin
COMMIT=631f4d8f33f040cd1376bb3ef012b77209f11df0
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

It just needs to be decided what should be the reference build, so to speak, so results can be compared.

Over 27 % of clients, according to https://getaddr.bitnodes.io/dashboard/?days=90, are using 0.10 already, so I think pushing in that direction should be aimed for.

Edit: going with a specific commit hash is probably the way to go for maximum reproducibility.

dexX7 commented 9 years ago

Gist updated.

Due to the missing release tag, some parts are still missing and tagged as TODO.

It now also includes instructions to produce file hash sum files and at least for the Windows part I consider it as final, once the missing pieces are filled.

https://gist.github.com/dexX7/7bca4f21141acaa0ec65#16-prepare-package-of-omni-core-for-windows

zathras-crypto commented 9 years ago

Well I didn't end up emailing out the rc1internal binaries because it seems our little merry band of men has a strong favouring for OSX (pretty much every one I planned to give it to runs a Mac). I'm sure we would have got a couple of windows VMs up and running, but I estimated the response to be small (if any) so thought I'd suggest going straight to the tag. As you say we can always do a 0.0.9.2 to fix something if needed.

Since we all seem to be in agreement here I'll update the version and request @m21 puts in the 0.0.9.1 tag (I'm not 100% on the process there), then we can do binaries via gitian and add them to 'releases' on this repo.

dexX7 commented 9 years ago

It would be extremely interesting to know, if Omni Core works on Mac. #203 tackles the topic, and I know at least in theory how it's done via Gitian, but it's nothing I can test.

Two notes:

There is not strictly need of a tag/release and Gitian can be used with commit hashes, which is probably even more specific, so once 0.0.9.1 is considered as final, and no new commit is added, it's basically ready to go, I think and hope.

zathras-crypto commented 9 years ago

what about the readme?

I'm looking into that at the mo. Just piecing together a few changes which I'll PR against main repo and merge, then can ask @m21 to tag. https://github.com/mastercoin-MSC/mastercore/compare/mscore-0.0.9...zathras-crypto:0.0.9.1-Z?expand=1

the build branch is currently named github-release-workaround - even if the goal is to maintain one branch vs. one per release, just to double check: github looks like a typo?

Really didn't put too much thought into this, just followed your suggested "merge the name revert commit into a special gitian-release-workaround branch and use that". If there are more appropriate naming conventions I'm open to better nomenclature sure - suggest away :)

Thanks Z

dexX7 commented 9 years ago

Haha, I don't want to argue about the name. :) Just thinking: if for example the -0.9 and -0.10 branch are not compatible, neither would the workaround branch. How about mscore-0.0.9-workaround or maybe better something like mscore-0.0.9-original-files?

Edit: changelog looks good. :)

zathras-crypto commented 9 years ago

Heh, no arguments from me I really don't have a preference :) I don't want to confuse people though so how about a simple mscore-0.0.9-gitianfix? No-one would use that unless they knew what they were after.

dexX7 commented 9 years ago

I'd prefer something like mscore-0.0.9-but-with-bitcoind-bitcoin-qt-and-bitcoin-cli-file-names in short, because that's what it is. I have no preference either, the one describes what it is, but the other one makes it pretty clear for what it should be used - fine in both cases. Flip a coin. :)

zathras-crypto commented 9 years ago

Alright I'll call for mscore-0.0.9-gitianfix then :) Also poked around the readme https://github.com/mastercoin-MSC/mastercore/commit/13f636faf9e3deec36caf49ce284e18dc80c4ddd but that's no good for an end user :(

dexX7 commented 9 years ago

It's at least an improvement. :)

Also: users who download the binaries (if they are published and made public with some announcement), then it's not necessarily given that those users take a look at the readme here. Or do you plan to include the readme in the "binary package"?

zathras-crypto commented 9 years ago

I would like to include a readme in the binary package, but I think perhaps tailored to the binaries (eg info on how to build is fairly pointless etc)

zathras-crypto commented 9 years ago

OK ready for tag. Will add a custom readme with binaries as noted above.

dexX7 commented 9 years ago

@zathras-crypto: if this is final, can you push it to the mscore-0.0.9-gitianfix branch and cherry-pick 419045f8a022b9dfd482cd3245331fbe34aa6a24? Or I could push the file name commit, if you prefer.

zathras-crypto commented 9 years ago

If we push to the new branch now (before the tag) will the tag come across to the new branch?

dexX7 commented 9 years ago

What exactly do you have in mind?

Say for example there is the branch mscore-0.0.9 with latest commit X, which is tagged with v0.0.9.1-rel, and when browsing the commit history, then the commits in this branch get a mark/tag icon, indicating they are part of v0.0.9.1-rel.

When browsing the commit history of different branch, say mscore-0.0.9-gitianfix, which includes all commits of mscore-0.0.9, as well as another commit Y on top, then all commits that are part of the release get that tag as well, but commit Y won't.

When clicking on the tag icon, either from branch mscore-0.0.9 or mscore-0.0.9-gitianfix, it would redirect to the release page (similar to releases/tag/v0.0.9).

In this context: it should not make if difference, whether the other branch is pushed before tagging or after, because the relation is between commits and tags. And a tag furthermore relates to a points to a specific branch:commit. Hope this makes sense, and I got it right.. :)

zathras-crypto commented 9 years ago

Old branch (github-release-workaround) deleted and new one created from mscore-0.0.9: https://github.com/mastercoin-MSC/mastercore/tree/mscore-0.0.9-gitianfix

zathras-crypto commented 9 years ago

And cherry picked your revert naming commit https://github.com/mastercoin-MSC/mastercore/commit/a1f977ac1d3bfe7ff448783fec53411904bd5e40 - hope I did that right :)

dexX7 commented 9 years ago

It looks like the branch is behind mscore-0.0.9.

If you have a git console somewhere, try the following (assuming upstream is the mastercoin-MSC/mastercore repo and you have commit/write rights):

git fetch upstream mscore-0.0.9
git checkout mscore-0.0.9
git branch -D mscore-0.0.9-gitianfix
git checkout -b mscore-0.0.9-gitianfix
git cherry-pick a1f977ac1d3bfe7ff448783fec53411904bd5e40
git push upstream mscore-0.0.9-gitianfix -f

This updates your local mscore-0.0.9 branch, deletes mscore-0.0.9-gitianfix locally, then creates a new mscore-0.0.9-gitianfix branch, cherry-picks the file commit, and finally forcefully overwrites the remote branch.

Edit: what you did was correct. :) But it looks like your local copy was slightly outdated.

zathras-crypto commented 9 years ago

How's that? https://github.com/mastercoin-MSC/mastercore/commits/mscore-0.0.9-gitianfix

dexX7 commented 9 years ago

Perfect!

So the relevant commit hash is 2c46451da12c7ecb57a6edde5675bf121eb1790b.

If you'd like to give it a try, here is an updated version, but without final result hashes:

https://gist.github.com/dexX7/7bca4f21141acaa0ec65

I suggest we start with Windows and if you have an older Gitian building VM, you'd likely have to start from scratch or at least update/download some dependencies, which changed with 0.9.

Please write down the full response of the actual build results of step 15, so we can compare them. :)

I'm going to start from zero, so it probably takes a while, but I'll update later.

Edit: I'm more or less around, so please contact, if there is any issue or question. :)

dexX7 commented 9 years ago

Smallish adjustment, instead of using a local path as URL, the remote should be used:

URL=https://github.com/mastercoin-MSC/mastercore.git
COMMIT=2c46451da12c7ecb57a6edde5675bf121eb1790b
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
zathras-crypto commented 9 years ago

Alrighty, my Gitian VM is a little old yep so I'll run up a fresh one as per your notes. I'll drop the results here when done :)

dexX7 commented 9 years ago

For some reason following the last comment creates a never ending loop. Not sure why, I'll update in a minute.

Works fine after a restart. Switching from local to remote probably confused the VM ... somehow.

Build ongoing. :)

dexX7 commented 9 years ago

Build finished successfully.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

URL=https://github.com/mastercoin-MSC/mastercore.git
COMMIT=2c46451da12c7ecb57a6edde5675bf121eb1790b
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

Build results:

10c1c236a21b923e74cdda87a5bee6f6d659512b51e8857fb0baad6cb153434b  32/bitcoin-0.9.3-win32-setup.exe
c97ca65a225c1587ec6b8c196600366ea07cb64359a4cca527c353b6f2b29a1d  32/bitcoin-cli.exe
fa4454a7d383cf7161e8a2009418606c96e2f5e1e195b50ddc21998679824e67  32/bitcoin-qt.exe
daa23e593d58416b95029210511e309474f862b82cfb20a4f41d9090c34efe04  32/bitcoind.exe
e76d16c91a0981ad1b01d7bfd7b25725d8e55578445caa10f63b517d58873d5d  32/test_bitcoin-qt.exe
ba1969bdf02ccf6a386875d5942878d34af8450b31b2d82438772481b42a294c  32/test_bitcoin.exe
e663e8d906bb114f33a5eef1768c17017793724444bd7175e19acaef03f007d4  64/bitcoin-0.9.3-win64-setup.exe
9ae3cbf74e3c6cafa3709a2082457362dd9075c5a21d394ee6ae664b322f2c9a  64/bitcoin-cli.exe
61345ee38b529f69799c5e392d4dba9f329deefd0a04f596731b58d72d0404dd  64/bitcoin-qt.exe
46a5ad5ffbf582738043ff3b9ff6cc7d2e9bda936749a5a99064c774bb0e9ef3  64/bitcoind.exe
9c86d51b86c47f643018db5b80698e7b80365f903933f9be5590e21f18ac0b24  64/test_bitcoin-qt.exe
bfdd3b4fce1823018f2edf811854eab1ebe6ebe8c2a810c0f1e59c6dd75cbf59  64/test_bitcoin.exe
87c9db294441549205abaf59d48a9fc176dfcad4a540ac043300960f5bea7a20  src/bitcoin-0.9.3.tar.gz
ebf18cd774aeb7bdd54c9fb28d29323351735de44e82dd5e1b540691de3ce628  bitcoin-res.yml

In particular after renaming the files in build/out/64:

9ae3cbf74e3c6cafa3709a2082457362dd9075c5a21d394ee6ae664b322f2c9a  mastercore-cli.exe
46a5ad5ffbf582738043ff3b9ff6cc7d2e9bda936749a5a99064c774bb0e9ef3  mastercored.exe
61345ee38b529f69799c5e392d4dba9f329deefd0a04f596731b58d72d0404dd  mastercore-qt.exe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJU+APYAAoJEHZ14xz1cZgydD8P/iq89RzQxdx8YJf9qJ0txcmD
iAx29tcQb3MPi2skTlSLkLc//Dhj44oIIiVdyfbYXmCqA8KVBR5WRV4aYUYfU3si
ksvuvzORjZx+/6Z/f3OdxRNyha0EWOBYOt5bjEs3F8RVuXCvkQqHnOj7X4vUvwhe
oh52dMq+0lc1nM+GmbNWHkvVPzCTNWaeNoRViIS3qO1oOghOvoqJDrxB9rqrzHy6
UvofL0qTRL8o7gwUANq6NQ8AVQ2Yfkwc/y/IG+Ys1Erhh22Pzq3cOmmQnUVsGKBJ
iWbUt3VReLBcnOcACiH8vI06jCznkleP7hYgnGqpnX6bxkg3ieGuFsKrGKLBYhIg
HxuuPFVbmGl45PkXJzr9VqQ9WpW8gtr/ecozIaGj7OTMWIG2oI9TGuYgqR8qrjkK
a2U2I+qk3T2if9zh9T4tcX3qlQfXLLUqjDY1V26lg0xYcRJ+/2bEUWQzTpIjKPk9
BmMf7gQ8cP2v7IutEqVWMycVyR2NSbRy7Nbdb+fvizAdRWE//VCX1Mk/Z/QKVqkF
JxqCvRyvyXF3a/j9dLMmxCLkhD3lbKvedVPDw2VlAKFfJ8nWs/zN5D87Db0BPLm8
bZXiJk3UCQFYE9nuJ95UQhpNbhr0b+8gaVQXJ1KuDFzqGM7iV/XMuKJ6vvP3M+sz
0E/V3g4ugHTiTfsZnj7S
=EaQl
-----END PGP SIGNATURE-----

about_omni

Tests passed:

Once the build results are confirmed, publishing binaries can be initiated. :)

zathras-crypto commented 9 years ago

Sorry mate, still working on this - something is up with net infra which is making it a slooooow process :( image image Ugh it's like the dialup days of old, connections to AU servers are still >20Mbps so trying to find local mirrors - hopefully my ISP will get it sorted - regardless should have results in a few hours.

dexX7 commented 9 years ago

Haha, I know that feeling. It really depends on the mirrors and dependencies, some are fast, some others are not. The really slow part for me was the compilation, and altogether it took a few hours. I think we're not really in a hurry, one day more or less doesn't really matter now, imho. :)

zathras-crypto commented 9 years ago

Quick note @dexX7 I've asked @msgilligan to ping you his new extended consensus tests (test all properties) could you please let me know if you see issues with the RPC server when running locally? He's seeing some timeouts testing to a Windows VM I'm hosting that don't occur on Linux when hitting the RPC server for numerous requests quickly (I saw about 500 connections or so). Thanks :)

Getting there on the build, everything downloaded and finally compiling :)

dexX7 commented 9 years ago

Sure, can you walk me through how can I test consensus with all properties? I used gradlew.bat consensusTest a few times without issues, and the regtests run smooth as well, but I'd be very curious to do more tests.

Please define the context of timeouts. What exactly happens?

zathras-crypto commented 9 years ago

Basically I requested that spock consensus test all properties instead of the current select few for more complete coverage, so @msgilligan has adapted the tests to loop all properties. He was running these tests against a Windows VM I have provided with direct access to Omni Core's RPC server and intermittently would get timeouts querying balances from the RPC server. At the same time as he would receive a timeout the RPC server was still responsive locally so unsure as to whether a networking related issue (I see about 500 connections being opened to RPC server).

I asked @msgilligan to provide the updated tests to you which he said he'd do this weekend.

Oh btw, @m21 has tagged 0.0.9.1 and I'm on the last stretch with the compile, so far looking good at least for the deps

60dc2d3b61e9c7d5dbe2f90d5955772ad748a47918ff2d8b74e8db9b1b91c909  boost-win32-1.55.0-gitian-r6.zip
f65fcaf346bc7b73bc8db3a8614f4f6bee2f61fcbe495e9881133a7c2612a167  boost-win64-1.55.0-gitian-r6.zip
ec17898a32b270af6a7c866b507d964d6060e3188879f6e1ec31a609bc8bb74c  boost-res.yml

9c2572b021b3b50dc9441f2e96d672ac1da4cb6c9f88a1711aa0234882f353cf  bitcoin-deps-win32-gitian-r15.zip
94e9f6d861140d9130a15830eba40eba4c8c830440506ac7cc0d1e3217293c25  bitcoin-deps-win64-gitian-r15.zip
7f70d48f3cc2de50ec77711d5b59482b3cad174d704e258add6b8e83e19fd566  bitcoin-deps-res.yml

963e3e5e85879010a91143c90a711a5d1d5aba992e38672cdf7b54e42c56b2f1  qt-win32-5.2.0-gitian-r3.zip
751c579830d173ef3e6f194e83d18b92ebef6df03289db13ab77a52b6bc86ef0  qt-win64-5.2.0-gitian-r3.zip
0fc79c8ab775b42a7d101d6862c9e50701970f3494ca4db66ee569217090296b  qt-res.yml

e2e403e1a08869c7eed4d4293bce13d51ec6a63592918b90ae215a0eceb44cb4  protobuf-win32-2.5.0-gitian-r4.zip
a0999037e8b0ef9ade13efd88fee261ba401f5ca910068b7e0cd3262ba667db0  protobuf-win64-2.5.0-gitian-r4.zip
8066120f974958c88a8590d159205f79c8f92da9d0791418a16265502aef881f  protobuf-win32-res.yml
dexX7 commented 9 years ago

So just to confirm: this is a client issue, but the server plays a passive role?

I see about 500 connections being opened to RPC server

This is very odd. The (current) consensus tests are pretty simple and use only getblockcount (once) and for each property getallbalancesforid_MP, while the processing and comparison is done client-side.

dexX7 commented 9 years ago

Once the binary results are confirmed, I suggest to update the tag to a proper release (similar to releases/tag/v0.0.9) with some information and files attached.

Speaking of: the last release was published with Ubuntu binaries and right now we're working on Windows binaries. What's the plan for this one? Releasing both?

zathras-crypto commented 9 years ago

So just to confirm: this is a client issue, but the server plays a passive role?

The timeout was seen on the client side yep, I had mastercore-qt running (via RDP) with the debug window up and was running my own getallbalancesforid_MP calls successfully at the same time as the timeouts.

This is very odd.

It'll be calling getallbalancesforid_MP once for every property but even then it shouldn't be more than a few hundred.

Once the binary results are confirmed, I suggest to update the tag to a proper release

Yep I'll create a release like I did with 0.0.9 :)

Speaking of: the last release was published with Ubuntu binaries

I'd like the archive to contain both Linux and Windows binaries with a short readme along with license info etc. Can we do Linux binaries using gitian in the same fashion?

dexX7 commented 9 years ago

I'd like the archive to contain both Linux and Windows binaries with a short readme along with license info etc.

This makes no sense in my opinon. One for each OS. :)

When creating the archive, take a look at: https://gist.github.com/dexX7/7bca4f21141acaa0ec65#16-prepare-zipped-package-of-omni-core

It's probably an overkill to create deterministic archives, but please include the file with file hashes, which can be created with:

sha256sum mastercore-cli.exe mastercored.exe mastercore-qt.exe > sha256sum.txt

Make sure you copy/move the binaries before starting a new build, otherwise the results will be overwritten.

I extended the guide to cover Linux building as well:

https://gist.github.com/dexX7/7bca4f21141acaa0ec65#18-build-dependencies-for-linux https://gist.github.com/dexX7/7bca4f21141acaa0ec65#19-build-omni-core-for-linux

I'll start building later, but within the next hours.

zathras-crypto commented 9 years ago

Awesome thanks, i'll take a stab at linux via gitian tomorrow, thanks for the info :)

On the windows side:

10c1c236a21b923e74cdda87a5bee6f6d659512b51e8857fb0baad6cb153434b  32/bitcoin-0.9.3-win32-setup.exe
c97ca65a225c1587ec6b8c196600366ea07cb64359a4cca527c353b6f2b29a1d  32/bitcoin-cli.exe
fa4454a7d383cf7161e8a2009418606c96e2f5e1e195b50ddc21998679824e67  32/bitcoin-qt.exe
daa23e593d58416b95029210511e309474f862b82cfb20a4f41d9090c34efe04  32/bitcoind.exe
e76d16c91a0981ad1b01d7bfd7b25725d8e55578445caa10f63b517d58873d5d  32/test_bitcoin-qt.exe
ba1969bdf02ccf6a386875d5942878d34af8450b31b2d82438772481b42a294c  32/test_bitcoin.exe
e663e8d906bb114f33a5eef1768c17017793724444bd7175e19acaef03f007d4  64/bitcoin-0.9.3-win64-setup.exe
9ae3cbf74e3c6cafa3709a2082457362dd9075c5a21d394ee6ae664b322f2c9a  64/bitcoin-cli.exe
61345ee38b529f69799c5e392d4dba9f329deefd0a04f596731b58d72d0404dd  64/bitcoin-qt.exe
46a5ad5ffbf582738043ff3b9ff6cc7d2e9bda936749a5a99064c774bb0e9ef3  64/bitcoind.exe
9c86d51b86c47f643018db5b80698e7b80365f903933f9be5590e21f18ac0b24  64/test_bitcoin-qt.exe
bfdd3b4fce1823018f2edf811854eab1ebe6ebe8c2a810c0f1e59c6dd75cbf59  64/test_bitcoin.exe
87c9db294441549205abaf59d48a9fc176dfcad4a540ac043300960f5bea7a20  src/bitcoin-0.9.3.tar.gz
ebf18cd774aeb7bdd54c9fb28d29323351735de44e82dd5e1b540691de3ce628  bitcoin-res.yml
dexX7 commented 9 years ago

Wooho, this is a match! :)

Edit: In case there is someone out there who doesn't want to wait until the official release:

http://bitwatch.co/uploads/omnicore-v0.0.9.1-rel-win/omnicore-v0.0.9.1-rel-win.zip http://bitwatch.co/uploads/omnicore-v0.0.9.1-rel-win/omnicore-v0.0.9.1-rel-win.zip.asc

dexX7 commented 9 years ago

Well, no Gitian Linux binaries for now. There appears to be an incompability between Boost and QT:

https://bugreports.qt.io/browse/QTBUG-22829

It can be solved, but this would come with removing all dependencies/includes of "toxic" Boost headers, and given all the cross-includes, this is not trivial, and it almost seems easier to move on to the next version and just provide source + Windows binaries for this one.