19:00:39 <wumpus> #startmeeting 
19:00:49 <jonasschnelli> hi
19:00:52 <sipa> hi
19:00:58 <warren> hi
19:01:01 <dongcarl> hi
19:01:01 <achow101> hi
19:01:02 <hebasto> h
19:01:02 <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:01:04 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:24 <warren> I have a short suggested topic, can mention later when there's an opening.
19:01:31 <ariard> hi
19:01:32 <fjahr> hi
19:01:37 <sipa> i like how wumpus doesn't even forget to call wumpus to the meeting
19:01:39 <wumpus> no proposed meeting topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:01:54 <michaelfolkson> hi
19:01:57 <wumpus> sipa: hah!
19:02:01 <jonasschnelli> heh
19:02:12 <jnewbery> hi
19:02:52 <wumpus> warren: do let us know so that we can announce it?
19:03:20 <wumpus> #topic High priority for review
19:03:48 <ariard> may we get #19160 as a priority (multiprocess) ?
19:03:50 <gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
19:03:50 <wumpus> https://github.com/bitcoin/bitcoin/projects/8   11 blockers, 1 bugfix, 2 chasing concept ACK
19:03:58 <emzy> hi
19:04:14 <ariard> it sounds finally to attract reviewers :)
19:04:21 <warren> Suggested Topic: A bit concerning to me is Fedora is again approaching possible packaging and distribution of Bitcoin Core. While the openssl-based risk is now eliminated, I now intend to package Guix for Fedora and use that to make binary identical builds. I think I can handle the Fedora specific parts of this. But Guix for Bitcoin Core releases is still missing a few parts of what Gitian used to do?
19:04:26 <aj> hi-ish (laggy)
19:04:50 <jonatack> hi
19:04:59 <wumpus> ariard: added
19:05:05 <ariard> thanks!
19:05:28 <wumpus> 12 blockers now! anything to add/remove or that's ready for merge?
19:05:42 <michaelfolkson> Your #19820 is still chasing Concept ACK ariard. Keep it there or remove?
19:05:43 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
19:06:08 <ariard> michaelfolkson: it's not really consuming review time...
19:06:13 <jonatack> wumpus: can rm #20391
19:06:16 <gribble> https://github.com/bitcoin/bitcoin/issues/20391 | wallet: introduce setfeerate (an improved settxfee, in sat/vB) by jonatack · Pull Request #20391 · bitcoin/bitcoin · GitHub
19:06:34 <wumpus> jonatack: done
19:06:48 <jonatack> thanks (being on the blockers list doesn't attract review)
19:07:11 <michaelfolkson> ariard: Ok. I hope to drive it forward a tiny bit at some point.
19:07:29 <ariard> michaelfolkson: I'll try to transfer in the wiki soon and trakc all related works in this area
19:07:31 <wumpus> jonatack: it helps for some PRs, though not all for sure
19:08:37 <michaelfolkson> ariard: I think everyone would give it a Concept ACK but needs more than that ;)
19:09:07 <wumpus> I didn't look into that one myself because honestly not sure about the logistics of adding another global fee setting command, it seems like something ideally set per transaction
19:09:57 <jonatack> wumpus: it's part of a larger roadmap to migrate to sat/vB
19:10:53 <jonatack> we can't deprecate the feeRate options in BTC/kB as long as settxfee and estimatesmartfee are only in BTC/kB
19:11:00 <wumpus> jonatack: yes it's not specific to your PR, I generally agree with that roadmap, just something I've had a differing opinion about for a long time
19:11:01 <jonatack> but that's ok, no worries
19:11:50 <wumpus> anything else to discuss in regard to high prio?
19:11:52 <aj> re 19160, it needs rebase? also is there any roadmap for libmultiprocessing, it's out of tree, but seems pretty bitcoin specific? has it really been reviewed much?
19:12:42 <dongcarl> #21025 is potentially a pre-req for safely doing 2 other high-prios, but happy to table that till later
19:12:43 <gribble> https://github.com/bitcoin/bitcoin/issues/21025 | validation: Guard the active_chainstate with cs_main by dongcarl · Pull Request #21025 · bitcoin/bitcoin · GitHub
19:12:52 <ariard> aj: it needs rebase since 12 min...
19:12:55 <jonatack> wumpus: the idea is to make hidden/soft-deprecate settxfee and estimatesmartfee in favor of new setfeerate and estimatefeerate rpcs
19:13:03 <wumpus> jonatack: also, introducing a new command with a new name to introduce a new unit , might be a bit overkill
19:13:06 <ariard> but yeah libmultiprocess should be moved under bitcoin-core
19:13:09 <wumpus> jonatack: okay
19:13:10 <ariard> at least
19:13:33 <wumpus> jonatack: I do agree the new names are better
19:13:36 <jonatack> wumpus: i don't see a choice, but TBH i'm happy to close and move on to other things
19:13:45 <jonatack> leave the migration to someone else
19:13:52 <ariard> and yes I had a look on libmultiprocess but ofc needs more review
19:14:01 <jonatack> we need review more than PRs to review
19:14:14 <wumpus> jonatack: well don't let it up to me, it's just my opinion, I'm not going to get in the way
19:14:47 <wumpus> ariard: if it needs more review, adding it to high prio for review makes sense :)
19:15:19 <wumpus> jonatack: what does achow101 think about it?
19:15:30 <sipa> jonatack: i think it's really the only convenient option to get an RPC with sat/vB units, so seems fine to me
19:15:40 <jonatack> achow101 wrote that they should all be in sat/vB
19:16:25 <wumpus> ok ,good
19:16:32 <jonatack> sipa: ok. anyway, no rush. we have lots to do.
19:16:38 <sipa> this is true
19:16:49 <wumpus> absolutely
19:16:59 <wumpus> not many topics for this meeting though, let's go to warren 's
19:17:07 <luke-jr> jonatack: I wouldn't close it tho
19:17:14 <wumpus> #topic Fedora packaging (warren)
19:17:21 <warren> A bit concerning to me is Fedora is again approaching possible packaging and distribution of Bitcoin Core. While the openssl-based risk is now eliminated, I now intend to package Guix for Fedora and use that to make binary identical builds. I think I can handle the Fedora specific parts of this. But Guix for Bitcoin Core releases is still missing a few parts of what Gitian used to do?
19:17:25 <warren> I will not be able to stop them from distributing not-deterministic Bitcoin Core for much longer.
19:17:30 <warren> Maybe TODO List?
19:17:30 <warren> 1) Bitcoin Core switch to Guix for release builds (when possible ... Guix is missing some of the architectures?) I believe we want a replacement for what Gitian used to do including exporting a particular tag from git, naming and versioning the output tarballs, anything else?
19:17:37 <warren> 2) Guix to additionally output .deb and .rpm packages that contain the same binary as the tarball.
19:17:37 <warren> 3) Debian Unstable now ships Guix. Warren is working on figuring out a way to package Guix so it would be acceptable for Fedora where it would be capable of building the above for Fedora/CentOS direct distribution.
19:18:18 <luke-jr> warren: distro packages *shouldn't* be identical to release binaries, but deterministic certainly does seem desirable
19:18:34 <luke-jr> warren: the problems with distro pkgs were discussed at the last meeting regarding Debian (which has chosen to ignore them)
19:18:35 <dongcarl> Status update on Guix from me: all architectures are packaged, codesigning is the main remaining task
19:18:52 <warren> luke-jr: Fedora can't do deterministic with its own build system anytime soon, using Guix there and here is the achievable goal in the short-term.
19:18:59 <achow101> dongcarl: codesigning is easy now
19:19:03 <warren> dongcarl: *all*? amazing!
19:19:11 <luke-jr> warren: sure, that's fine - but they should dynamic link to most libraries
19:19:19 <achow101> codesigning is also unreltaed to linux distros
19:19:29 <dongcarl> right
19:19:46 <warren> luke-jr: I believe that's an opinion not shared by most others?
19:19:58 <luke-jr> warren: dunno, if not, they're wrong ;)
19:20:23 <luke-jr> LevelDB is the one exception that might justify static linking
19:20:25 <wumpus> i'm for 100% static release binaries
19:20:34 <luke-jr> (in distro packages)
19:20:45 <warren> dongcarl: so this soon to be process eliminates gitian? is there something to handle naming and versioning outputs like gitian used to do?
19:21:02 <luke-jr> warren: it can't eliminate gitian..
19:21:04 <dongcarl> warren: The output naming scheme is exactly Gitian's
19:21:10 <warren> dongcarl: can this work entirely offline with provided pre-cached downloads? That's one of the requirements of Fedora's build system
19:21:14 <luke-jr> Guix requires a trusted bootstrap
19:21:37 <sipa> luke-jr: you trust the system you're building on, no?
19:22:02 <luke-jr> sipa: yes, but Guix wants me to trust <random third party binaries>
19:22:19 <dongcarl> luke-jr: Is gitian different?
19:22:28 <MarcoFalke> luke-jr: Just use a vm
19:22:36 <luke-jr> dongcarl: gitian runs all untrusted bins in a VM
19:22:36 <wumpus> guix is an improvement to gitian in that regard, that's all
19:22:40 <luke-jr> MarcoFalke: that's what gitian is for ;)
19:22:42 <wumpus> you can run guix in a vm
19:22:48 <luke-jr> Guix *within* gitian is an improvement
19:22:49 <wumpus> you can run guix in gitian even
19:22:51 <wumpus> :-)
19:22:53 <luke-jr> Guix *without* gitian is a regression
19:23:01 <wumpus> well that's entirely up to you
19:23:08 <wumpus> guix doesn't care what you run it in
19:23:10 <wumpus> that's thepoint
19:23:13 <warren> dongcarl: can this new glorious gitianless future work entirely offline with provided pre-cached downloads? That's one of the requirements of Fedora's build system
19:23:13 <MarcoFalke> luke-jr: You are free to use guix in gitian, but you can't force everyone else to do the same
19:23:25 <warren> MarcoFalke: +1
19:24:04 <achow101> I agree with luke-jr for a different reason. I think gitian is an easier way to onboard new gitian builders, and existing gitian builders don't need to change anything for guix. So we should still have gitian descriptors that do the guix builds. People who want guix locally can do that too. It should all be the same.
19:24:07 <dongcarl> warren: Yes, I believe it's designed to do so. I will double-check
19:24:25 <warren> achow101: that's fine
19:24:39 <sipa> achow101: yeah, i'd expect we'll just change the gitian descriptors to be thin wrappers around guix
19:24:44 <sipa> but no reason they can't remain
19:24:45 <warren> if people find it more convenient to use it that way
19:24:55 <luke-jr> sipa: +1
19:24:59 <wumpus> mind that gitian is effectively unmaintained
19:25:02 <MarcoFalke> achow101: guix is included in debian, so it will be in Ubuntu soon. I don't see how another wrapper makes things easier
19:25:29 <achow101> MarcoFalke: I already have gitian setup and can't be bothered to figure out gitian :p
19:25:39 <achow101> * figure out guix
19:25:47 <luke-jr> MarcoFalke: we should not be asking people to run third-party binaries on their system to build releases
19:26:04 <MarcoFalke> luke-jr: Then they should be using a vm
19:26:06 <wumpus> and it has some long-running issues, like the inability to upgrade base images leading to very long setup+build times
19:26:10 <luke-jr> MarcoFalke: yes
19:26:32 <MarcoFalke> luke-jr: The gitian guide starts by telling people how to install the vm, so nothing changes
19:26:32 <luke-jr> wumpus: gitian's last merge was only a month ago, hardly unmaintained..
19:26:33 <dongcarl> Is the main benefit here just a convenience script for running guix in a VM, or that people are used to the Gitian workflow?
19:26:40 <wumpus> then again, i'm tired of this discussion every time, if you want to use gitian then do...
19:27:08 <wumpus> i don't think it should be the default recommendation or 'a good way to onboard new builders'
19:27:15 <sipa> gitian does a few things that guix doesn't, i assume (like the creation of assert files, signing, verifying them)?
19:27:21 <wumpus> just make guix easy to use please
19:27:33 <wumpus> sipa: there is no reason why the guix wrapper couldn't do that
19:27:41 <sipa> wumpus: of course
19:27:52 <dongcarl> making guix easy to use is very much my goal
19:28:03 <wumpus> generating assert files is quite easy, signing them is done by gnupg
19:28:08 <wumpus> dongcarl: right!
19:28:35 <wumpus> and verifying them can be done without gitian now, e.g. see the gitian-verify.py script in maintainer-tools
19:28:41 <sipa> ok!
19:28:42 <warren> luke-jr: you can bootstrap guix yourself, why are you calling it untrusted?
19:28:50 <luke-jr> warren: no, I cannot
19:28:56 <luke-jr> warren: I spent hours trying and couldn't get anywhere
19:29:02 <MarcoFalke> warren: What is the policy for packages that are EOL? What is the policy for packages that went from fedora->stream->rhel?
19:29:08 <wumpus> I mean the whole point is that guix relies on a smaller trusted base than gitian
19:29:32 <warren> MarcoFalke: i need to ask what is possible from Fedora Engineering Steering Committee. I have a few things in mind like:
19:29:33 <aj> MarcoFalke: bitcoin's not going in stream/rhel, surely
19:29:36 <wumpus> gitian installs an *ubuntu* VM, it has lots of cruft
19:29:59 <luke-jr> wumpus: Guix is a smaller trusted base than Ubuntu, but larger than gitian for the host end
19:30:00 <warren> 1) Before a distro goes EOL the bitcoincore package is replaced with a final update that removes the binary.
19:30:27 <warren> 2) Build system CI could verify that the binary is reproducible and matches some URL upstream.
19:30:36 <wumpus> luke-jr: otoh if the guix trusted base is compromised so will the bitcoin core binaries
19:30:42 <luke-jr> warren: how about automatic upgrades and softforks? both deploying and not deploying the softfork are problematic without user consent
19:30:45 <sipa> wumpus: i think luke-jr's concern is about the risk that guix is malicious and say install malware in his host system; not about trusting the result of the build
19:30:49 <wumpus> luke-jr: it's kind of important
19:30:55 <wumpus> same for ubuntu right now, btw
19:30:56 <MarcoFalke> aj: shoudn't or can't?
19:30:58 <dongcarl> is here but is a bit overwhelmed by the convo
19:31:09 <warren> luke-jr: why are you blindly trusting Ubuntu right now?
19:31:19 <wumpus> one compromised package in ubuntu and our binaries can be compromised
19:31:26 <aj> MarcoFalke: won't / isn't a rhel priority so doesn't make sense?
19:31:27 <wumpus> this is kind of scary
19:31:27 <warren> hands dongcarl a calming Tribble.
19:31:35 <luke-jr> wumpus: yes, but we already have that problem
19:31:40 <sipa> googles Tribble
19:31:52 <wumpus> luke-jr: it is mitigated by guix
19:31:55 <luke-jr> (with Ubuntu)
19:31:58 <MarcoFalke> aj: Oh, I assumed they just take all packages from fedora
19:32:36 <wumpus> because guix has a smaller trusted base, sure, it still has some binaries for bootstrapping, n one really solved the trusting-trust attacks yet, we can only slowly improve things
19:32:47 <luke-jr> wumpus: the ideal solution would be a way to bootstrap Guix without the third-party binary blobs
19:32:58 <warren> luke-jr does have a legitimate question about automatic upgrades. It is upstream's policy to not force users into automatic upgrades. If you install a distro package you opt-in to that.
19:33:00 <wumpus> luke-jr: i'm sure that's possible
19:33:21 <warren> There is a way however for users to opt-out of automatic distro upgrades.
19:33:23 <wumpus> guix is fully open source right? why couldn't you bootstrap it from an existing system?
19:33:37 <wumpus> givn that you have compilers and such of course
19:33:53 <warren> well that's one way to win the debate
19:33:55 <achow101> wumpus: from my experience, there are some usability hurdles that can make setting up guix really frustrating
19:34:12 <wumpus> achow101: well then we need to solve them
19:34:13 <aj> warren: nah, he got too close to telling the truth, so the powers that be deplatformed him
19:34:25 <wumpus> i don't see why that's an argument in favor of wrapping guix in ubuntu forever
19:34:32 <sipa> it isn't
19:34:34 <warren> achow101: people downloading a guix VM is no worse than people blindly trusting Ubuntu in current gitian.
19:34:54 <dongcarl> I'm happy to solve all of the usability problems in setting up Guix, that was an explicit goal from the beginning. To make it easier to use.
19:35:00 <sipa> yay.
19:35:13 <aj> dongcarl: <3
19:35:38 <dongcarl> Bootstrapping Guix from source is not the most user-friendly, but the UX problems are being solved, and the recent debian packaging outlines a for-sure way to bootstrap it from a system
19:35:42 <MarcoFalke> warren: Also, who would maintain the fedora package?
19:35:43 <warren> There is a way however for users to opt-out of automatic distro upgrades. The .rpm distributed by bitcoincore.org would be identical to the package distributed by Fedora except the Epoch number is higher. That way the Fedora package will never be seen as "newer". It retains the property desired by Bitcoin Core project that nobody is forced into automatic upgrades.
19:36:05 <warren> MarcoFalke: me, and everyone, because I intend it to be identical to bitcoincore.org's guix generated .rpm
19:36:17 <wumpus> fwiw gitian is also not the most user friendly, it helps that there's guides for it everywhere now, but it took ages for people to start using it
19:36:45 <dongcarl> I'm sure that the debian packaging rules/formula can be ported to other distros, such as Gentoo, so that people on those distros can stay within their trusted base and boostrap Guix
19:36:46 <sipa> i don't even invoke anything gitian related directly, all within perhaps several layers of wrapper scripts
19:37:33 <wumpus> in a way it's just a matter of getting used to a new way of working, i don't think we need to wait for guix to be 100% user friendly all over the board until we can start using it for release builds
19:38:08 <jonatack> this ^
19:38:08 <warren> gitian is already not user friendly, it's been mostly broken for me for a few years now.
19:38:23 <sipa> agree
19:38:27 <wumpus> warren: exactly my point, gitian was never easy to use or set up
19:38:30 <achow101> true
19:38:54 <dongcarl> I am also happy to offer my time to 1. Help anyone with their setup 2. Document UX hiccups 3. Fix them so that others don't experience them
19:38:55 <wumpus> it's just fairly well documented now, that will happen for guix too i'm sure when we start using it
19:39:00 <MarcoFalke> Are we aiming to ship guix packages for the next release?
19:39:05 <warren> If people want easy to use guix they can download a VM. That isn't worse than the current blind trust on Ubuntu used within gitian.
19:39:22 <wumpus> warren: at least you have more flexibility in what VM then!
19:39:44 <sipa> dongcarl: how realistic do you think it is to replace all release binaries for 22.0 with guix-built ones?
19:39:52 <wumpus> it doesn't need to be ubuntu anymore, can be debian, or even a guix-as-a-distro VM
19:40:17 <jonatack> warren: we've onboarded a dozen or so new gitian signers the past 6 months, by (a) making it a bit easier to get started and (b) communicating a bit more about doing it to people
19:40:31 <jonatack> i'm sure can do the same with guix
19:40:48 <dongcarl> sipa, MarcoFalke: The missing steps before we ship 22 with guix are: codesigning, assert-file tooling, UX/non-UX debugging and testing
19:40:51 <warren> How difficult are the remaining things needed to switch to guix/
19:40:52 <warren> ?
19:41:14 <MarcoFalke> dongcarl: Would those be easier if the gitian setup was used?
19:41:28 <dongcarl> I don't expect codesigning and assert-file tooling to be too difficult, but I don't want to make any promises w/re UX/non-UX debugging and testing
19:41:34 <MarcoFalke> I.e. replace the gitian build script with a guix build script, but still call gitian
19:41:55 <dongcarl> MarcoFalke: No, I believe using the gitian setup will probably be much more difficult
19:42:03 <warren> dongcarl: fedora builds have things neat thing where .rpm contains stripped binaries, but unstripped go into an optional -debuginfo package. gdb is smart enough to look at the debuginfo if you debug. Does guix have anything like that?
19:42:09 <dongcarl> s/much more/a bit/
19:42:24 <wumpus> there's still 4.5 months left before the 22.0 feature freeze
19:42:48 <warren> Could we do a practice release using guix of 0.21?
19:42:52 <MarcoFalke> If we switch, I'd prefer to do it at least two months before freeze
19:43:09 <warren> 0.21.x
19:43:21 <sipa> dongcarl: what do you mean with "UX/non-UX debugging" ?
19:43:21 <wumpus> nack on wrapping guix in gitian, i really don't want to do a build like that
19:43:27 <warren> wumpus: +1
19:43:41 <wumpus> this almost doubles the trusted base
19:44:11 <dongcarl> Okay, I've been deep in the libbitcoin_kernel work as of late. But let me reload my stack, explore the scope, and get back to you all with my rough timeline expectations next week. Does that sound alright?
19:44:21 <wumpus> dongcarl: thanks!
19:44:37 <warren> How difficult is it to write the remaining tooling needed to switch releases to guix? If we don't know the answer right now can we have a TODO list by next meeting?
19:45:34 <wumpus> how can we help?
19:45:39 <dongcarl> sipa: UX debugging would be going through the process to see which parts are non-intuitive and hard to use. non-UX debugging would entail testing the build output result more thoroughly
19:46:12 <warren> dongcarl: isn't that the same problem we have with the gitian release process?
19:46:16 <warren> not a new problem
19:46:19 <sipa> dongcarl: i'd expect the former can be alleviated by just writing documentation
19:46:36 <sipa> and perhaps in later steps make it more user friendly, so less needs to be documented
19:46:36 <MarcoFalke> do we need any assert-file tooling?
19:46:47 <dongcarl> furiously typing
19:46:56 <MarcoFalke> As I understand the assert-file will list the installed ubuntu packages, but we no longer use that
19:47:13 <wumpus> what would a guix assert file even look like? just a list of hashes of the release files? or would you want to include more?
19:47:25 <wumpus> MarcoFalke: right, that
19:47:36 <achow101> shoudl the assert file even try to look like gitian's?
19:47:49 <wumpus> achow101: no reason it needs to
19:47:56 <MarcoFalke> so a sha256sum with a wildcard would generate the "assert file"?
19:47:57 <achow101> I would expect the guix assert file would be everything installed in guix
19:48:00 <sipa> if it's not guix-in-gitian, i see no reason why the assert file needs to be anything similar
19:48:04 <dongcarl> You're right, it doesn't need to.
19:48:13 <wumpus> it's fine with me if the assert file loks like SHA256SUMS.asc
19:48:30 <luke-jr> kicks ISP
19:48:34 <sipa> it's nice if it also commits to the exact source code it was built from
19:48:56 <dongcarl> Here's the way fanquake and I have been verifying our outputs: https://github.com/bitcoin/bitcoin/pull/17920#issuecomment-765109583
19:48:57 <wumpus> sipa: true!
19:49:14 <dongcarl> Literally a one-liner
19:49:17 <wumpus> ideally it could commit to the inputs as well as the outputs
19:49:34 <dongcarl> Since that one-liner includes src/bitcoin-f1694757ddbc.tar.gz, it does commit to the bitcoin source
19:49:37 <luke-jr> it would be nice if as a result from this, we can dump everyone's signatures into the SHA256SUMS.asc file on the website
19:49:53 <MarcoFalke> dongcarl: Is the commit included when building tags?
19:50:15 <dongcarl> MarcoFalke: Sorry, not entirely sure what you mean here
19:50:26 <wumpus> luke-jr: that was my thinking as well
19:50:39 <dongcarl> luke-jr: That would be nice! I'll make a note of that
19:50:46 <MarcoFalke> when building a tag, the archive looks like `bitcoin-22.0.tar.gz`, not `bitcoin-fffffff.targ.gz`
19:51:01 <wumpus> everyone would be signing the same data so you could combine the signatures
19:51:13 <luke-jr> I wrote a blog post about verifying gitian sigs - it was way more complex than I'd like
19:51:30 <dongcarl> MarcoFalke: Yes, I believe I made sure of that some time ago, will re-check for you!
19:51:59 <wumpus> luke-jr: have you seen https://github.com/bitcoin-core/bitcoin-maintainer-tools#gitian-verify ? it makes things much easier
19:52:10 <wumpus> (e.g. tabulates the result)
19:52:29 <luke-jr> wumpus: that assumes the end user already has it ;)
19:52:39 <MarcoFalke> Though, since guix only works from git, including the commit hash in the "assert file" shouldn't be too hard
19:52:45 <wumpus> luke-jr: already has what?
19:52:57 <luke-jr> wumpus: a trusted Bitcoin Core source repo
19:53:28 <luke-jr> or rather, the maintainer tools repo
19:53:42 <wumpus> well okay sure, if you want to do it all manually
19:53:47 <wumpus> that's definitely a lot of work
19:53:57 <luke-jr> wget https://luke.dashjr.org/programs/bitcoin/files/bitcoind/0.21.0/SHA256SUMS.asc && gpg --verify SHA256SUMS.asc
19:53:59 <luke-jr> is a lot less
19:54:15 <luke-jr> (sha256sum -c too I guess)
19:54:46 <wumpus> i mean, sure, but that still assumes someone has all the gpg keys received and installed, but yeah
19:55:11 <wumpus> any other topics?
19:55:13 <warren> Question ... since 0.22 is months away could we aim to do a practice release on 0.21.x?
19:55:23 <luke-jr> WOT issues are unavoidable and not going away XD
19:55:45 <wumpus> warren: i would prefer to start using guix only in a major release
19:55:46 <MarcoFalke> wumpus: My topic was 0.20.2 :)
19:56:05 <warren> wumpus: not official for 0.21.x, but in parallel
19:56:19 <sipa> warren: or just master?
19:56:21 <warren> wumpus: partly because I need it to calm down the Fedora packagers
19:56:22 <MarcoFalke> warren: I think we can also practice on master
19:56:23 <sipa> why backport?
19:56:24 <wumpus> it's too big a change to backport, and besides, it needs the more extensive rc cycle of a major release
19:56:37 <warren> hmm
19:56:42 <wumpus> yes, practicing can be done fine on master
19:56:54 <warren> I'll live with that.
19:56:58 <sipa> or, on the guix PR branch, as long as it's not merged
19:56:59 <dongcarl> I'd be happy to practice with anyone and take notes :-)
19:57:02 <wumpus> #topic 0.20.2 (MarcoFalke)
19:57:14 <MarcoFalke> Basically asking if anything is left to do there
19:57:30 <MarcoFalke> and whether to do an rc and upload binaries
19:57:31 <wumpus> no idea, haven't kept track
19:58:44 <MarcoFalke> the rc1 was never released?
19:58:46 <luke-jr> MarcoFalke: I did end up finding a bug in the 0.19 bump
19:58:56 <luke-jr> sorry I missed the rcs
19:59:03 <MarcoFalke> luke-jr: huh?
19:59:12 <luke-jr> digs it out to see if it's relevant to 0.20
19:59:45 <wumpus> I think it would be good if someone took over the back-releases from me, i do not have the capacity to handle that, definitely not so many at the same time
20:00:03 <luke-jr> I thought MarcoFalke was?
20:00:20 <MarcoFalke> I create the backports
20:00:22 <wumpus> yes, he effectively does
20:00:29 <wumpus> already
20:00:40 <MarcoFalke> Haven't run any of the release stuff scripts
20:00:43 <luke-jr> MarcoFalke: aha, it was a libevent dep for just bitcoin-tx builds
20:01:09 <luke-jr> I think it was fixed before 0.20
20:01:40 <luke-jr> so n/a for 0.20.2, and 0.19 will probably be dead before there's a chance to do another
20:02:52 <wumpus> #endmeeting