< fanquake> phantomcircuit: I'm not sure how much smaller we can make it. The diff also looks a lot bigger because we are removing boost macros.
< luke-jr> dongcarl: I don't see how that would solve it. I think there already is such a package (using third-party binaries of course) though
< dongcarl> luke-jr: A Guix package built from source, that is.
< luke-jr> dongcarl: I would be amazed to see it, and happy to do the work to port it to gitian myself ;)
< dongcarl> luke-jr: Others have done the same (build Guix from source) on debian, Fedora, and Arch Linux. I'm not too familiar with Gentoo packaging, but I'll take a look to see if it's easy enough to do.
< luke-jr> dongcarl: it's essentially a bash script
< sipa> dongcarl: i'm trying myself in a clean ubuntu VM
< luke-jr> looking at the Arch one, I'm pretty sure that will use 3P bins
< sipa> so far i've gotten to building gnutls from source to get guile support for it, but i get a compilation error
< luke-jr> don't see anything in Fedora's to avoid 3P bins either
< sipa> what is 3P?
< dongcarl> sipa: you may want to take a look at the debian testing package, will link!
< luke-jr> third-party
< luke-jr> ie, not compiled myself
< dongcarl> luke-jr which one?
< luke-jr> dongcarl: any
< dongcarl> luke-jr do you mean the source tarball?
< luke-jr> no, I mean the bootstrap binaries
< dongcarl> luke-jr: where do you see that in the PKGBUILD?
< luke-jr> dongcarl: it's a question of what I *don't* see - it's Guix's default behaviour
< luke-jr> FWIW I'm starting over from https://guix.gnu.org/manual/en/html_node/Requirements.html right now
< luke-jr> on x86_64 this time just to minimise issues
< dongcarl> luke-jr: the bootstrap binaries are used when building binaries *inside* Guix, not when building Guix itself. To avoid them and build from the minimal binary seed, you can just supply —bootstrap to any guix build command
< luke-jr> dongcarl: using them at all is a problem
< luke-jr> (unless Guix is run inside a VM, such as gitian would)
< sipa> so what is the problem with using -bootstrap?
< luke-jr> I don't recall, my last attempt was many months ago
< luke-jr> annoyingly, all the spectre mitigations mean I'm still installing deps this time ;.;
< luke-jr> dongcarl: are guile-lzlib and guile-zlib likely included with guile itself? don't see a pkg for those
< dongcarl> luke-jr I don’t think so unfortunately... Arch Linux packages them separately
< * sipa> slams keyboard
< luke-jr> hmm
< sipa> In procedure dynamic-link: file: "/home/pw/src/gnutls-3.6.15/guile/src/guile-gnutls-v-2", message: "file not found"
< sipa> when building gnutls
< * luke-jr> wonders how he got zlib/lzlib last time
< sipa> hmm, it seems the guile-gnutls package works, but installs for guile 2.2
< sipa> and guile-git also works, but install for guile 3.0
< luke-jr> O.o
< * dongcarl> looking at packages now
< luke-jr> looks like a `nix-guix` package overlay has -zlib/lzlib ebuilds that are trivially auditable
< dongcarl> sipa: guile-gnutls package in Ubuntu?
< sipa> dongcarl: yes, it works, but it's for guile 2.2
< sipa> so i'll try installing guile-git (which guix also needs) manually for guile 2.2 as well
< sipa> because the guile-git ubuntu package is for guile 3.0
< bitcoin-git> [bitcoin] ajtowns opened pull request #21148: Split orphan handling from net_processing into txorphanage (master...202102-txorphanage) https://github.com/bitcoin/bitcoin/pull/21148
< * luke-jr> glares at Guix docs for making him hunt for a git uri
< dongcarl> sipa: Ah I see, it seems like an ubuntu apt repo with the right dependencies + guix would be helpful then...
< sipa> dongcarl: if i'd trust it :)
< sipa> dongcarl: do you understand https://github.com/TaylanUB/scheme-bytestructures ?
< sipa> it's a dependency for guile-git
< * luke-jr> still hasn't found it
< sipa> it looks like it has autoconf/automake all over it, but no instructions on how to do anything automaky
< dongcarl> luke-jr: what are you trying to find?
< luke-jr> aha, gotta go to About, then to Savannah
< luke-jr> dongcarl: the source code via git
< dongcarl> luke-jr: Right it's on savannah
< dongcarl> sipa: I think for those packages you'll have most luck looking at salsa, as they're all packaged properly there
< sipa> dongcarl: i have no idea where you want me to look
< luke-jr> dongcarl: what version should I work with?
< dongcarl> luke-jr: version-1.2.0 works
< dongcarl> sipa: I'm talking about here: https://salsa.debian.org/debian/scheme-bytestructures/-/tree/debian/master, the debian/rules is how the .deb package for the debian guile-bytestructures package is produced
< dongcarl> sipa: Oh you're talking about regenerating ./configure?
< sipa> dongcarl: i have no idea
< sipa> i want to know how to build/install it
< sipa> i types autoconf, and it produced a configure file
< sipa> but that gives an error when running
< sipa> *typed
< sipa> but i believe there is no compilation whatsoever really, it just needs to end up in the right directory
< sipa> the instructions say add it to GUILE_LOAD_PATH, which i did, but guile-git still can't find it :)
< luke-jr> configure doesn't exist
< dongcarl> In the release tarball ./configure exists
< luke-jr> ☺
< luke-jr> dongcarl: ./configure --prefix=/home/dev/guix/root --with-store-dir=/home/dev/guix/root/gnu/store
< luke-jr> ok?
< dongcarl> luke-jr: sec
< dongcarl> luke-jr: you might need to set `--localstatedir`, it defaults to `/var`, and if you want non-root, maybe some other things...
< luke-jr> --localstatedir=DIR modifiable single-machine data [PREFIX/var]
< sipa> dongcarl: i don't have configure, and the one autoconf create doesn't work
< dongcarl> luke-jr: oh cool did not know
< luke-jr> I think that's a standard autoconf thing
< sipa> dongcarl: oh! i need autoreconf --install
< luke-jr> sipa: ./bootstrap ?
< dongcarl> sipa: Ah yes. Also, I think the git repo is different from the release tarball. The one here: https://github.com/TaylanUB/scheme-bytestructures/releases/download/v1.0.7/bytestructures-1.0.7.tar.gz, does have ./configure
< sipa> still, now make doesn't work
< dongcarl> sipa: I does the release tarball work? I will look into the autoreconf now.
< sipa> dongcarl: oh, grr
< sipa> i was just trying a broken master branch i guess
< dongcarl> Also, since the debian folks did a lot of hard work to make Guix work well, it may be easier for APT-based distro users to just get their apt-sources from debian and build the .deb to install
< dongcarl> They made all the dependencies of Guix work well too, including gnutls, bytestructures, etc.
< luke-jr> says 3%, guess it will be a bit
< luke-jr> dongcarl: that part was easy tho :P
< luke-jr> 50%
< sipa> dongcarl: ok progress, guile-gnutls, guile-git, guile-json, guile-sqlite3, guile-gcrypt, guile-zlib work
< sipa> next: guile-lzlib
< dongcarl> sipa: Oh wow!
< dongcarl> sipa: I honestly didn't expect them to work without the special debian rules...
< dongcarl> Good news so far I guess :-)
< sipa> i'm doing --prefix=/usr everywhere; i wouldn't do that on a real OS, but this is a VM to play with...
< sipa> ok, building!
< * dongcarl> cautiously excited
< sipa> 11%...
< sipa> y dis slo
< luke-jr> u forgot -j80
< dongcarl> Haha
< luke-jr> actually I intentionally didn't just in case it has parallel issues
< sipa> i did -j8 (and my VM should have access to 8 threads)
< luke-jr> can try -j8 when I rebuild it all again later
< dongcarl> btw, guix has a handy `./pre-inst-env` script to use `guix` without installing it
< dongcarl> luke-jr: I usually do -j48, and haven't had problems yet
< luke-jr> I wonder if I was using master last time
< luke-jr> I mgiht have been
< luke-jr> I remember finding a bug
< luke-jr> are all these .go files not actually go?
< sipa> i suspect they are "guile object"s
< dongcarl> It's guile bytecode I think
< luke-jr> XD
< sipa> 75%!
< dongcarl> woop woop
< * dongcarl> half-expects a failure @ 99%
< sipa> 95%...
< dongcarl> luke-jr: How's it going?
< luke-jr> 65%
< luke-jr> sipa is faster
< dongcarl> luke-jr: Oh did you -j1?
< luke-jr> yes
< luke-jr> also it's running on my old x86_64 box ☺
< sipa> threadripper 2950X here...
< luke-jr> trying to minimise risks so that when something *does* go wrong it's less unclear what
< sipa> 100%... still going...
< luke-jr> lol
< luke-jr> 101% soon? ☺
< dongcarl> luke-jr: True, honestly good practice...
< sipa> ok, done
< dongcarl> sipa: woo!
< luke-jr> I suppose the downside is, now I'm getting de-sync'd from sipa
< * luke-jr> stops a system update in case that helps it pick up some pace
< sipa> make check fails... due to missing help2man, lol
< luke-jr> XD
< * luke-jr> SIGSTOPs chromium cuz Google can't be responsible with CPU time
< * dongcarl> looking thru issues.guix.gnu.org to see if there are bugs on master
< luke-jr> well, I'm on 1.2.0 this time
< luke-jr> sipa: you still doing master?
< sipa> 1.2.0
< sipa> lots of tests fail...
< sipa> tests/cpan.scm, tests/channels.scm, tests/crate.csm, ...
< sipa> is that normal?
< dongcarl> sipa: When I ran `make check` in the past, a lot of them failed as well, but normal operation hasn't had many problems. If you send me the output I can go investigate though!
< luke-jr> so skip `make check`?
< dongcarl> luke-jr: Yep, but if you provide me a log I can go investigate too (you can do that later)
< luke-jr> it needs to compile all its packages? O.o
< dongcarl> sipa: what is the full path for your guix src dir, if you don't mind?
< dongcarl> luke-jr: What did you just run?
< luke-jr> dongcarl: `make`
< luke-jr> still
< luke-jr> [ 71%] GUILEC gnu/packages/emacs-xyz.go
< dongcarl> luke-jr: Found a way for you to replace the bootstrap bins after Guix is made: https://salsa.debian.org/debian/guix/-/blob/debian/devel/debian/rules#L30
< * luke-jr> pokes Debian for requiring cookies
< sipa> dongcarl: ok, i have guix daemon running
< sipa> what now?
< dongcarl> sec
< sipa> a link to documenting is fine... but i'm sort of at the end of the guix.gnu.org documentation
< fanquake> could it be as simple as ./contrib/guix/guix-build.sh
< dongcarl> sipa: well, the full release process isn't done yet, but you can do an unsigned build!
< dongcarl> sipa: I recommend: `env HOSTS=riscv64-linux-gnu ./contrib/guix/guix-build.sh`
< * dongcarl> double checking Guix manual
< sipa> why riscv64?
< dongcarl> Just anything but macOS cuz that needs the SDK haha
< sipa> i have the SDK
< dongcarl> Oh cool! extract it into depends/SDKs/
< dongcarl> Then I guess just `./contrib/guix/guix-build.sh` works!
< sipa> lemme do x86_64 linux first
< dongcarl> One hiccup... how many builder users did you setup?
< sipa> 10
< dongcarl> Okay then do `env MAX_JOBS=10`
< * dongcarl> makes note to see if I can automate builder user detection to cap MAX_JOBS
< luke-jr> is it bad if I don't know what a builder user is
< fanquake> dongcarl: heh. I ran into that recently and just made it make more: https://github.com/fanquake/core-review/commit/d5e5740dc823f0b4788fbcfaee228604c3582b43
< dongcarl> fanquake: Haha yeah, for my Guix installs I usually just make $(nproc) build users
< sipa> this VM only has access to 8 cores, so 10 should be enough...
< dongcarl> 👍
< sipa> is guix-daemon --no-substitutes what i want?
< dongcarl> sipa: sec
< luke-jr> [ 81%] GUILEC gnu/packages/maths.go
< dongcarl> sipa: Yup, I would also do `env ADDITIONAL_GUIX_COMMON_FLAGS=--keep-failed` when invoking `./contrib/guix/guix-build.sh` so that we can debug build failures if they crop up
< fanquake> is it too early to throw ADDITIONAL_GUIX_ENVIRONMENT_FLAGS='--bootstrap' in as well
< sipa> what's the difference between --no-substitutes and --bootstrap?
< sipa> guix time-machine: error: Git error: cannot locate local branch 'origin/keyring'
< dongcarl> --no-substitutes disables downloading binary substitutes from guix build farm, but builds from an intermediary group of bootstrap binaries, --bootstrap bootstraps from the absolute minimum set of bootstrap binaries
< dongcarl> sipa: are you using ./pre-inst-env? Or did you install?
< sipa> i did sudo make install
< * dongcarl> looking
< fanquake> sipa: plz block xuxihai999
< sipa> fanquake: tis but a word
< dongcarl> sipa: what commit are you on in bitcoin?
< sipa> master
< sipa> merge of 21130
< * dongcarl> have a lead but still looking
< dongcarl> sipa: Do you have a longer log I can take a look at?
< dongcarl> sipa: Did you build git from savannah's git?
< dongcarl> build guix*
< fanquake> sipa: needs to be blocked in the gui repo as well. Maybe just from the whole org.
< fanquake> Yea is spamming docs and & hwi now as well
< sipa> fanquake: blocking is always org wide
< fanquake> right. I take it the blocking hadn't happened yet
< sipa> i did
< sipa> hmm, does sipa_vm need to have some permissions to speak here?
< sipa> he pm'ed me, that worked
< sipa> VM escapee
< fanquake> Weird. Guess they managed to open a few more issues
< sipa> i blocked them after they created the ones i've seen
< * sipa> afk
< sipa> dongcarl: ^
< dongcarl> Kk
< fanquake> ffs: https://github.com/fanquake/core-review/issues/16#issuecomment-777183353. Guess I get to do the blocking now
< luke-jr> [ 94%] GUILEC gnu/services/cups.go
< dongcarl> luke-jr: cool!
< dongcarl> sipa: Looks to be due to an old libgit2 confusing not recognizing that origin/keyring means keyring branch of origin rather than branch named "origin/keyring"... What version do you have installed? http://logs.guix.gnu.org/guix/2020-11-12.log#232527
< gribble> https://github.com/bitcoin/bitcoin/issues/232527 | HTTP Error 404: Not Found
< dongcarl> luke-jr: I hope you have libgit2 >= 1.0 ?
< luke-jr> 1.1.0-r2
< dongcarl> yay
< luke-jr> 1.0 is so old it isn't available
< luke-jr> otoh Gentoo likes to murder old versions very quickly
< dongcarl> apparently debian stable + Ubuntu doesn't think so...
< luke-jr> keeping Python 2 is becoming a pain
< dongcarl> repology thinks the version that debian+Ubuntu uses is way too old: https://repology.org/project/libgit2/versions
< luke-jr> I wonder how Debian handles chromium
< dongcarl> I bet debian just keeps patching the CVEs themselves...
< luke-jr> chromium has CVEs all the time and often just forces major version bumps..
< dongcarl> ¯\_(ツ)_/¯
< dongcarl> luke-jr: Are you building on your GPD? XP
< dongcarl> luke-jr: How's it going?
< * dongcarl> struggling to keep eyelid open
< * dongcarl> going to bed
< dongcarl> sipa: I think that bug with origin/keyring is solved by upgrading to libgit2 1.1 and rebuilding everything that depends on it, let me know if that works!
< * dongcarl> zzz
< luke-jr> dongcarl: no, Haswell 4771
< luke-jr> it finished
< sipa> dongcarl: 1.1? i think i have 0.28
< sipa> it works!
< fanquake> !
< sipa> mes-boot, gcc 4.9.4, gcc 7.5.0, ...
< fanquake> was that with --no-substitues and/or bootstrap?
< fanquake> *--bootstrap
< sipa> both
< sipa> i think
< fanquake> If the build took days, and consumed 150% of you disk, you probably did
< achow101> what's the command to have guix bootstrap if I already installed it a while ago?
< sipa> fanquake: i gave it 128 GB disk space; should that be enough?
< fanquake> achow: For doing a build of Bitcoin Core, something like: env ADDITIONAL_GUIX_COMMON_FLAGS='--no-substitutes --keep-failed' ADDITIONAL_GUIX_ENVIRONMENT_FLAGS='--bootstrap' `./contrib/guix/guix-build.sh (which will build for all hosts)
< fanquake> sipa: iirc yes it should be.
< achow101> fanquake: thanks. I think I need to uninstall all of the guix packages for it to rebuild everything then..
< * luke-jr> watches Guix try to get to the net without permission
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/deb185d2fdcd...b69eab902567
< bitcoin-git> bitcoin/master fafca47 MarcoFalke: fuzz: Hide script_assets_test_minimizer
< bitcoin-git> bitcoin/master fac726b MarcoFalke: doc: Fixup docs in fuzz/script_assets_test_minimizer.cpp
< bitcoin-git> bitcoin/master b69eab9 MarcoFalke: Merge #20663: fuzz: Hide script_assets_test_minimizer
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20663: fuzz: Hide script_assets_test_minimizer (master...2012-fuzzNoReg) https://github.com/bitcoin/bitcoin/pull/20663
< vasild> sdaftuar: I wonder if it is worth changing SIGNATURE_TYPE=EdDSA_SHA512_Ed25519 to SIGNATURE_TYPE=7 in the request we send? If the buggy i2pd is the latest version which debian stable has...
< ishaqm> all, does anyone have pointers on compiling bitcoin-core with DEBUG symbols on?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b69eab902567...dd0521b6408a
< bitcoin-git> bitcoin/master fabeb5b MarcoFalke: fuzz: Disable shuffle when merge=1
< bitcoin-git> bitcoin/master dd0521b MarcoFalke: Merge #21023: fuzz: Disable shuffle when merge=1
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21023: fuzz: Disable shuffle when merge=1 (master...2101-fuzzMerge) https://github.com/bitcoin/bitcoin/pull/21023
< michaelfolkson> ishaqm: Does this answer your question? Please upvote if you find it useful https://bitcoin.stackexchange.com/questions/66892/what-are-the-debug-categories
< ishaqm> michaelfolkson, let me check (and of course if this is the answer, it must be upvoted :-) )
< ishaqm> thank you
< ishaqm> i see, I might have phrased my question better I am afraid. I am trying to output debug *symbols* i.e. so that I can run it with a debugger (gdb or similar)
< ishaqm> ah, the second link is exactly what I wanted, thank you very much michaelfolkson
< michaelfolkson> No problem
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/dd0521b6408a...a59e7ed0bc34
< bitcoin-git> bitcoin/master faefed8 MarcoFalke: fuzz: Count message type fuzzers before main()
< bitcoin-git> bitcoin/master fa4bc89 MarcoFalke: fuzz: Fail if message type is not fuzzed
< bitcoin-git> bitcoin/master a59e7ed MarcoFalke: Merge #20915: fuzz: Fail if message type is not fuzzed
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20915: fuzz: Fail if message type is not fuzzed (master...2101-fuzzFailMsgType) https://github.com/bitcoin/bitcoin/pull/20915
< prusnak> dongcarl: is there a Guix Docker image or what's the preferred way to build bitcoin w/ guix on macos ?
< fanquake> prusnak: you can try using https://github.com/fanquake/core-review/tree/master/guix if you want to. I think we link to it from our Guix docs as well.
< fanquake> That sets up a Docker image for doing Guix builds
< prusnak> ah great, so docker is preferred, ty
< prusnak> i'll send a pr to your repo, so also arm64 builds work via docker
< fanquake> great thanks
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a59e7ed0bc34...e498aeffbec9
< bitcoin-git> bitcoin/master fa59e0b MarcoFalke: test: Add missing script_standard_Solver_success cases
< bitcoin-git> bitcoin/master fa650ca MarcoFalke: Use -Wswitch for TxoutType where possible
< bitcoin-git> bitcoin/master e498aef MarcoFalke: Merge #20211: Use -Wswitch for TxoutType where possible
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20211: Use -Wswitch for TxoutType where possible (master...2010-WswitchTxoutType) https://github.com/bitcoin/bitcoin/pull/20211
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e498aeffbec9...685c16fcb2c7
< bitcoin-git> bitcoin/master f5f2f97 practicalswift: net: Avoid UBSan warning in ProcessMessage(...)
< bitcoin-git> bitcoin/master 3ddbf22 MarcoFalke: util: Disallow negative mocktime
< bitcoin-git> bitcoin/master 685c16f MarcoFalke: Merge #21043: net: Avoid UBSan warning in ProcessMessage(...)
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21043: net: Avoid UBSan warning in ProcessMessage(...) (master...ubsan-nTime) https://github.com/bitcoin/bitcoin/pull/21043
< bitcoin-git> [bitcoin] laanwj pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/685c16fcb2c7...a1be08405d9b
< bitcoin-git> bitcoin/master aa17a44 Vasil Dimov: net: move MillisToTimeval() from netbase to util/time
< bitcoin-git> bitcoin/master dec9b5e Vasil Dimov: net: move CloseSocket() from netbase to util/sock
< bitcoin-git> bitcoin/master ba9d732 Vasil Dimov: net: add RAII socket and use it instead of bare SOCKET
< bitcoin-git> [bitcoin] laanwj merged pull request #20788: net: add RAII socket and use it instead of bare SOCKET (master...sock) https://github.com/bitcoin/bitcoin/pull/20788
< vasild> jonatack: wumpus: Thanks! Now lets see what happens with the I2P PR, I think some good simplification will be possible. Maybe the moving of SocketEvents() to a standalone function will not be necessary because it would be possible to use sock.Wait()
< vasild> SocketEvents() allows to wait for at least one of a bunch of sockets to become ready. If it is just one socket then sock.Wait() may be used as well.
< jonatack> vasild: looking forward to it :)
< vasild> The I2P PR used SocketEvents() to wait on more than one socket simultaneously at some point - to issue more than one STREAM ACCEPT, but it turned out that this is SAM 3.2 feature and i2pd only supports SAM 3.1, so IIRC we no longer call SocketEvents() with more than one socket.
< vasild> So, now we wait for incoming connections on just one socket and there is a tiny interval of time - after we have accepted a connection and before we issue STREAM ACCEPT where we are not listening. I think this is acceptable, though I did not check what happens if somebody tries to connect to us exactly then - would he get an error or just wait for us to issue STREAM ACCEPT.
< * vasild> brb...
< wumpus> vasild: i'm pretty sure you need something like socketEvents, after all the P2P code uses async networking, waiting on one socket is not enough
< wumpus> (or is this only for session setup like the SOCKS5 init?)
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/a1be08405d9b...8e1913ae025a
< bitcoin-git> bitcoin/master 9db10a5 gzhao408: [refactor] clean up logic in testmempoolaccept
< bitcoin-git> bitcoin/master f82baf0 gzhao408: [refactor] return MempoolAcceptResult
< bitcoin-git> bitcoin/master 174cb53 gzhao408: [refactor] const ATMPArgs and non-const Workspace
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21062: refactor: return MempoolAcceptResult from ATMP (master...2021-02-refactor-validation) https://github.com/bitcoin/bitcoin/pull/21062
< vasild> wumpus: after we accept the i2p socket (in a i2p-specific way, not like usual tcp sockets via listen() bind() accept()), we give it to the connman like a normal already connected peer, then it uses CConnman::SocketEvents() internally to see if some of the peers has something to say
< vasild> but lets see...
< wumpus> vasild: ok so it's similar to SOCKS5 in that regard, there's some initial setup but after that it's simply a TCP connection like any other
< vasild> exactly
< wumpus> makes sense thanks
< luke-jr> -builder for `/home/dev/guix/root/gnu/store/6mx4wp11nwrj886amyb86nwgvws68d03-gzip-1.10.tar.xz.drv' failed to produce output path `/home/dev/guix/root/gnu/store/vgrx621h8750zm0ijlpdfnd9s4igsakp-gzip-1.10.tar.xz'
< luke-jr> dongcarl: I put the file where it wants it, but it's just deleting it and trying to refetch
< dongcarl> luke-jr: happy to debug, could you send me logs?
< sdaftuar> vasild: maybe, or perhaps we should just document the requirements somewhere so that others aren't tripped up? i don't have much of an opinion i guess
< luke-jr> dongcarl: nothing interesting in log
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8e1913ae025a...0ad46567905a
< bitcoin-git> bitcoin/master fabce45 MarcoFalke: fuzz: version handshake
< bitcoin-git> bitcoin/master 0ad4656 MarcoFalke: Merge #20370: fuzz: version handshake
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20370: fuzz: version handshake (master...2011-fuzzNetFlags) https://github.com/bitcoin/bitcoin/pull/20370
< dongcarl> luke-jr: That log you linked doesn't look like text?
< sipa> luke-jr: your dpaste looks like bzip2 compressed data
< dongcarl> sipa: could you send me `/usr/local/var/log/guix/drvs/wk/rgrjfkpqdzdvv81nbra7bvskfl9i57-gawk-5.0.1.drv.gz`?
< sipa> dongcarl: i restarted, and it seems to work now...
< dongcarl> sipa: Great!
< dongcarl> One of the things that Guix tries to do is to run as much of the test suite for its packages as possible... Which is great in ensuring that the built product works, but a lot of times reveals just how fragile pacakges' tests are (esp in a multi-threaded environment)
< luke-jr> sipa: indeed! lol
< luke-jr> `less` automatically decompresses but `wgetpaste` does not >_<
< luke-jr> if I make the source immutable, it errors with guix install: error: cannot unlink `/home/dev/guix/root/gnu/store/vgrx621h8750zm0ijlpdfnd9s4igsakp-gzip-1.10.tar.xz': Operation not permitted
< luke-jr> still no explanation why it's trying to delete and refetch it
< sipa> luke-jr: did starting over help?
< luke-jr> sipa: no
< * dongcarl> looking
< dongcarl> luke-jr: Did you turn off networking for this?
< luke-jr> sipa: not sure how far I got last time, but it's probably around the same point
< luke-jr> dongcarl: yes
< dongcarl> Okay, asking on #guix now
< dongcarl> Aha!
< dongcarl> luke-jr: Do: `guix download <path/to/file>`
< luke-jr> oh right, it keeps a db of what it has :/
< sipa> is there a way to make it download everything it will need for a particular build?
< dongcarl> sipa: I'm guessing if you do `--dry-run` it'll do that?
< * dongcarl> double-checking
< dongcarl> FWIW: All guix package builds are offline (enforced by network namespaces I think) and hermetic. The bitcoin build script I wrote also builds in a completely offline environment by default.
< dongcarl> Of course, pulling out the ethernet cable may be easier to trust...
< luke-jr> keeping guix itself offline is my only way to ensure it doesn't pull in a blob
< luke-jr> iptables -I OUTPUT -m owner --uid-owner dev -j REJECT
< luke-jr> in this case
< dongcarl> Right. I'm gunna see if it's easy to write a Guile script to generate a list of files to download from a manifest...
< sipa> luke-jr: but it needs to download source code anyway, and how do you know that source code doesn't contain any blobs? :)
< sipa> i guess your argument is: you download everything once, inspect it, then turn off networking, and build it?
< luke-jr> sipa: that's why I'm downloading each one manually and checking
< luke-jr> I'll automate it once I have it sorted out
< sipa> that's fair
< bitcoin-git> [bitcoin] prayank23 opened pull request #21155: doc: Improve Tor docs (master...tor-docs-improve) https://github.com/bitcoin/bitcoin/pull/21155
< dongcarl> luke-jr: I'll post on the Guix mailing list about extracting out a list of needed downloads from a manifest, hopefully it's a simple enough Guile script.
< sipa> dongcarl: if what i've been told about scheme/lisp is true, this should be easy ;)
< dongcarl> sipa: Hehe true :-)
< luke-jr> dongcarl: guix ignored that Debian trick
< MarcoFalke> how much space does a guix build need these days (looks like DrahtBot is running out of disk)
< dongcarl> MarcoFalke: You can most likely garbage collect and get some space back. One thing on my list is to pin the latest manifest output so that it doesn't get garbage collected, so that you can safely garbage collect everything else without affecting bitcoin builds
< dongcarl> luke-jr: Looking
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0ad46567905a...937dfa839873
< bitcoin-git> bitcoin/master acd7980 practicalswift: log: Move "Leaving block file [...]: [...]" log message to debug category
< bitcoin-git> bitcoin/master 25f899c practicalswift: log: Move "Pre-allocating up to position 0x[...] in [...].dat" log message...
< bitcoin-git> bitcoin/master 937dfa8 Wladimir J. van der Laan: Merge #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" l...
< bitcoin-git> [bitcoin] laanwj merged pull request #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" log message to debug category (master...pre-allocation-up-to-position-0xff-in-foo.dat) https://github.com/bitcoin/bitcoin/pull/21041
< MarcoFalke> dongcarl: wait? guix can garbage collect? how
< dongcarl> MarcoFalke: HPC folks love their admin tools hehe
< wumpus> #startmeeting
< core-meetingbot> Meeting started Thu Feb 11 19:00:17 2021 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< fjahr> hi
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< michaelfolkson> hi
< dongcarl> hi
< luke-jr> existing convo overwritten by meeting :P
< achow101> hi
< phantomcircuit> hi
< warren> hi
< phantomcircuit> warren, HI
< jonasschnelli> Hi
< wumpus> one proposed meeting topic Initial Guix Release Transition Plan for 22.0 (dongcarl)
< dongcarl> :)
< wumpus> anything else to discuss this week?
< MarcoFalke> hi
< sipa> hi
< jonatack> hi
< jonasschnelli> I have a small one,... nested commands vs @height macros
< wumpus> jonasschnelli: thanks
< jnewbery> hi
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 open: 7 blockers, no bugfixes, 2 chasing concept ACK
< wumpus> anything to add/remove or that is ready for merge?
< sdaftuar> can i request that #20726 be added?
< gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
< sipa> i like #20861
< gribble> https://github.com/bitcoin/bitcoin/issues/20861 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses by sipa · Pull Request #20861 · bitcoin/bitcoin · GitHub
< sipa> *i'd like
< jonatack> #19145 seems close to rfm
< gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr · Pull Request #19145 · bitcoin/bitcoin · GitHub
< wumpus> sdaftuar: added
< achow101> 19145 has 4 acks
< wumpus> jonatack: achow101 good to know
< fjahr> jonatack, achow101: thanks, I was just typing :)
< wumpus> sipa: added
< meshcollider> hi
< wumpus> #topic Initial Guix Release Transition Plan for 22.0 (dongcarl)
< core-meetingbot> topic: Initial Guix Release Transition Plan for 22.0 (dongcarl)
< dongcarl> Hello everyone! I'm published a plan here: #21145
< gribble> https://github.com/bitcoin/bitcoin/issues/21145 | Guix Release Transition Plan for 22.0 · Issue #21145 · bitcoin/bitcoin · GitHub
< wumpus> dongcarl: great!
< dongcarl> There is a "What I need help with" section, which I'd encourage people to look at
< wumpus> adding 22.0 milestone
< dongcarl> :)
< luke-jr> still missing gitian support
< wumpus> i've been trying around with guix builds, seems to work okay
< dongcarl> wumpus: Happy to hear that!
< achow101> the guix build seems to work
< luke-jr> only if you run third-party blobs
< achow101> getting guix setup seems to be the sticking point
< dongcarl> As always, anything that doesn't work: tell me and I'll document and try to debug
< dongcarl> Right. Setting up Guix is definitely a pain point, which is why a detailed installation guide is in the TODOs
< wumpus> hit some small snags but it they were my own fault (e.g. crap left behind in the build dir), and the issue reported https://github.com/bitcoin/bitcoin/pull/21089#issuecomment-777562303 here which seems to be harmless just spammy
< MarcoFalke> Is it? debian bullseye comes with it and setting it up on other distros isn't too hard either. I think the pain point is to keep it in a working state/learn to use it.
< dongcarl> wumpus: My general feeling is that if people run into things that are "their own fault" enough times, it's probably best to add an early check.
< warren> luke-jr: I don't understand why you are asking for gitian support. The purpose of switching to guix is to eliminate the untrackable blob that we had in gitian.
< wumpus> i had no trouble setting up guix at all, then again an ubuntu VM is probably easy mode
< luke-jr> warren: as things stand, Guix is a regression in that respect
< sipa> luke-jr: you can run guix in a VM if you like
< luke-jr> warren: gitian works just fine without any untrusted blobs on my own system
< MarcoFalke> Didn't we discuss this last week?
< sipa> yes
< wumpus> yes, no need to revisit this
< MarcoFalke> ok, let's move on for now
< luke-jr> it still needs to get on the plan
< MarcoFalke> dongcarl: Do we need to change anything in the ci?
< wumpus> luke-jr: you can write it yourself and contribute it as well as you want it so badly
< wumpus> luke-jr: don't demand others work
< luke-jr> wumpus: first I need to get Guix to work ;)
< MarcoFalke> Currently we have the windows cross build using focal because gitian uses that
< MarcoFalke> (windows cross build in the ci)
< warren> dongcarl: Pre-meeting it sounds like a supported way to pre-populate downloads for guix bootstrap is a priority. The packager of Guix for Debian similarly commented that entirely offline is a requirement for their distro packages. He had to add a ton of unsupported hacks to package Guix for Debian.
< sipa> i've been setting up guix from scratch in an ubuntu VM, from source, with --bootstrap... it's been a bit of a pain, but running fine now
< MarcoFalke> So I am wondering how to deal with diverging compilers between the guix windows build and the ci windows build
< * dongcarl> trying to answer one at a time
< sipa> MarcoFalke: ideally we have a guix build in CI, i guess?
< MarcoFalke> sipa: That'd be hard to setup, because you'd have to cache the gnu_store
< MarcoFalke> for DrahtBot that is 11GB
< MarcoFalke> 11G./temp/scratch/guix/root_store/
< dongcarl> MarcoFalke: Right, ideally we would have the same... Let me write it down and think about it. Will reach out back to you. Most likely we just cache a fully-GC'd gnu_store
< luke-jr> wumpus: the only "demand" (more like expectation) is that it be usable without regressions before we switch to it exclusively.. and I've already said I'm willing to help, but I need to get to the point where I can
< sipa> MarcoFalke: well, let drahtbot do it and comment, rather than actual CI?
< MarcoFalke> on every pull?
< sipa> just master would be great already
< dongcarl> luke-jr: Will continue helping you set up like we've been doing this past 24 hrs :-)
< sipa> luke-jr: you don't run gitian in a VM (outside; i'm not talking about the VM gitian itself uses internally)
< sipa> ?
< luke-jr> sipa: not anymore, no; I got rid of that extra layer a while ago..
< sipa> ok
< warren> gitian has optional VM or container mode
< luke-jr> (only did that at first because once upon a time gitian required Ubuntu IIRC)
< sipa> warren: i know; that's not what i'm talking about
< MarcoFalke> Maybe for ci we just use the closest version of mingw to guix that is offered by ubuntu/debian?
< dongcarl> MarcoFalke: I think it'll be easier to do the other way around
< dongcarl> I'll double-check, I think I made the Guix mingw build correspond to focal when I first set it up
< luke-jr> are we expecting CI to produce binaries that match Guix? O.o
< wumpus> no, just to run with the same version of the compiler to find relevant issues
< dongcarl> No, but I think similar behaviour is good
< MarcoFalke> luke-jr: Mostly to catch compiler errors before they are in the release
< wumpus> right
< dongcarl> I feel like I might have missed some comments up above, let me know if I did
< warren> dongcarl: "Most likely we just cache a fully-GC'd gnu_store" <--- Is this also the answer to my question above about offline operation?
< warren> Debian and Fedora require that for builds
< luke-jr> MarcoFalke: ultimately, I think a full Guix CI is needed to avoid that?
< dongcarl> warren: Could you detail what you want out of offline operations?
< MarcoFalke> luke-jr: I think that'd be tricky to set up, as we need to cache the full guix store
< MarcoFalke> (the part that we are using)
< luke-jr> MarcoFalke: just DrahtBot is enough..? it's not like we want *all* the CI to use the same compiler ideally
< sipa> warren: the gnu_store is the result of building all dependencies; i think with "offline operation" you're talking about the ability to fetch the sources beforehand, not the results (which implies trusted binaries)
< warren> dongcarl: for packaging Guix in Debian in Fedora we're required to bootstrap from source starting with the distro toolchains of those respective distros. The build process cannot download anything from the network so we must pre-populate any downloads that it would expect. The Debian packager added a ton of hacks to enable this to work offline for Debian guix bootstrap.
< sipa> warren: for CI trusted binaries are fine, we're just mimicking the release process
< warren> s/Debian in Fedora/Debian and Fedora/
< dongcarl> warren: Right, I believe those hacks are still required for packing for Fedora. I believe the Debian maintainer just mentioned that he's slowly upstreaming this effort.
< luke-jr> warren: can you help with that after the meeting? ;)
< warren> It was unfortunate to learn that Guix does not have a goal of Guix itself being reproducible.
< dongcarl> I think w/re CI, let's get the versions as close as possible, and we will figure out a way to get a Guix-based CI working.
< dongcarl> warren: ?
< warren> dongcarl: the resulting Guix is not 100% identical to bootstrapped in a different way, reason being is reproducibility is not a goal of Guix, only bootstrapability.
< sipa> you mean the guix-daemon and guix binaries?
< dongcarl> If you're building Guix from source in $DISTRO, it's not going to be reproducible because $DISTRO's build tools are not reproducible. But once you have Guix built from source, you can reproduce Guix itself, and even challenge the binary tarball released on the Guix website.
< dongcarl> See: `guix challenge` and the last section of: https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
< warren> OK thanks.
< wumpus> it could do a second pass for that?
< dongcarl> wumpus: Yup! `guix install guix` works (I think)
< sipa> we must go deeper.
< wumpus> like if you compile the compiler using the OS' build tools, then compile the compiler using that compiler, that one should be deterministic
< wumpus> ok
< dongcarl> :-)
< dongcarl> Any other concerns/questions?
< luke-jr> wumpus: Gentoo actually builds every GCC 3 times :p
< warren> Should a goal of bitcoin's release reproduce the bootstrap of guix and challenge? Or you expect guix to be already somehow bootstrapped on your own?
< sipa> warren: i think our goal should be reproducibility; the user can choose what level of trust they have in their own build process
< wumpus> agree with sipa
< phantomcircuit> luke-jr, i guess that's why it's so slow
< dongcarl> Exactly... Especially once Guix bridges into stage0... Bootstrap builds may take a week...
< sipa> if you guix, presumably you got it in a way you're comfortable with, and if you have that - regardless of how you did so - you can build a reproducible bitcoin core release binary
< sipa> +have
< wumpus> it's useful if some people taking part in builds bootstrap guix from ~nothing, but not everyone would need to do this to be useful
< luke-jr> I'm going to aim to have a gitian descriptor that produces a guix base with most deps at least
< warren> That'd be fine if Guix had an upstream supported way of doing it offline
< dongcarl> Guix boostrapping party leggoooo (just a bunch of nerds staring a build logs scrolling by)
< wumpus> hehe
< sipa> dongcarl: a bunch of geeks
< sipa> (that's how guix is pronounced, right?)
< dongcarl> warren: Let's open a dialogue with vagrantc, he has a full year's experience doing this for Debian and can answer more questions
< luke-jr> lol
< dongcarl> Haha yup!
< dongcarl> NOT goo-iks!
< warren> k
< sipa> building python 3.8.2, and guile 3.0.2 now, ...
< sipa> is there any kind of progress indicator?
< luke-jr> I'm still stuck on not allowing it to run a 3P bash :/
< dongcarl> sipa: Yes if it thinks you are on a tty... I might have messed that up with all my nesting...
< sipa> luke-jr: yes, i'm sure we'll find a way around that
< dongcarl> luke-jr: Yeah let's talk afterwards
< sipa> dongcarl: it's printing what it's doing, and what it did; i don't know what it still has to do
< dongcarl> sipa: Yup, if it thinks it has a tty it'll print "what it still has to do" as well... A good UX improvement... Will note it down
< sipa> aH
< sipa> cool
< wumpus> that would be neat
< dongcarl> Any other qs/comments?
< * jb551> ponders a nix guix build
< wumpus> if not, let's move to jonasschnelli's quick topic
< dongcarl> 👍
< jonatack> dongcarl: know that you had me at guile (and guix pronounced geeks)
< dongcarl> hehe
< jonasschnelli> I think it would be helpful to chime in on #16439 versus (or and) #20273
< gribble> https://github.com/bitcoin/bitcoin/issues/16439 | cli/gui: support "@height" in place of blockhash for getblock on client side by ajtowns · Pull Request #16439 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20273 | Extend support for nested commands to bitcoin-cli by jonasschnelli · Pull Request #20273 · bitcoin/bitcoin · GitHub
< wumpus> #topic Nested commands vs @height macros (jonasschnelli)
< core-meetingbot> topic: Nested commands vs @height macros (jonasschnelli)
< jonasschnelli> I guess aj and I like to know what and to drag through the rebase hell
< jonasschnelli> For me, nested commands in the cli would be pretty neat (and consistent with the GUI)
< wumpus> nested commands in the cli would be great, all for that
< luke-jr> I don't think I'd use it, but why not
< achow101> why not both?
< wumpus> @height is basically a shorthand for nested commands, could be useful too dunno
< jonasschnelli> yes. Both would work as well
< wumpus> eg @height would evaluate to the block hash right ?
< luke-jr> if both, it makes sense to implement @height using nested logic
< wumpus> i have no problems with anything as long as it's client side
< jonatack> i'd use 16439, thus my reviews
< luke-jr> just be sure @number doesn't turn into a hash in other contexts >_<
< jonasschnelli> @height could just translate into a nedted command
< luke-jr> eg tx comments
< jonasschnelli> preprocessing
< jonatack> yes, why not
< jonasschnelli> If people think both (together) are viable, then we can continue rebasing it.
< jonasschnelli> But there was some lack of concept acks/nacks
< wumpus> i think nested should go in first
< luke-jr> jonasschnelli: what happens if I want to do a tx comment '@45123' or such?
< jonasschnelli> Yes. It's kind of the base
< wumpus> it's the most general and powerful
< sipa> the height thing should only trigger in arguments that are known to be block hashes?
< luke-jr> imo yes
< sipa> (which could be in the rpc tables)
< jonasschnelli> yes
< jonasschnelli> the descriptors are also a problem
< jonasschnelli> since they use bracket syntax
< jonasschnelli> but all solvable
< luke-jr> hrm
< sipa> yeah just restrict it to whitelisted fields
< jonasschnelli> yes.
< luke-jr> sipa: well, for nested in genreal..
< sipa> and concept ack on having stuff like this on the client side
< jonasschnelli> cool. Let me enhance it then.
< jonasschnelli> (btw: its purely client side)
< jonatack> yes, iirc 16439 is gui-side and cli-side (with some duplication for now)
< luke-jr> does GUI currently have a problem with descriptors?
< jonasschnelli> I don't recall but I think possibly
< jonasschnelli> no. it doesn't since its captured in quotes
< wumpus> anything else to discuss?
< wumpus> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu Feb 11 19:50:25 2021 UTC.
< luke-jr> dongcarl: warren: so anyway, I made gnu/packages/bootstrap/x86_64-linux and dropped my bash/mkdir/xz/tar bins there - but Guix is still trying to download the 3rd party blobs
< dongcarl> luke-jr: Are you running the Test Suite?
< dongcarl> luke-jr: Debian maintainer seems to think that only the test suite tries to clobber the 3rd party blobs
< jamesob> hi
< jamesob> Oh oops, timezones haha
< wumpus> heh
< luke-jr> dongcarl: no
< luke-jr> per docs, I was trying to: guix install glibc-utf8-locales
< luke-jr> fwiw, the answer we're getting in #guix appears to still be "you can't" (setup Guix without trusted third-party binaries) ☹
< dongcarl> sipa: Could you send me: /usr/local/var/log/guix/drvs/vh/phki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv.gz
< dongcarl> luke-jr: Right, until wip-full-source-bootstrap is merged, building packages in Guix will require the binary seed. Which is smaller than the Ubuntu distro.
< sipa> does that work?
< luke-jr> dongcarl: which makes Guix a suitable substittue for Ubuntu, but not gitian
< dongcarl> sipa: No, I think 0bin mangles stuff... Could you pipe it to `bzcat` first?
< * luke-jr> wonders why 0bin requires cookies :/
< sipa> dongcarl: https://0bin.net/paste/08lqkp9f#2Fw4RoP+qHZXlTB7EIRbDntA6BuMuQEO5dSALl7Rfdr
< gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
< dongcarl> sipa: Ah I know this one, looking for best fix right now
< dongcarl> sipa: Okay this is due to a bug in Gnutls' test suite that tests a certificate, but that certificate expired on 2020-10-24. There's already a fix in Guix master upstream, which I will pull into my branch for our time-machine, but for now, this might work: 1. Disable NTP 2. Set your time to 2020-10-01 3. `guix build
< dongcarl> /gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv` (only builds gnutls) 4. re-enable NTP and check that your time is okay
< dongcarl> Actually I think it's already fixed as of #21088... Will check
< gribble> https://github.com/bitcoin/bitcoin/issues/21088 | guix: Jump forwards in time-machine and adapt by dongcarl · Pull Request #21088 · bitcoin/bitcoin · GitHub
< dongcarl> Yes, it's already fixed as of that time-machine jump :-)
< dongcarl> sipa: If my hack doesn't work, you may want to check out that PR
< sipa> ok, so i'll just checkout that branch
< dongcarl> sipa: Thanks for being patient with me as we work through these kinks, I am taking notes on the hiccups we run into :-)
< sipa> dongcarl: very welcome
< bitcoin-git> [bitcoin] prayank23 closed pull request #21155: doc: Improve Tor docs (master...tor-docs-improve) https://github.com/bitcoin/bitcoin/pull/21155
< bitcoin-git> [bitcoin] prayank23 opened pull request #21157: doc: Improve Tor docs (master...tor-docs-add) https://github.com/bitcoin/bitcoin/pull/21157
< sipa> dongcarl: now it's trying to build macOS
< jb55> sipa: that happened to me and I had to explicitly set HOSTS=x86_64-linux-gnu
< jb55> then again I haven't tried that PR so might be different issue
< bitcoin-git> [bitcoin] jrawsthorne opened pull request #21158: lib: Add Taproot support to libconsensus (master...libconsensus_taproot) https://github.com/bitcoin/bitcoin/pull/21158