19:00:17 <wumpus> #startmeeting 
19:00:18 <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.
19:00:18 <core-meetingbot> Available commands: action commands idea info link nick
19:00:38 <fjahr> hi
19:00:39 <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
19:00:41 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:00:46 <michaelfolkson> hi
19:00:55 <dongcarl> hi
19:00:55 <luke-jr> existing convo overwritten by meeting :P
19:00:56 <achow101> hi
19:01:00 <phantomcircuit> hi
19:01:27 <warren> hi
19:01:37 <phantomcircuit> warren, HI
19:01:38 <jonasschnelli> Hi
19:01:41 <wumpus> one proposed meeting topic Initial Guix Release Transition Plan for 22.0 (dongcarl)
19:02:01 <dongcarl> :)
19:02:06 <wumpus> anything else to discuss this week?
19:02:09 <MarcoFalke> hi
19:02:18 <sipa> hi
19:02:20 <jonatack> hi
19:02:24 <jonasschnelli> I have a small one,... nested commands vs @height macros
19:02:37 <wumpus> jonasschnelli: thanks
19:02:47 <jnewbery> hi
19:03:07 <wumpus> #topic High priority for review
19:03:08 <core-meetingbot> topic: High priority for review
19:03:27 <wumpus> https://github.com/bitcoin/bitcoin/projects/8    open: 7 blockers, no bugfixes, 2 chasing concept ACK
19:03:44 <wumpus> anything to add/remove or that is ready for merge?
19:03:59 <sdaftuar> can i request that #20726 be added?
19:04:02 <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
19:04:09 <sipa> i like #20861
19:04:11 <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
19:04:15 <sipa> *i'd like
19:04:26 <jonatack> #19145 seems close to rfm
19:04:29 <gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr · Pull Request #19145 · bitcoin/bitcoin · GitHub
19:04:39 <wumpus> sdaftuar: added
19:04:39 <achow101> 19145 has 4 acks
19:04:49 <wumpus> jonatack: achow101  good to know
19:05:02 <fjahr> jonatack, achow101: thanks, I was just typing :)
19:05:27 <wumpus> sipa: added
19:05:29 <meshcollider> hi
19:06:29 <wumpus> #topic Initial Guix Release Transition Plan for 22.0 (dongcarl)
19:06:29 <core-meetingbot> topic: Initial Guix Release Transition Plan for 22.0 (dongcarl)
19:06:45 <dongcarl> Hello everyone! I'm published a plan here:  #21145
19:06:46 <gribble> https://github.com/bitcoin/bitcoin/issues/21145 | Guix Release Transition Plan for 22.0 · Issue #21145 · bitcoin/bitcoin · GitHub
19:07:10 <wumpus> dongcarl: great!
19:07:22 <dongcarl> There is a "What I need help with" section, which I'd encourage people to look at
19:07:30 <wumpus> adding 22.0 milestone
19:07:35 <dongcarl> :)
19:07:57 <luke-jr> still missing gitian support
19:07:59 <wumpus> i've been trying around with guix builds, seems to work okay
19:08:17 <dongcarl> wumpus: Happy to hear that!
19:08:21 <achow101> the guix build seems to work
19:08:29 <luke-jr> only if you run third-party blobs
19:08:30 <achow101> getting guix setup seems to be the sticking point
19:08:31 <dongcarl> As always, anything that doesn't work: tell me and I'll document and try to debug
19:09:00 <dongcarl> Right. Setting up Guix is definitely a pain point, which is why a detailed installation guide is in the TODOs
19:09:21 <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
19:10:13 <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.
19:10:15 <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.
19:10:31 <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.
19:10:44 <wumpus> i had no trouble setting up guix at all, then again an ubuntu VM is probably easy mode
19:10:55 <luke-jr> warren: as things stand, Guix is a regression in that respect
19:11:07 <sipa> luke-jr: you can run guix in a VM if you like
19:11:11 <luke-jr> warren: gitian works just fine without any untrusted blobs on my own system
19:11:18 <MarcoFalke> Didn't we discuss this last week?
19:11:21 <sipa> yes
19:11:32 <wumpus> yes, no need to revisit this
19:11:33 <MarcoFalke> ok, let's move on for now
19:11:40 <luke-jr> it still needs to get on the plan
19:11:58 <MarcoFalke> dongcarl: Do we need to change anything in the ci?
19:12:15 <wumpus> luke-jr: you can write it yourself and contribute it as well as you want it so badly
19:12:22 <wumpus> luke-jr: don't demand others work
19:12:29 <luke-jr> wumpus: first I need to get Guix to work ;)
19:12:33 <MarcoFalke> Currently we have the windows cross build using focal because gitian uses that
19:12:42 <MarcoFalke> (windows cross build in the ci)
19:12:49 <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.
19:13:23 <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
19:13:30 <MarcoFalke> So I am wondering how to deal with diverging compilers between the guix windows build and the ci windows build
19:13:45 <dongcarl> trying to answer one at a time
19:14:01 <sipa> MarcoFalke: ideally we have a guix build in CI, i guess?
19:14:19 <MarcoFalke> sipa: That'd be hard to setup, because you'd have to cache the gnu_store
19:14:35 <MarcoFalke> for DrahtBot that is 11GB
19:14:37 <MarcoFalke> 11G	./temp/scratch/guix/root_store/
19:15:09 <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
19:15:24 <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
19:15:26 <sipa> MarcoFalke: well, let drahtbot do it and comment, rather than actual CI?
19:15:38 <MarcoFalke> on every pull?
19:15:44 <sipa> just master would be great already
19:16:21 <dongcarl> luke-jr: Will continue helping you set up like we've been doing this past 24 hrs :-)
19:16:22 <sipa> luke-jr: you don't run gitian in a VM (outside; i'm not talking about the VM gitian itself uses internally)
19:16:28 <sipa> ?
19:16:41 <luke-jr> sipa: not anymore, no; I got rid of that extra layer a while ago..
19:16:46 <sipa> ok
19:16:58 <warren> gitian has optional VM or container mode
19:17:11 <luke-jr> (only did that at first because once upon a time gitian required Ubuntu IIRC)
19:17:20 <sipa> warren: i know; that's not what i'm talking about
19:17:49 <MarcoFalke> Maybe for ci we just use the closest version of mingw to guix that is offered by ubuntu/debian?
19:18:05 <dongcarl> MarcoFalke: I think it'll be easier to do the other way around
19:18:30 <dongcarl> I'll double-check, I think I made the Guix mingw build correspond to focal when I first set it up
19:19:00 <luke-jr> are we expecting CI to produce binaries that match Guix? O.o
19:19:17 <wumpus> no, just to run with the same version of the compiler to find relevant issues
19:19:20 <dongcarl> No, but I think similar behaviour is good
19:19:46 <MarcoFalke> luke-jr: Mostly to catch compiler errors before they are in the release
19:19:55 <wumpus> right
19:19:58 <dongcarl> I feel like I might have missed some comments up above, let me know if I did
19:20:01 <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?
19:20:23 <warren> Debian and Fedora require that for builds
19:20:34 <luke-jr> MarcoFalke: ultimately, I think a full  Guix CI is needed to avoid that?
19:20:53 <dongcarl> warren: Could you detail what you want out of offline operations?
19:21:14 <MarcoFalke> luke-jr: I think that'd be tricky to set up, as we need to cache the full guix store
19:21:29 <MarcoFalke> (the part that we are using)
19:21:48 <luke-jr> MarcoFalke: just DrahtBot is enough..? it's not like we want *all* the CI to use the same compiler ideally
19:21:50 <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)
19:22:07 <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.
19:22:09 <sipa> warren: for CI trusted binaries are fine, we're just mimicking the release process
19:23:45 <warren> s/Debian in Fedora/Debian and Fedora/
19:23:56 <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.
19:24:06 <luke-jr> warren: can you help with that after the meeting? ;)
19:24:38 <warren> It was unfortunate to learn that Guix does not have a goal of Guix itself being reproducible.
19:24:49 <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.
19:24:53 <dongcarl> warren: ?
19:25:49 <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.
19:26:22 <sipa> you mean the guix-daemon and guix binaries?
19:28:11 <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.
19:28:32 <dongcarl> See: `guix challenge` and the last section of: https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
19:28:39 <warren> OK thanks.
19:28:40 <wumpus> it could do a second pass for that?
19:28:56 <dongcarl> wumpus: Yup! `guix install guix` works (I think)
19:29:09 <sipa> we must go deeper.
19:29:09 <wumpus> like if you compile the compiler using the OS' build tools, then compile the compiler using that compiler, that one should be deterministic
19:29:12 <wumpus> ok
19:29:25 <dongcarl> :-)
19:29:52 <dongcarl> Any other concerns/questions?
19:30:17 <luke-jr> wumpus: Gentoo actually builds every GCC 3 times :p
19:30:21 <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?
19:30:55 <sipa> warren: i think our goal should be reproducibility; the user can choose what level of trust they have in their own build process
19:31:05 <wumpus> agree with sipa
19:31:09 <phantomcircuit> luke-jr, i guess that's why it's so slow
19:31:24 <dongcarl> Exactly... Especially once Guix bridges into stage0... Bootstrap builds may take a week...
19:31:37 <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
19:31:46 <sipa> +have
19:31:54 <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
19:32:14 <luke-jr> I'm going to aim to have a gitian descriptor that produces a guix base with most deps at least
19:32:21 <warren> That'd be fine if Guix had an upstream supported way of doing it offline
19:32:37 <dongcarl> Guix boostrapping party leggoooo (just a bunch of nerds staring a build logs scrolling by)
19:32:49 <wumpus> hehe
19:33:24 <sipa> dongcarl: a bunch of geeks
19:33:31 <sipa> (that's how guix is pronounced, right?)
19:33:36 <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
19:33:36 <luke-jr> lol
19:33:42 <dongcarl> Haha yup!
19:33:52 <dongcarl> NOT goo-iks!
19:33:53 <warren> k
19:34:04 <sipa> building python 3.8.2, and guile 3.0.2 now, ...
19:34:16 <sipa> is there any kind of progress indicator?
19:34:30 <luke-jr> I'm still stuck on not allowing it to run a 3P bash :/
19:34:46 <dongcarl> sipa: Yes if it thinks you are on a tty... I might have messed that up with all my nesting...
19:34:47 <sipa> luke-jr: yes, i'm sure we'll find a way around that
19:35:03 <dongcarl> luke-jr: Yeah let's talk afterwards
19:35:07 <sipa> dongcarl: it's printing what it's doing, and what it did; i don't know what it still has to do
19:35:51 <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
19:36:02 <sipa> aH
19:36:06 <sipa> cool
19:36:39 <wumpus> that would be neat
19:37:14 <dongcarl> Any other qs/comments?
19:37:56 <jb551> ponders a nix guix build
19:38:28 <wumpus> if not, let's move to jonasschnelli's quick topic
19:38:37 <dongcarl> 👍
19:38:38 <jonatack> dongcarl: know that you had me at guile (and guix pronounced geeks)
19:38:45 <dongcarl> hehe
19:39:02 <jonasschnelli> I think it would be helpful to chime in on #16439 versus (or and) #20273
19:39:06 <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
19:39:07 <gribble> https://github.com/bitcoin/bitcoin/issues/20273 | Extend support for nested commands to bitcoin-cli by jonasschnelli · Pull Request #20273 · bitcoin/bitcoin · GitHub
19:39:11 <wumpus> #topic Nested commands vs @height macros (jonasschnelli)
19:39:11 <core-meetingbot> topic: Nested commands vs @height macros (jonasschnelli)
19:39:21 <jonasschnelli> I guess aj and I like to know what and to drag through the rebase hell
19:39:43 <jonasschnelli> For me, nested commands in the cli would be pretty neat (and consistent with the GUI)
19:40:00 <wumpus> nested commands in the cli would be great, all for that
19:40:10 <luke-jr> I don't think I'd use it, but why not
19:40:13 <achow101> why not both?
19:40:21 <wumpus> @height is basically a shorthand for nested commands, could be useful too dunno
19:40:29 <jonasschnelli> yes. Both would work as well
19:40:33 <wumpus> eg @height would evaluate to the block hash right ?
19:40:39 <luke-jr> if both, it makes sense to implement @height using nested logic
19:40:44 <wumpus> i have no problems with anything as long as it's client side
19:40:48 <jonatack> i'd use 16439, thus my reviews
19:41:00 <luke-jr> just be sure @number doesn't turn into a hash in other contexts >_<
19:41:07 <jonasschnelli> @height could just translate into a nedted command
19:41:07 <luke-jr> eg tx comments
19:41:19 <jonasschnelli> preprocessing
19:41:59 <jonatack> yes, why not
19:42:28 <jonasschnelli> If people think both (together) are viable, then we can continue rebasing it.
19:42:35 <jonasschnelli> But there was some lack of concept acks/nacks
19:42:40 <wumpus> i think nested should go in first
19:42:57 <luke-jr> jonasschnelli: what happens if I want to do a tx comment '@45123' or such?
19:43:00 <jonasschnelli> Yes. It's kind of the base
19:43:09 <wumpus> it's the most general and powerful
19:43:18 <sipa> the height thing should only trigger in arguments that are known to be block hashes?
19:43:23 <luke-jr> imo yes
19:43:24 <sipa> (which could be in the rpc tables)
19:43:34 <jonasschnelli> yes
19:43:41 <jonasschnelli> the descriptors are also a problem
19:43:47 <jonasschnelli> since they use bracket syntax
19:43:52 <jonasschnelli> but all solvable
19:44:23 <luke-jr> hrm
19:44:26 <sipa> yeah just restrict it to whitelisted fields
19:44:40 <jonasschnelli> yes.
19:44:42 <luke-jr> sipa: well, for nested in genreal..
19:44:43 <sipa> and concept ack on having stuff like this on the client side
19:45:01 <jonasschnelli> cool. Let me enhance it then.
19:45:29 <jonasschnelli> (btw: its purely client side)
19:45:31 <jonatack> yes, iirc 16439 is gui-side and cli-side (with some duplication for now)
19:45:44 <luke-jr> does GUI currently have a problem with descriptors?
19:46:22 <jonasschnelli> I don't recall but I think possibly
19:47:18 <jonasschnelli> no. it doesn't since its captured in quotes
19:50:01 <wumpus> anything else to discuss?
19:50:25 <wumpus> #endmeeting