< fanquake>
If the changes in 4546ac5af1c4105a0cf78a407fefcb189822bcf5 in 21614 are covered in a commit in 21701, we can drop that change from 21614
< aj>
21377 should have cherry-picked cleanly on top of 21614; i guess some/all of them were included in the "fuzz: test versionbits delayed activation" commit though?
< fanquake>
Yes it looks like some of those changes are included in b529222ad18f7facbaff394455875b4aa65d653e
< wumpus>
agree it is not good if the last two PRs conflict, that introduces a rebase bottleneck
< fanquake>
I think if we get 21701 in. We can always open a PR to make the required followups. Otherwise, marco will be active soon, and should be able to rebase/modify 21614
< fanquake>
aj is #21691 meant to be backported as well?
< aj>
fanquake: (it's only relevant if we introduce more soft forks that reuse version bits)
< aj>
one of them's included in the NEVER_ACTIVE commit, which looks like it means the vbits fuzzer won't work for earlier commits
< wumpus>
oh yea i think aiming for activating one soft fork is enough for this release, or do you mean releasing without it will make reusing the bits impossible in the future?
< aj>
no, it's just a test to make sure we're not currently reusing bits
< wumpus>
right, thanks
< wumpus>
at least backporting tests is very low risk
< aj>
safely reusing bits in the future just means we need to make sure the first activation is actually finished (FAILED/ACTIVE) and preferably buried (SoftForkHeight = 987654) rather than signaled
< aj>
(or we could switch to signaling by something other than nVersion and avoid worrying about bit reuse entirely)
< aj>
(we've got another 9 bits before we need to reuse any and another 3 additional bits reusing bits for buried activations before we have to worry about this. would be impressive if we added that many soft forks to 0.21...)
< aj>
err, 10+3 not 9+3
< aj>
oh no, i'm counting taproot, 9+3 was right
< wumpus>
that *would* be impressive yes
< wumpus>
definitely doesn't sound like we're going to run out of bits any time soon
< fanquake>
unfortunately I'm heading out, so will have to gitian build in the morning
< provoostenator>
first!
< emzy>
third!
< jonatack>
sixth with a 4-core laptop 😛
< wumpus>
i suppose we are not going to do codesigning this time? (or only for macos?)
< achow101>
only macos
< wumpus>
ok!
< midnight>
have to get my gitian box back functional again.. :-/
< achow101>
I'm going to be moving forward with setting up a LLC for the code signing stuff, as a backup plan at least. does anyone else (other than me and jonasschnelli) need/want to be part of it?
< sipa>
that can always be changed later, i suppose?
< achow101>
it's harder to change later
< bitcoin-git>
[bitcoin] dergoegge opened pull request #21706: log: Mitigate disk filling attacks by globally rate limiting LogPrintf(…) (master...g_log_ratelimiting) https://github.com/bitcoin/bitcoin/pull/21706
< bitcoin-git>
[bitcoin] mzumsande opened pull request #21707: test: Extend functional tests for addr relay (master...202104_test_getaddr) https://github.com/bitcoin/bitcoin/pull/21707
< bitcoin-git>
[bitcoin] jonatack opened pull request #21709: doc: update doc/reduce-memory.md peer connections info (master...update-reduce-memory-doc) https://github.com/bitcoin/bitcoin/pull/21709
< bitcoin-git>
[bitcoin] jonatack opened pull request #21710: doc: update help docs for -addnode config option and addnode rpc (master...update-addnode-docs) https://github.com/bitcoin/bitcoin/pull/21710
< jonasschnelli>
achow101: Agree that this is a good backup plan.
< jonasschnelli>
It looks like the swiss association takes not too much time to setup. The documenta have now be written and will be submitted (probably early next week) to the register
< achow101>
ok, that should be faster than creating the LLC
< jonasschnelli>
we will see... you never know how long it requires to pass the swiss register
< jonasschnelli>
and there is the word "Bitcoin" in the association name...
< jonasschnelli>
which I'm sure will lead to longer processing times and some dbl-checks.
< sipa>
jonasschnelli: good to hear
< jonasschnelli>
achow101: I pulled master from your signapple and signed 0.21.1rc1 and did a gitian test build.. where I get:
< jonasschnelli>
fatal error: signed.temp/codesign_allocate: size for '-a x86_64 227000' not a multiple of 16
< jonasschnelli>
codesign however reported "Code signature is valid"
< achow101>
jonasschnelli: for 0.21, you need to use the with-codesign-allocate tag and use macport's codesign_allocate
< achow101>
otherwise I think our apply script won't work
< jonasschnelli>
ah.. right... let me try again
< achow101>
this was changed in master to use the apply command I added to signapple, but that wasn't backported to 0.21
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21711: guix: Add full installation and usage documentation (master...2021-03-guix-docs) https://github.com/bitcoin/bitcoin/pull/21711
< jonasschnelli>
okay.. worked. Pushing the signature now
< achow101>
Signature appears to be valid, but opening the .app results in "Bitcoin Core.app was blocked from use because it is not from an identified developer"
< achow101>
Oh, it's because of the notarization crap
< jonasschnelli>
achow101: Yes. Right.
< bitcoin-git>
[bitcoin] promag opened pull request #21712: qa: Test default include_mempool value of gettxout (master...2021-04-gettxout) https://github.com/bitcoin/bitcoin/pull/21712
< bitcoin-git>
[bitcoin] rebroad opened pull request #21713: Refactor ProcessNewBlock to reduce code duplication (master...RefactorProcessNewBlock) https://github.com/bitcoin/bitcoin/pull/21713