< luke-jr>
wumpus: I would hope the source tarball issues get fixed for any release..
< wumpus>
yes if we stll even have unmerged things that should go into rc2 I guess I was way too optimisic
< wumpus>
it's okay with me as long as we don't keep moving the goalposts
< MarcoFalke>
luke-jr: Not sure how to proceed with that, now that a conflicting pull got merged
< MarcoFalke>
I haven't checked how much they conflict
< luke-jr>
it moved the util script back into the individual gitian ymls
< luke-jr>
I could rebase by moving the tarball logic into the ymls, or by moving it back out into a util script
< luke-jr>
I see pros and cons for either, so I don't really care which approach we use
< luke-jr>
pros: less duplication in each yml; cons: can't change it outside the commit/tag and still build the same commit/tag (harder to diff yml changes)
< luke-jr>
(otoh, having a separate util script isn't too different from the former `make dist` logic being separate - so I guess it's not strictly *worse* than what we had before)
< wumpus>
why did the script get absorbed into the ymls?
< wumpus>
I thought factoring out the logic was kind of clever
< luke-jr>
dunno
< luke-jr>
looks like the goal in #18741 was to fix the Guix ASAP and fix any fallout in the rebase of #18818
< bitcoin-git>
[bitcoin] jtimon closed pull request #17037: Testschains: Many regtests with different genesis and default datadir (master...b20-n-chains) https://github.com/bitcoin/bitcoin/pull/17037
< bitcoin-git>
[bitcoin] jtimon closed pull request #17032: Tests: Chainparams: Make regtest almost fully customizable (master...b20-customizable-regtest) https://github.com/bitcoin/bitcoin/pull/17032
< luke-jr>
ok, rebased, reintroducing the tarball-generation script
< luke-jr>
even if Guix isn't important for 0.20, would be nice to be sure I didn't break it
< luke-jr>
actually, hold off a minute
< luke-jr>
looks like something doesn't like it being an executable script for some reason, just going to make it `source`d like before
< wumpus>
it takes a long time for it to actually run, so yea please make sure it's correct first
< luke-jr>
wumpus: ok, it seems to build now
< stevenroose>
Are -connect= nodes automatically also -whitelist'ed?
< sipa>
no
< instagibbs>
"(the rules for this peer are the same as for -addnode)."
< stevenroose>
instagibbs: yeah but addnode also doesn't mention it
< stevenroose>
Another the -whitelist mentions "Whitelist peers connecting from the given IP address". So would it even work for outgoing connections?
< stevenroose>
I'm specifically thinking about outgoing `-connect` connections that send you bad data. Can they be prevented from being banned with `-whitelist`?
< dongcarl>
luke-jr: thanks for the rebase btw, I'll test guix
< ariard>
hey going to withdraw my NACK on bip157 impl but I would be glad to have this on a subject for meeting tmrw
< ariard>
like I'm curious about people opinion on long-term scaling of light clients
< michaelfolkson>
What were the reasons for your initial NACK and why have you changed your mind?
< ariard>
michaelfolkson: see what I posted on ml, but thinking more, it's maybe interesting to signal filter *headers but not servicing headers themselves
< michaelfolkson>
Ok thanks
< ariard>
therefore you're ready to dedicate resources to help people to verify correctness of filters but not servicing filtters in themselves
< ariard>
like you separate control/data plane of BIP 157
< gribble>
https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] brakmic opened pull request #18901: fuzz: initialize variable sep_pos to get rid of warning (master...warning-in-fuzz-tests) https://github.com/bitcoin/bitcoin/pull/18901
< luke-jr>
ugh, I think this road leads back to restoring the build.h hack
< luke-jr>
but I suppose without a real fix for that, it's unavoidable