< bitcoin-git>
bitcoin/master 4e353cb João Barbosa: http: Release work queue after event base finish
< bitcoin-git>
bitcoin/master 6a67366 W. J. van der Laan: Merge bitcoin/bitcoin#19033: http: Release work queue after event base fin...
< bitcoin-git>
[bitcoin] laanwj merged pull request #19033: http: Release work queue after event base finish (master...2020-05-fix-race-interrupt-http-server) https://github.com/bitcoin/bitcoin/pull/19033
< laanwj>
_aj_: it seems kind of involved (19 files changes, including consensus code), and i'm not sure it's a good idea to add further features to the 22.0 milestone
< laanwj>
i mean we're already slipping the feature freeze with the currentl ylabeled PRs
< laanwj>
hebasto: haven't read *anything* about stopping ARM 32 bit support
< laanwj>
hebasto: that would be extremely sudden
< hebasto>
laanwj: ok
< laanwj>
if the libc symbol issue is not solvable we could bump thje minimum libc for that platform
< laanwj>
that will affect a lot less people than dropping the platform completely
< hebasto>
^^ sgtm, will look into possible implementation
< laanwj>
thanks!
< hebasto>
laanwj: what do you think about getrandom and getentropy symbols?
< laanwj>
i don't know
< laanwj>
they both come from dependencies at least (libevent and qt respectively) which apparently need their own internal random generation and seeding
< hebasto>
cannot see the way to make boost ignore new random.h without patching
< laanwj>
what happens if you build those libraries against older libc which doesn't have those symbols?
< laanwj>
i mean i'm sure it has some kind of build-time detection for them?
< hebasto>
package (at least boost) auto detects glibc version
< laanwj>
or does libevent and qt refuse to build against older glibc
< laanwj>
clear, that's what imean
< laanwj>
what if the glibc doesn't have those symbols
< hebasto>
no issues with glibc 2.27 on bionic
< laanwj>
(which is the case for the version we are trying to support)
< hebasto>
^^ until #22244 was merged
< laanwj>
sure, but we need it to run against glibc 2.17, which we somehow determined to be the minimum glibc at some point the distributed binaries sshould run agianst
< laanwj>
all #22244 did was fix the check
< hebasto>
right :)
< laanwj>
it was not actually running on those platforms, the check was wrong because it ignored some symbols
< hebasto>
if our release will be made via guix there is an idea to point it to glib 2.25
< hebasto>
err 2.24
< laanwj>
yes, if that is possible it would solve a large part of the problem
< hebasto>
dongcarl: ^
< laanwj>
i would really prefer compiling and linking against the minimum glibc version that we support at run time, working around every symbol individually is very error prone
< * MarcoFalke>
wen musl?
< laanwj>
providing our own implementation of getrandom and getentropy seems unwise
< laanwj>
MarcoFalke: yes please
< laanwj>
no way we're going to be able to switch to that before 22.0 though
< hebasto>
maybe 23.0?
< laanwj>
sgtm
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #20509: net: CAddress deser: use stream's version, not what's coming from disk (master...caddress_deser_version) https://github.com/bitcoin/bitcoin/pull/20509
< bitcoin-git>
[bitcoin] laanwj opened pull request #22294: build: Perform boost::process detection with BOOST_CPPFLAGS (master...2021-06-boost-process-detection) https://github.com/bitcoin/bitcoin/pull/22294
< bitcoin-git>
bitcoin/master fa09fd1 MarcoFalke: doc: Final merge of release notes snippets
< bitcoin-git>
bitcoin/master 398dd67 MarcoFalke: Merge bitcoin/bitcoin#22296: doc: Final merge of release notes snippets, m...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22296: doc: Final merge of release notes snippets, mv to wiki (master...2106-doRel) https://github.com/bitcoin/bitcoin/pull/22296
< angela>
Hello! :) I have been reading a lot about bitcoin recently and have been thoroughly moved! I want to start understanding and contributing to bitcoin-core. Can someone recommend good newbie contributor resources? Thanks
< angela>
Thanks sipa! Just what I was looking for!
< jamesob>
anyone have tips for running `lint-all.sh` locally? do we have a container image to mount into or something? because when I run it naively, I get about a bazillion errors many of which don't occur on CI
< dongcarl>
Sorry, just caught up on the discussion here... orionwl[m] laanwj hebasto see #bitcoin-core-builds for some of my thoughts
< jonatack>
jamesob: i use a bash alias to run "test/lint/lint-circular-dependencies.sh ; ./test/lint/lint-python.sh"
< jonatack>
since those seem to be the ones i ever ran up against
< jonatack>
(agree; lint-all was always unusable for me)