< jamesob> fuzzing under valgrind has timed out a number of times on cirrus for #19806. is this happening on other PRs? https://github.com/bitcoin/bitcoin/pull/19806/checks?check_run_id=1424737784
< gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
< miketwenty1> I'm wondering if anyone had issue going through the gitian process in terms of the signed builds
< miketwenty1> was looking at this:
< miketwenty1> It's unclear to me how it's referencing the proper tag/version, as the VERSION in the command seems to be unused.
< miketwenty1> I may be looking at this incorrectly but
< miketwenty1> echo $VERSION
< miketwenty1> 0.21.0rc2
< miketwenty1> `bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml`
< miketwenty1> getting: `sha256sum: bitcoin-win-unsigned.tar.gz: No such file or directory`
< miketwenty1> However I do have: `./gitian-builder/inputs/bitcoin-0.21.0rc2-win-unsigned.tar.gz`
< miketwenty1> unsigned process seems to work just fine
< sipa> why do you say it's unused? you're using it...
< miketwenty1> the gbuild script is failing ::::::::::
< miketwenty1> Checking if target is up.
< miketwenty1> Preparing build environment
< miketwenty1> lstat /gitian/gitian-builder/inputs/bitcoin-win-unsigned.tar.gz: no such file or directory
< miketwenty1> Updating apt-get repository (log in var/install.log)
< miketwenty1> Installing additional packages (log in var/install.log)
< miketwenty1> Upgrading system, may take a while (log in var/install.log)
< miketwenty1> Creating package manifest
< miketwenty1> Creating build script (var/build-script)
< miketwenty1> Running build script (log in var/build.log)
< miketwenty1> Traceback (most recent call last):
< miketwenty1> 6: from ./bin/gbuild:332:in `<main>'
< miketwenty1> 5: from ./bin/gbuild:332:in `each'
< miketwenty1> 4: from ./bin/gbuild:334:in `block in <main>'
< miketwenty1> 3: from ./bin/gbuild:334:in `each'
< miketwenty1> 2: from ./bin/gbuild:339:in `block (2 levels) in <main>'
< miketwenty1> 1: from ./bin/gbuild:185:in `build_one_configuration'
< miketwenty1> ./bin/gbuild:23:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
< sipa> please don't copy-paste more than 3 lines on IRC
< sipa> looks like you're missing bitcoin-win-unsigned.tar.gz
< 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
< sipa> so it has to be a fixed name
< bitcoin-git> [gui] jarolrod opened pull request #139: doc: Improve gui/src/qt README.md (master...improve-qt-readme) https://github.com/bitcoin-core/gui/pull/139
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e2ff5e7b35d7...1ae5758981de
< bitcoin-git> bitcoin/master 89bdad5 Luke Dashjr: RPC/Wallet: unloadwallet: Allow specifying wallet_name param matching RPC ...
< bitcoin-git> bitcoin/master 1ae5758 MarcoFalke: Merge #20448: RPC/Wallet: unloadwallet: Allow specifying wallet_name param...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20448: RPC/Wallet: unloadwallet: Allow specifying wallet_name param matching RPC endpoint wallet (master...unloadwallet_namematch) https://github.com/bitcoin/bitcoin/pull/20448
< bitcoin-git> [gui] MarcoFalke merged pull request #138: unlock encrypted wallet "OK" button bugfix (master...qt-unlock-wallet-ok-enabled-bugfix) https://github.com/bitcoin-core/gui/pull/138
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1ae5758981de...854b36cfa2ef
< bitcoin-git> bitcoin/master 8008ef7 Michael Dietz: qt: unlock wallet "OK" button bugfix
< bitcoin-git> bitcoin/master 854b36c MarcoFalke: Merge bitcoin-core/gui#138: unlock encrypted wallet "OK" button bugfix
< jonatack> miketwenty1: maybe this guide can be helpful. a number of people have been using it to do it for the first time and i use it: https://github.com/jonatack/bitcoin-development/blob/master/gitian-building.md
< 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] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/854b36cfa2ef...7ae86b3c6845
< bitcoin-git> bitcoin/master 3ebde21 Amiti Uttarwar: [test] Fix wait condition in disconnect_p2ps
< bitcoin-git> bitcoin/master 7ae86b3 MarcoFalke: Merge #20522: [test] Fix sync issue in disconnect_p2ps
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20522: [test] Fix sync issue in disconnect_p2ps (master...2020-11-disconnect-p2ps) https://github.com/bitcoin/bitcoin/pull/20522
< bitcoin-git> [bitcoin] theStack opened pull request #20523: zmq: deduplicate 'sequence' publisher message creation/sending (master...20201128-zmq-refactor-dedup_sequence_msg_sending) https://github.com/bitcoin/bitcoin/pull/20523
< 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
< jonatack> maybe 64-bits isn't considered cheap
< sipa> 64 bits is definitely cheap
< 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)
< jonatack> ah interesting