< wumpus>
what is this about a new boost dependency? "A new Boost dependency in the form of "boost/thread/mutex.hpp" appears to have been introduced:" i'm 100% sure i don't use a line of boost in #21007
< fanquake>
seems to be test only code, so it's about to be deleted
< wumpus>
fanquake: "silent merge conflict" was my first idea as well, thanks for checking it
< wumpus>
one step closer to getting rid of boost thread, and also one step further away from it again, it's a lot of running to stay in the same place :-)
< wumpus>
but yes IIRC after #18710 it should be just a matter of cleaning up, happy that the new introduced usage is in the test only
< viraltaco_>
I'm trying to socialize. Don't mind unless it works
< sipa>
i'd say it's working
< viraltaco_>
How are public addresses generated? 😕 I'd like to end up with something nice but I can't brute force my way to that because I don't have infinite time, or resources :( (hate when that happens)
< bitcoin-git>
[gui] jonasschnelli merged pull request #189: qt: drop workaround for QTBUG-42503 which was fixed in Qt 5.5.0 (master...qtbug-42503) https://github.com/bitcoin-core/gui/pull/189
< bitcoin-git>
bitcoin/master 2a39ccf sinetek: Add include for std::bind.
< bitcoin-git>
bitcoin/master e130ff3 MarcoFalke: Merge bitcoin-core/gui#183: Add include for std::bind.
< wumpus>
viraltaco_: again, #bitcoin please
< theStack>
could anyone with write access to the repository convert #21008 to draft please? (the "fix" seems to fail on two cirrus instances immediately :/)
< wumpus>
theStack: is it not possible to convert your own PRs to draft?
< fjahr>
It is, just did it last night
< wumpus>
phew, i just assumed everyone had that option, but wasn't sure :)
< fjahr>
It is a link below the participants on the right iirc
< fjahr>
“Convert to draft”
< wumpus>
ya, it's a bit stealth, i always have to do a browser search to find it, also *converting from draft* is in a wholly different place (a button at the bottom)
< aj>
yeah, it's text not a button for some reason?
< setpill>
Question about the gitian stuff again - what's the point of apt-cacher-ng? Is there a reason to not just straight up use ubuntu package servers?
< wumpus>
setpill: if you do a lot of VM work (e.g. spin up new VMs, upgrade them, throw them away again) like gitian does then having your own apt cache makes sense
< wumpus>
it's an optimization but not necessary
< wumpus>
e.g. mind that gitian *never* upgrades the base image, does an apt-get dist-upgrade as first thing which (even with caching) is one of the longest-taking parts of the build
< wumpus>
it wouldn't necessarily have to be like that but it is :)
< setpill>
Trying to set up a CI/CD-friendly docker-only pipeline
< setpill>
Since it uses docker, any needed caching can be done through that
< wumpus>
it's one more thing that won't be needed anymore after moving to guix builds (which also handles caching dependencies itself)
< setpill>
Also fwiw gitian-builder/bin/make-base-vm does do `docker build --pull` so in that part of the process the base image is "upgraded" (or at least the latest version is fetched from upstream)
< setpill>
Hmm rightr
< wumpus>
okay, it does not do so for LXC and KVM builds, i always use LXC
< wumpus>
(and i use a lot of VMs even outside of gitian, so running my own apt cacher makes sense)
< setpill>
Yeah, that makes sense.
< setpill>
I'll just add a flag to disable it, since installing apt-cacher-ng in the host image is kind of a pita
< setpill>
Since building docker images from within docker needs alpine-based images
< setpill>
Out of curiosity - is the guix approach going to be docker-friendly?
< setpill>
Would be nice to have, to make it easier to set up automated builds. Docker-based workflows and infrastructure are pretty widespread.
< prusnak>
MarcoFalke:
< prusnak>
MarcoFalke: will you upload your public GPG key to github, so the history shows Verified instead of Unverified?
< MarcoFalke>
prusnak: no I won't, we should be trusing GitHub less, rather than more
< MarcoFalke>
setpill: Yes, guix can run in docker
< prusnak>
fair enough
< wumpus>
MarcoFalke: good point, centralizing both the git hosting and signature verification in one place somewhat defeats the reason to sign commits in the first place
< wumpus>
e.g. if github is compromised they could add arbitrary commits and also show them as verified
< wumpus>
at least if you verify locally it protects against that
< hebasto>
it's pretty easy to verify commit sigs locally
< wumpus>
btw does github have some kind of shortcut to quickly jump to a PR/issue by number? i keep ending up having to edit the browser URL, it feels like this should be easier
< aj>
wumpus: i setup https://github.com/bitcoin/bitcoin/pull/%s as a bookmark in firefox with the keyword "btc" so i can type "btc 12345" in the url bar to get to PR 12345
< aj>
wumpus: seems to redirect fine if i put an issue number in too
< wumpus>
aj: seems like a good idea
< wumpus>
i'm always disappointed that typing, say '#<issue>' in the search bar doesn't simply take you to that issue
< wumpus>
noooo it searches for that number in the source code, that's soo useful for a jump-to feature
< wumpus>
but handling it at the browser level makes sense thanks
< gribble>
https://github.com/bitcoin/bitcoin/issues/26 | Confirmations not appearing for sent coins after recovering wallet from archive · Issue #26 · bitcoin/bitcoin · GitHub
< jnewbery>
Feel free to add more topics
< jonatack>
jnewbery: i moved my topics to the feb 9 meeting
< jonatack>
not being too dependent on it but trying to do more GitHub interaction from the command line, it's getting slowly better, not a full replacement yet
< aj>
<aj> jnewbery: what do you think of a "p2p agenda/priorities" page on the devwiki, that's just "current status" rather than an "rss feed/log" like the p2p meeting page is? be a nice place to capture/update todo lists, and could serve as an agenda each week (for both overall priorities and a hashtag-proposedp2pmeetingtopic thing) ?
< jnewbery>
< jnewbery> aj: ACK. If you create the first version of the page I can link to it from the p2p meeting page, and I'll add my own priorities
< aj>
jnewbery: hmm, i don't remember seeing that
< jnewbery>
I think it's a good idea
< aj>
jnewbery: ah, i'd gone to sleep by then perhaps
< jonatack>
also: gh pr view <number> -c (e.g. --comments) allows loading all the PR comments without the "84 hidden items" messages and clicking through over and over
< wumpus>
jonatack: oh nice, does that also work authenticated?
< wumpus>
yes the hidden items are another frequent source of confusion
< jnewbery>
jonatack: that is nice! The hidden items are github's worst feature
< jonatack>
yess. but it takes getting used to the output.
< jonatack>
wumpus: authenticated?
< wumpus>
jonatack: yes, for posting things, and accessing private repositories
< gribble>
https://github.com/bitcoin/bitcoin/issues/26 | Confirmations not appearing for sent coins after recovering wallet from archive · Issue #26 · bitcoin/bitcoin · GitHub
< emzy>
hi
< jnewbery>
Does anyone have any updates that they'd like to share with the group?
< sipa>
i suggest a gr-grab-by-combat to decide it
< vasild>
I just added it to my to-review list
< aj>
sipa: compile by combat?
< emzy>
wumpus: tnx. I found it. I will include that in my personal icinga monitoring.
< wumpus>
jonatack: seems like a nice tool, the only thing i dislike is that it's written in go, i'd managed to avoid having to install a go toolchain on my bitcoin dev VM until now :-)
< wumpus>
emzy: yeah if you need some other output format like json feel free to add that
< wumpus>
(as a command line option)
< vasild>
I am just trying to figure why a newly added fuzz test to ser/unser addrman crashes. After that I will review 20044 if somebody has rebased it, or I can rebase it if nobody has done so by then.
< MarcoFalke>
vasild: Which pull?
< vasild>
MarcoFalke: you mean the fuzz test? I wrote a test for #20557
< vasild>
MarcoFalke: hmm, generating 50k addresses to fill addrman would require a few 100s of kilobytes of fuzzing input, is that reasonable? I think not.
< MarcoFalke>
We have more then 5 GB of inputs
< MarcoFalke>
+1MB shouldn't matter
< vasild>
hmm
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #20044: Make all of net_processing (and some of net) use std::chrono types (master...202009_chrono_types) https://github.com/bitcoin/bitcoin/pull/20044
< vasild>
the fuzz test adds just a few entries to addrman as far as I have observed, even though there should be 1..100 sources with each one providing 1..1000 addresses. I will play with it further tomorrow...
< * vasild>
afk
< jnewbery>
vasild: thanks for writing the test!
< bitcoin-git>
[bitcoin] stackman27 opened pull request #21014: test: Run mempool_accept.py even with wallet disabled (master...diswallet_mempoolaccept) https://github.com/bitcoin/bitcoin/pull/21014
< norisgOG>
Hello, when running regtest on docker: I only have to expose 18443?
< wumpus>
depends on what you want to do, for RPC, yes, for P2P you'd have to open 18444 as well
< norisgOG>
wumpus so p2p means when I will run more then one node?
< norisgOG>
so they connect
< sipa>
norisgOG: you open the P2P port if you want other nodes (run by other people) to connect to you
< sipa>
otherwise you can only connect out
< norisgOG>
sipa ok so when I am planning to build 2 docker regtest nodes I have to expose 18444 for that matter?
< wumpus>
in the particular case of regtest, the other nodes are likely also run by yourself, but yes :)
< sipa>
norisgOG: yes, at least on one of them
< norisgOG>
so when starting a regtest network, when starting all nodes lets say 2 of them how do they that they belong to one regtest network, and not every single bitcoind instance starts its own regtest env?
< wumpus>
regtest nodes won't automatically connect to any other, by default they're on their own, to make a network they can be manually connected using the 'addnode' RPC
< wumpus>
(or -connect on the command line, i guess)
< norisgOG>
ok so as soon as I connect another node lets say typing the command (bitcoind -regtest -server -addnode=10.7.0.11:12345) and then when I start bitcoind form 10.7.0.11 it will connect to the regtest of the former?
< norisgOG>
I will try :)
< sipa>
yes just play around
< norisgOG>
I followed the build process in doc/unix-build but its missing the configure: error: libdb_cxx headers missing, Bitcoin Core requires this library for wallet functionality
< norisgOG>
but there is no libdb specified in the unix requirements ?
< norisgOG>
it just states something like Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, is there a reason why they are not listed in the above sudo apt install command ?
< norisgOG>
because of the libdb 4.8 problem
< sipa>
norisgOG: this is getting off topic; there are several answers about this on https://bitcoin.stackexchange.com, and people are probably willing to help on #bitcoin
< norisgOG>
ok thx
< bitcoin-git>
[bitcoin] dhruv opened pull request #21015: Make all of net_processing (and some of net) use std::chrono types (master...pr-20044) https://github.com/bitcoin/bitcoin/pull/21015