< bitcoin-git>
bitcoin/master 5e7d199 Jarol Rodriguez: doc: note on SDK for macOS depends cross-compile
< bitcoin-git>
bitcoin/master 16d0051 fanquake: Merge bitcoin/bitcoin#21688: doc: note on SDK for macOS depends cross-comp...
< bitcoin-git>
[bitcoin] fanquake merged pull request #21688: doc: note on SDK for macOS depends cross-compile (master...depends-note-sdk) https://github.com/bitcoin/bitcoin/pull/21688
< michaelfolkson>
I guess this is a question for fanquake. What's the latest thinking/progress on supporting Bitcoin Core builds on ARM MacOS? He didn't sound enthusiastic or confident about the prospect in July last year
< wumpus>
building it on a M1 already been done, the bottleneck (if any) is the cross-build , although getting the right hardware into the hands of devs would still make sense for testing ofc.
< sipa>
doesn't provoostenator_ have an M1?
< sipa>
and jonasschnelli maybe?
< wumpus>
would be nice to get fanquake one i guess
< bitcoin-git>
[bitcoin] rebroad opened pull request #21805: Send fewer feefilter messages (and avoid the wobbling issue) (master...SteadierFeefilter) https://github.com/bitcoin/bitcoin/pull/21805
< bitcoin-git>
[bitcoin] rebroad opened pull request #21806: Display send/recv in Bps instead of totals in the debug window (master...SendRecvSpeed) https://github.com/bitcoin/bitcoin/pull/21806
< bitcoin-git>
[bitcoin] rebroad closed pull request #21806: Display send/recv in Bps instead of totals in the debug window (master...SendRecvSpeed) https://github.com/bitcoin/bitcoin/pull/21806
< bitcoin-git>
[gui] rebroad opened pull request #305: Display send/recv in Bps instead of totals in the debug window (master...SendRecvSpeed-gui) https://github.com/bitcoin-core/gui/pull/305
< jonasschnelli>
sipa: I have a M1 mini
< jonasschnelli>
I tried to go through the cross compile process but due to lack of know how in this area I didn’t succeed
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21810: fuzz: Various RPC fuzzer follow-ups (master...rpc-fuzzer-followups) https://github.com/bitcoin/bitcoin/pull/21810
< michaelfolkson>
jonasschnelli: Sorry if basic question but what is the cross compile process? Say building a binary on your M1 mini which is intending to be a run on a different machine/OS?
< jonasschnelli>
I tried to add the apple-arm-darwin tripplet to our dependency build system. Which would result in cross compiling Apple M1 (arm64) on a Linux machine.
< jonasschnelli>
But the compiler didn’t new the tripplet
< jonasschnelli>
*knew
< sipa>
michaelfolkson: simply put, you use a crosscompiler :)
< sipa>
(which means pretty much you need to have a separate compiler installed, together with some parts of the environment it will be compiling for)
< jonasschnelli>
You also need to right Apple SDK
< sipa>
and the complexity is that of course you also need all of bitcoin core's dependencies built for the target platform
< sipa>
which all have their own build systems
< sipa>
the depends system helps a lot here
< jonasschnelli>
Apple m1 support is IMO not very time critical because x86 “emulation” on the M1 is crazy fast...
< hebasto>
^ good to know
< wumpus>
at least theoretically it shouldn't be a big deal though, we have other builds for ARM
< jonasschnelli>
But off couse if you have an M1 processor,.. you want an M1 native binary
< sipa>
the hard part is the apple thing, not the arm thing :)
< jonasschnelli>
sipa: exactly
< wumpus>
yes i definitely have no idea about that
< ariard>
michaelfolkson: well you can pursue process separation further in the future by splitting server code in its own process
< ariard>
like all the indexes, i've an old trying to do that
< wumpus>
dongcarl: ok, the [experimental] tag makes me less sure it should be in high prio now :)
< dongcarl>
wumpus: Yeah we could probably come back to it next week when ryanofsky's had a chance to rebase and update :-)
< wumpus>
dongcarl: good point
< wumpus>
jonatack: looks close too then!
< michaelfolkson>
wumpus dongcarl: Indeed
< michaelfolkson>
ariard: Nothing is ever entirely finished ;)
< wumpus>
#topic 0.21.1 final
< core-meetingbot>
topic: 0.21.1 final
< wumpus>
0.21.1rc1 has been out for a while, at least i haven't heard of anyone noticing problems with it, so it might be time to label it as -final soon
< achow101>
I think we should do final soon
< achow101>
signaling begins in a few days
< meshcollider>
Agreed
< wumpus>
right
< jonasschnelli>
the win signing certs are still missing though
< wumpus>
let's tag it after the meeting then
< jonasschnelli>
(association registration in in progress though)
< wumpus>
jonasschnelli: we're not going to be able to wait for that, we can do the windows signingafter it arrives i guess
< jonasschnelli>
yes. agree
< Murch>
achow101: in 289 blokcs :)
< wumpus>
there is no reason other platforms need to wait for the windows sig after all :)
< achow101>
that also leads to the question of how we are going to re-release with the new cert
< sipa>
0.21.1.1 ?
< wumpus>
does that need to be a new release at all?
< wumpus>
just sign it, upload the binary, or am i missing something
< sipa>
hmm, right
< achow101>
the gitian job requires the tag
< sipa>
no repo changes at all?
< achow101>
there will be a repo change for the new cert, although I can probably work around that
< wumpus>
oh in that case 0.21.1.1 makes sense
< achow101>
I don't think the gitian job actually needs the cert in repo, but the making the signature does
< wumpus>
i didn't know it needed a repo change
< wumpus>
no need to do anything to work around it
< luke-jr>
why would it need a repo change? O.o
< jonasschnelli>
manual sign and manual verification and gitian-builder sugnatures?
< achow101>
luke-jr: the cert is in the repo at contrib/windeploy/win-codesign.cert
< jonasschnelli>
Would though depend on if one could verify the code signed binary easly
< luke-jr>
achow101: but is that used?
< achow101>
luke-jr: yes
< luke-jr>
:/
< achow101>
but only by the code signer, so it can be worked around if we really want to
< achow101>
the other issue is the detached-sigs repo which would then need the version tag to be force pushed to a commit that has the win sigs
< achow101>
that probably won't play well with gitian
< achow101>
easiest solution would be do to a x.x.x.1 release for all affected versions
< wumpus>
let's just do that
< wumpus>
we have more often used minor-minor releases for architecture specific changes
< jonasschnelli>
lets first try to get a code signing certificate. :/
< bitcoin-git>
bitcoin/master 62932cc Luke Dashjr: GUI/Intro: Return actual prune setting from showIfNeeded
< bitcoin-git>
bitcoin/master f2e5a6b Luke Dashjr: GUI/Intro: Abstract GUI-to-option into Intro::getPrune
< bitcoin-git>
bitcoin/master e2dcd95 Luke Dashjr: GUI/Intro: Rework UI flow to let the user set prune size in GBs
< sipsorcery>
hebasto: the vs2017 command line build for master fails (before applying the PR) due to an ABI issue.
< sipsorcery>
I suspect it's related to the Qt binaries which are pre-built with vs2019.
< sipsorcery>
imho I don't think it's worth attempting to support vs2017.
< hebasto>
sipsorcery: may I ask you to submit a well-motivated pr for that?
< sipsorcery>
sure, so the need is to remove the vs2017 reference from the build_msvc\README.md? I'll check if there are any other refs to vs2017 but i don't think so.
< hebasto>
many thanks
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #21811: Remove Visual Studio 2017 reference from readme (master...remove_vs2017) https://github.com/bitcoin/bitcoin/pull/21811