< bitcoin-git>
bitcoin/master ae9b489 fanquake: contrib: add symbol check test for PE
< bitcoin-git>
bitcoin/master 0547106 fanquake: Merge #20608: contrib: add symbol check test for PE binaries
< bitcoin-git>
[bitcoin] fanquake merged pull request #20608: contrib: add symbol check test for PE binaries (master...symbol_check_test_pe) https://github.com/bitcoin/bitcoin/pull/20608
< bitcoin-git>
bitcoin/master 904d875 Andrew Poelstra: configure: output notice that test binary is disabled by fuzzing
< bitcoin-git>
bitcoin/master c8fdbb4 MarcoFalke: Merge #20609: configure: output notice that test binary is disabled by fuz...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20609: configure: output notice that test binary is disabled by fuzzing (master...2020-12--fuzz-config-output) https://github.com/bitcoin/bitcoin/pull/20609
< jonasschnelli>
curios to know: why do we have nPruneAfterHeight (a minimum height for pruning)?
< az0re>
Alternatively, how should I get a CTxOut from a COutPoint (e.g., from CTxIn::prevout)?
< sipa>
az0re: look it up in the UTXO set
< az0re>
ELI5 please :)
< az0re>
To be more specific, how best to do it from within validation.cpp?
< az0re>
(I am new to the Bitcoin codebase and would appreciate some tips on the most relevant data structures)
< aj>
az0re: there's a "gettxout" rpc call, you could look at how it's implemented in rpc/blockchain.cpp; or similar for "getrawtransaction" if you want to lookup the blockchain rather than the utxo set
< az0re>
OK roger that I'll check them out
< az0re>
Thanks
< az0re>
Actually I think Consensus::CheckTxInputs() did the trick for me. Looks like I need a CCoinsViewCache, then get a Coin from it with CCoinsViewCache::AccessCoin(), and can get the CTxOut from Coin::out
< sipa>
az0re: yeah, pretty much
< sipa>
where to get that cache depends on the context
< sipa>
if you need to include mempool UTXOs as well it's a bitndifferent
< az0re>
Hmmm...
< sipa>
the gettxout RPC supports both with and without mempool
< sipa>
so you can use that as an example
< az0re>
I see, thanks
< jonasschnelli>
MarcoFalke: functional tests: when calling assert_start_raises_init_error, the node checks for a few seconds for an RPC connection (bitcoind started, waiting for RPC to come up). Would it be possible to detect a shutdown and init error rather then polling RPC?
< jonasschnelli>
(would save some seconds)
< wumpus>
it's definitely possible to detect with subprocess that the child processes exited
< wumpus>
or wait for it to exit, even with a timeout
< jonasschnelli>
hmm... our testframework calls "if self.process.poll() is not None:"... I guess that should detect the halted process
< jonasschnelli>
(but it doesn't)
< jonasschnelli>
or it does but the timeout is too large
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20611: Move TX_MAX_STANDARD_VERSION to policy (master...2012-mvTxStandardVersion) https://github.com/bitcoin/bitcoin/pull/20611
< jonasschnelli>
it's a race
< wumpus>
dunno--fwiw there's .poll() which polls if the process is still running and .wait(timeout) that waits
< wumpus>
the preferable thing, if no RPC interaction is neccesary, would be to wait, no need for periodic polling
< bitcoin-git>
bitcoin/master 0f949cd Pieter Wuille: Add regression test for incorrect decoding
< bitcoin-git>
bitcoin/master eb53c03 Wladimir J. van der Laan: Merge #20595: Improve heuristic hex transaction decoding
< wumpus>
when any kind of RPC interaction is necessary there's no other option than to poll until it becomes available, there's no way to asynchronously be notified that 'RPC is up'
< wumpus>
although honestly I have no idea how to fit that best into the POSIX process model
< wumpus>
hm I guess bitcoind could print some token to stdout / stderr that is detected by the connected parent process and taken as signal that RPC is running
< wumpus>
alternatively it'd be possible to pass, say, in an additional file descriptor for signaling but that probably gets too fiddly
< promag>
fanquake: ping?
< MarcoFalke>
jonasschnelli: removing the rpc polling from assert_start_raises_init_error is a good idea
< MarcoFalke>
we have intermittent issues due to that
< fanquake>
promag: hi
< MarcoFalke>
removing rpc from the equation should make everything more stable, but I am not sure how easy it is to implement
< MarcoFalke>
if `assert_start_raises_init_error` fails, you'll have to use the rpc to use "stop"
< jonasschnelli>
MarcoFalke: Agree. Though I'm not touching it for now. Happy if someone wants to take a closer look.
< MarcoFalke>
or are the nodes shut down with SIGKILL? I don't remember
< wumpus>
MarcoFalke: I think we don't use the signals in the RPC tests because windows; I guess though it could start polling RPC only after the process didn't shut down as expected after a certain timeout
< bitcoin-git>
bitcoin/master 34c80d9 Wladimir J. van der Laan: test: Add option to git-subtree-check to do full check, add help
< bitcoin-git>
bitcoin/master e20b488 Wladimir J. van der Laan: Merge #20567: test: Add option to git-subtree-check to do full check, add ...
< bitcoin-git>
[bitcoin] laanwj merged pull request #20567: test: Add option to git-subtree-check to do full check, add help (master...2020_12_subtree_check) https://github.com/bitcoin/bitcoin/pull/20567
< promag>
hebasto: thanks, will try it
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20613: test: Use Popen.wait instead of RPC in assert_start_raises_init_error (master...2012-testFastFailInitError) https://github.com/bitcoin/bitcoin/pull/20613
< bitcoin-git>
bitcoin/master 206f74e João Barbosa: Support make src/bitcoin-node and src/bitcoin-gui
< bitcoin-git>
bitcoin/master 8e1f9d6 Wladimir J. van der Laan: Merge #20549: Support make src/bitcoin-node and src/bitcoin-gui
< bitcoin-git>
[bitcoin] laanwj merged pull request #20549: Support make src/bitcoin-node and src/bitcoin-gui (master...2020-12-make-bitcoin-node) https://github.com/bitcoin/bitcoin/pull/20549
< sdaftuar>
MarcoFalke: can you tell me your thoughts on how close #19858 is to be merged? 3 PRs that conflict with it have been merged since it was acked 4 times, so i'm trying to rebase and get re-review before this happens again
< sdaftuar>
but if it will be a while i can hold off on pestering people
< MarcoFalke>
sdaftuar: I explictly held back on merging the conflicting prs. I simply didn't get the notification last night from GitHub that you rebased it
< sdaftuar>
ah, thanks for the effort
< sdaftuar>
so i should go ahead then with my rebase and re-pester plan
< MarcoFalke>
Yes, I think the re-ACKs shouldn't be too difficult
< MarcoFalke>
Not sure why no one has re-ACKed it in the last 9 days
< sdaftuar>
gleb reacked last night
< sdaftuar>
or this morning i guess
< sdaftuar>
MarcoFalke: if you do think it close, would you mind commenting on the PR that you think it would be ready for merge once it gets some re-acks? so that other reviewers know their time will be well spent getting it across the finihs line
< hebasto>
promag: `make -C depends qt HOST=x86_64-apple-darwin18` ends with `Caching qt...` that means ok. Have you a problem with it?
< promag>
did it build qt quick controls?
< hebasto>
checking...
< queip>
the "score" field in getnetworkinfo, what does it actually mean? we are confused about it trying to provide support to user in #bitcoin . Could RPC help xxx command include short explanation for the outputed JSON fields for most commands?
< promag>
hebasto: do you have qml/QtQuick/Controls.2 dir in the build dir?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20615: cirrus: Schedule one task with paid credits for faster CI feedback (master...2012-ciFasterFeedback) https://github.com/bitcoin/bitcoin/pull/20615
< vasild>
I did not cancel it, maybe it got confused somehow by my push of a previous commit?
< hebasto>
promag: for which platform are you trying to build depends?
< sdaftuar>
i will try again
< promag>
hebasto: for my host, macos
< hebasto>
which macos version?
< sdaftuar>
vasild: ok i'm out of my depth on trying to get the appveyor or cirrus-ci builds to re-run
< vasild>
sdaftuar: if nothing else works, I can always make some minor whitespace change and re-push, but lets wait for all to complete first and see if somebody will have a better idea
< sdaftuar>
yeah, sounds good
< promag>
hebasto: Some of the required modules (qtHaveModule(quick)) are not available. \n Skipped.
< hebasto>
promag: thanks! I see this message on Big Sur.
< promag>
not on linux?
< hebasto>
on linux too ((
< promag>
ok good, at least we are on the same page :D
< promag>
fanquake: cfields: do you see problems using qt single archive instead of separate modules?
< promag>
download a bigger archive VS more complicated build script
< ariard>
sdaftuar: jonatack and I just re-ack #19858 but please ping again if there is a new rebase to deal with it, this PR has been in limbo for too long :)
< jonatack>
I don't recall being able to restart appveyor, it always seemed more like a "game over, re-push to replay" thing. The cirrus builds can be restarted...ISTM they restart on their own after a while (unsure)
< bitcoin-git>
[bitcoin] hebasto closed pull request #19882: depends: Export variables from make to environment explicitly (master...200905-build) https://github.com/bitcoin/bitcoin/pull/19882
< sipa>
are they (final rc3) backports, or final (rc3) backports?
< MarcoFalke>
hopefully both
< luke-jr>
XD
< wumpus>
i deleted the en_GB translation on transifex; it contained all kinds of junk, e.g. a pasted shell transcript, some French messages, and so on. Besides that it seems kind of pointless in the first place.
< wumpus>
sipa: final for rc3 at least, i plan to tag rc3 soon after
< jonasschnelli>
sipa: I run LXC directly on a physical debian host
< jonasschnelli>
(I guess you can do the same with ubuntu?)
< wumpus>
if you already run debian you could skip the outer VM, but, I generally don't want to pollute the physical host with all kind of stuff
< jonasschnelli>
Yes. Agree that this makes sense.
< sipa>
i assume you can do the gpg signing outside the VM?
< wumpus>
(though LXC isn't that bad)
< wumpus>
yes
< jonasschnelli>
sipa: yes. I also GPG sign "outside"
< jonasschnelli>
(on a different computer)
< wumpus>
I have my own script to fetch the assert files from the VM and sign them with (w gpg2 --detach-sign), don't know if there's a standard way to do it nowadays
< sipa>
how much disk space would you need for the VM?
< jonasschnelli>
15G Aug 11 08:51 base-bionic-amd64
< jonasschnelli>
+ some small stuff
< sipa>
cool
< wumpus>
it needs to write the output somewhere too but yes
< jonasschnelli>
You'll also need the macOS SDK (grab it from bitcoincore.org, check the travis files for the URL)
< wumpus>
it's preferable to extract the SDK using the instructions from an actual Apple download, especially if you have a mac yourself, but yeah most people simply grab it
< sipa>
i don't have any apple hardware
< sipa>
but you can do the extraction from linux, right?
< luke-jr>
sipa: you may want more than 15 GB for caches
< luke-jr>
unless you wipe them
< sipa>
ok, gave it 50 G
< luke-jr>
I have 16 GB of caches alone XD
< wumpus>
definitely if you keep the caches for old branches around
< luke-jr>
hebasto: it's not technically legal for us to distribute that btw
< wumpus>
FWIW I usually delete the caches for every major/minor release, building the depends takes somewhat longer but it's rare enough, and there are some other steps that take a long time too
< wumpus>
and it wouldn't be the first time that solves a determinism issue
< bitcoin-git>
bitcoin/0.20 98c9d79 Wladimir J. van der Laan: gui: Pre-rc1 translations update
< bitcoin-git>
bitcoin/0.20 a4bc4c1 Wladimir J. van der Laan: doc: Update manual pages pre-rc1
< wumpus>
luke-jr: renaming files is kind of annoying, as the file names are hardcoded in all kinds of places and scripts, also not sure it's worth it for something that doesn't generate any ambiguity
< sipa>
jonasschnelli: i created an apple id, but it says i'm not allowed to download the xcode files
< jonasschnelli>
sipa: have you used the link from the docs?
< sipa>
i need to sign up for the developer program
< sipa>
which is $99 a year
< sipa>
??
< achow101>
sipa: it shouldn't be required, but I don't remember which links to go to
< jonasschnelli>
No. You don't need that
< jonasschnelli>
You only need the 99$ programm if you want to deploy apps
< jonasschnelli>
sipa: just click harder,... you'll find it
< sipa>
Sorry, you cannot view this page.
< sipa>
he Apple ID you signed in with does not have permission to view this page.
< sipa>
If you’re currently a member of the Apple Developer Program, you or your Account Holder may need to update your account by agreeing to the latest license agreement in order to access this page. To view your current membership status and benefits, visit your account.
< jonasschnelli>
sipa: let me try to create a new account..
< jonasschnelli>
Have you verified your email and all that stuff?
< theStack>
luke-jr: not really, it shares the kernel with the host
< sipa>
ok, i have the unsigned binaries, they match
< sipa>
i'm running gitian-build.py --sign now, but it seems it's building the linux binaries again?
< sipa>
oh, i'm silly
< sipa>
-b == --build
< luke-jr>
theStack: so do many VMs
< luke-jr>
sipa: lol
< theStack>
luke-jr: there are tons of articles explaining the differences between containers and vms... feel free to redefine terms for yourself though