< bitcoin-git>
[bitcoin] achow101 closed pull request #14558: rpc: Require solvability in importmulti if importing more than the scriptPubKey (master...importmulti-solvability) https://github.com/bitcoin/bitcoin/pull/14558
< phwalkr>
Hey. I'm trying to build a testnet transaction according to an example, and I am getting Error validating transaction: Rejected script for input 0 referencing . Can someone help me?
< provoostenator>
Gitian for v0.17.0.1 Windows is presenting me with "cp: cannot stat 'inputs/bitcoin-0.17.0.1-win-unsigned.tar.gz': No such file or directory"
< provoostenator>
Same Bionic machine that I signed v0.17.0(rc*) with.
< hebasto>
provoostenator: I've modified two lines in the script on this purpose.
< hebasto>
provoostenator: in lines 95 and 103 replace args.version with "0.17.0.1"
< hebasto>
err
< provoostenator>
hebasto: thanks, can you make a PR for that? I'll ACK it if those changes work.
< hebasto>
with 0.17.0
< hebasto>
provoostenator: sure
< provoostenator>
Though I think it's the unsigned version that's not named right.
< hebasto>
yes
< provoostenator>
So your version would be incompatible with wuppus' commit: 0.17.0.1-win-signed/laanwj/bitcoin-win-signer-build.assert
< provoostenator>
Oh no nvm
< provoostenator>
Oh no nvm, it's the file name: "bitcoin-0.17.0-win64-setup.exe"
< hebasto>
^
< achow101>
provoostenator: there was a change to gitian-build.py that may not exist in 0.17.0.1
< achow101>
provoostenator: the change was that the unsigned version that goes into gitian-builder/inputs would be versioned, instead of generically named
< achow101>
that's probably what is causing your problem.
< provoostenator>
achow101 I'm using gitian-build.py from the latest master
< provoostenator>
It's versioned, but it ignored the 4th decimal: bitcoin-0.17.0-win-unsigned.tar.gz
< achow101>
oh, i see.
< provoostenator>
I would say that's the bug; no reason to leave out the 4th digit for an internal file name.
< provoostenator>
(though I'm happy to ignore the bug for this release and just stick to 0.17.0-win, otherwise everyone would have to rebuild.
< achow101>
that seems like a bug in gitian itself though, not with the build script. the resulting unsigned.tar.gz file is versioned incorrectly
< achow101>
unless the version number wasn't bumped again
< achow101>
so gitian is making binaries with the version number 0.17.0? or is it making them wiht 0.17.0.1 except for the win unsigned tar?
< provoostenator>
macOS has the same naming issue
< provoostenator>
Linux binaries have 3 digits: bitcoin-0.17.0-arm-linux-gnueabihf.tar.gz
< achow101>
provoostenator: I see the problem now, investigating a fix
< achow101>
(something to do with 'make dist')
< provoostenator>
achow101: great, I'm too jetlagged to make sense of this, but happy to test your fix :-)
< provoostenator>
Also at some point we should rename osx to macos in the file name
< wumpus>
provoostenator: could be, my base image is pretty old at this point
< wumpus>
is this a regression for 0.17.0.1? it looked to me that there were plenty of succesful builders
< hebasto>
wumpus: yes, it's a regression for 0.17.0.1
< achow101>
wumpus: hebasto: it isn't really a regression
< achow101>
it has been broken for a while I think. we see the same thing happend with 0.15.0.1
< achow101>
all that has changed is that the build script does versioning, which is what is causing problems. the versioning is slightly broken in make or configure
< Arvidt>
When doing tar -xzf bitcoin-0.17.0.1-x86_64-linux-gnu.tar.gz it extracts to the folder bitcoin-0.17.0/ . I would suggest that it extracts to the folder bitcoin-0.17.0.1/ because I have a symlink "current" to the newest version, and now, my old binary tree of 0.17.0 got simply overwritten with the 0.17.0.1 version, while I was still running 0.17.0 with that binary tree :-( But it looks
< Arvidt>
like 0.17.0 could cleanly shutdown anyway...
< achow101>
Arvidt: I believe that is part of the problem that I am investigating with gitian producing binaries without the 4th build number
< Arvidt>
achow101: Great :-)
< Arvidt>
Maybe for quality assurance a check could be added to a release process script that checks if the tar ball extracts to the exact version?
< Arvidt>
I am not sure if also the RC versions should extract to the RC version named folders, e.g. 0.17.0rc1
< Arvidt>
With the RC versions I had the same problem with the symlink as stated above
< esotericnonsense>
Arvidt: non-specific to bitcoin, the binary changing out from underneath it shouldn't matter
< esotericnonsense>
the running process will continue to hold a file descriptor to the "deleted" other version
< sipa>
esotericnonsense: for some upgrades (though not 4th digit changes...) you may end up with difference in version between bitcoind and bitcoin-cli
< bitcoin-git>
[bitcoin] JBaczuk opened pull request #14610: Docs: correction to test readme compile instructions (master...fix_test_readme_compile_instructions) https://github.com/bitcoin/bitcoin/pull/14610
< esotericnonsense>
i suppose that's true
< provoostenator>
achow101: if I use your commit, would my gitian build be incompatible with others? If so I'll push my sigs first using some manual workaround
< provoostenator>
hebasto: I think your workaround is causing my gitian to checksum the v0.17.0 binary instead of the new one.
< provoostenator>
Maybe I applied it on the wrong lines though.
< provoostenator>
Oh wait, that was macOS.
< provoostenator>
Windows works for me.
< bitcoin-git>
[bitcoin] achow101 opened pull request #14612: Include full version number in released file names (master...fix-make-build-version) https://github.com/bitcoin/bitcoin/pull/14612
< achow101>
provoostenator: Arvidt: ^ that should resolve these version number/filename problems for the future
< phantomcircuit>
so uh
< phantomcircuit>
how can i get something in build-aux/m4 to actually be used?
< phantomcircuit>
seems the windows functional tests are still kind of buggy
< sipa>
MarcoFalke: how is appveyor set up? there is a webhook from the bitcoin/bitcoin repo to appveyor, but how does appveyor get to report a CI status back?