< miketwenty1>
sipa: shouldn't it be referencing the specific "bitcoin-0.21.0rc2-win-unsigned.tar.gz"
< sipa>
don't think so
< sipa>
no, it requires an input file named bitcoin-win-unsigned.tgz
< miketwenty1>
gitian-builder/inputs/bitcoin-win-unsigned.tar.gz isn't created going through the unsigned build steps for me.. apparently
< miketwenty1>
but does create one with the version in the name of the file
< miketwenty1>
sipa: do you manually mv the file to that name?
< sipa>
presumably
< miketwenty1>
looking at docs more. seems to be implied mv step for people using the gitian-build.py, that i see for people building with the gbuild directly
< miketwenty1>
gitian-build.py will move to inputs using the version name of the file.. which i think would make more sense to use.. but idk.. the reasons for not wanting to do it this way
< sipa>
i think gitian just doesn't support variable expansion in its input file list
< hebasto>
miketwenty1: and the convenient `gitian-build.py` script is still useful :D
< miketwenty1>
jonatack: i saw you tweet from a couple days ago and followed you .. good stuff I have indeed looked at your repo.. you as well have gbuild / mv commands in your guide. iirc. behasto: Seems the only manual step for python-build.py is being able to verify signed builds? or is there a way to run it through python-build.py without using gbuild directly?
< hebasto>
I've been using `gitian-build.py` for years without manual running `gbuild`
< hebasto>
it is not ideal for testing pulls (see dedicated prs in the repo), but it works flawlessly for the tagged releases.
< miketwenty1>
hebasto: then maybe im not understanding something or something is failing silently on my side after the build is done.. in your inputs dir does it create the version file and the non version file? -> gitian-builder/inputs/bitcoin-win-unsigned.tar.gz
< hebasto>
miketwenty1: if you have an issue with the `gitian-build.py` script, don't hesitate to open an issue, and provide your system info and steps to reproduce the issue. It would help much.
< bitcoin-git>
[bitcoin] jnewbery opened pull request #20524: [test] Move MIN_VERSION_SUPPORTED to p2p.py (master...2020-11-subversion-string) https://github.com/bitcoin/bitcoin/pull/20524
< andytoshi>
kallewoof: i'm looking again at implementing bip-322 and i see a bunch of pain points. do you think we could get on a phone call or something and go over things?
< andytoshi>
i think i'd like to meaningfully change the BIP but maybe you're tired of doing that
< jonatack>
i'm scratching my head on why many CAmount "in" parameters to functions are being passed as reference to const rather than by value... CAmount is int64_t, a cheaply-copied type
< sipa>
generally things up to two pointers worth in size is consodered cheaply copyable
< jonatack>
sipa: yes. thank you
< jonatack>
" two or three words (doubles, pointers, references) are usually best passed by value. When copying is cheap, nothing beats the simplicity and safety of copying, and for small objects (up to two or three words) it is also faster than passing by reference because it does not require an extra indirection to access from the function."
< achow101>
it might be that people just forget that CAmount is really an int64
< sipa>
yeah
< jonatack>
maybe they thought oh, it's not a built-in type, so...
< sipa>
well one of the motivations for adding it in the first place was a freicoin contributor who needed the ability to replace it with a not-so-simple type
< hebasto>
someday CAmount could be a not typedef to int64
< sipa>
(most of that didn't make it in, only the typedef did)