< dongcarl>
In the meeting on the 14th, people asked jamesob and me to take a look at potential AssumeUTXO and chainman-deglobalization conflicts and if a certain merge order is preferable. Here is the result: https://github.com/bitcoin/bitcoin/pull/19806#issuecomment-768673523
< dongcarl>
The conclusion was that the PRs are mergeable in any order without much pain if the last commit of the AssumeUTXO changes in #19806 is slightly modified
< bitcoin-git>
[gui] jonasschnelli merged pull request #177: Use "fusion" style on macOS Big Sur with old Qt (master...210107-style) https://github.com/bitcoin-core/gui/pull/177
< bitcoin-git>
bitcoin/master 4e1154d Hennadii Stepanov: qt: Use "fusion" style on macOS Big Sur with old Qt
< bitcoin-git>
bitcoin/master 02b0165 Jonas Schnelli: Merge bitcoin-core/gui#177: Use "fusion" style on macOS Big Sur with old Q...
< bitcoin-git>
[gui] jonasschnelli merged pull request #72: util: Log static plugins meta data and used style (master...200812-log) https://github.com/bitcoin-core/gui/pull/72
< bitcoin-git>
bitcoin/master b695148 Hennadii Stepanov: qt: Add flags to prevent a "What's This" button on Windows OS
< bitcoin-git>
bitcoin/master ac7ccd6 Hennadii Stepanov: scripted-diff: Remove unused "What's This" button in dialogs on Windows
< bitcoin-git>
bitcoin/master 68692d3 Jonas Schnelli: Merge bitcoin-core/gui#85: Remove unused "What's This" button in dialogs o...
< bitcoin-git>
[gui] jonasschnelli merged pull request #85: Remove unused "What's This" button in dialogs on Windows OS (master...200907-whatsit) https://github.com/bitcoin-core/gui/pull/85
< jnewbery>
It's actually impossible to load the hidden review comments in #20749. Whenever I hit the "Load more..." button it instantly fails. Looking at network capture I'm getting a 400 bad request when trying to load the extra comments.
< wumpus>
jnewbery: that's been my experience as well
< fanquake_>
wumpus: lol. yea we certainly aren't about to start a Tor fork..
< wumpus>
jnewbery: it's starting to look like the API is the only way to use github anymore, the website adds less and less
< wumpus>
(this is really bad for a mostly web based product)
< wumpus>
fanquake_: right eh
< fanquake_>
jnewbery: I reported a similar issue to GitHub on the 30th of October last year. It got a reply a week later, which was basically "can't reproduce"
< fanquake_>
Can anyone else confirm that hitting load more in #20749 doesn't work ?
< wumpus>
prayank: to be clear i would be happy if someone picked up Dandelion again, and was able to resolve the DoS issues, it has a limited an realistic enough scope, transaction broadcast
< wumpus>
fanquake_: same now
< jnewbery>
jonatack: thanks for the gh cli tip. Do you know if there's any way to also load the inline code review comments?
< wumpus>
i was able to load them yesterday
< fanquake_>
wumpus: great. Just wanted to triple check before posting heh
< jnewbery>
I'm just seeing the top level PR review comments
< wumpus>
so: currently no—it seems to less of an implementation issue but more of a matter of failing to agree on what would be a usable command line interface to this
< wumpus>
prayank: i keep being surprised how actually-helpful the bitcoin stackexchange is
< prayank>
wumpus: Not sure if I should comment on this but it's been helpful sometimes and for few things I had to ask questions on r/bitcoin and other places.
< michaelfolkson>
prayank: I think you forget about the questions you get answered and just focus on those that don't. Never going to get close to 100 percent success rate
< prayank>
lol maybe
< michaelfolkson>
Given it is completely voluntary it is very impressive the people that dedicate time to it
< wumpus>
prayank: then i see a reddit thread and am shocked how full of distractive trolls and nonsense it is, though it definitely has it's good threads too, but the stack exchange is just so serious and people seem to really take their time to type explanations and such that are on-point
< wumpus>
michaelfolkson: exactly
< prayank>
wumpus: Agree both have their own positives. Maybe I am just overthinking about few issues and hate the options available to "close" questions on Stackexchange.
< michaelfolkson>
If you didn't have the moderator features you'd get the Reddit style "full of distractive trolls and nonsense"
< michaelfolkson>
Moderation is never perfect but it is generally pretty high quality imo
< wumpus>
michaelfolkson: it's kind of defined by that, yes
< wumpus>
prayank: anyhow yeah if you write down what the specific issues are (and what you're trying to do) others might be able to help you out, fwiw there are a fair bit of dandelion-specific threads on the stack exchange too
< wumpus>
you're far from the only person looking into this
< wumpus>
oh yes, rebasing the work on recent source code is going to be a challenge in itself
< wumpus>
i think to do that you need to first understand every change, then see how it applies to master, git's source-context-based suggestions quickly become completely useless
< prayank>
michaelfolkson: Thanks. I had seen someone doing ACKs on individual commits so thought we can do it.
< michaelfolkson>
I guess if you only review one commit (or a subset of commits) then you could refer to them. But if you review all of them just ACK that head commit
< wumpus>
you *can* ACK invidual commits, but that's generally if you have a special reason to
< wumpus>
right
< prayank>
wumpus: Yes. Trying to understand every change and there are lot of changes.
< wumpus>
prayank: maybe as first pass, try to sort out which are the most important ones :)
< wumpus>
there's alwasys ancillary things like refactors that were needed at the time to bring things into posistion which might no longer be needed, or needed completely differently
< prayank>
Thanks. Will try and share the progress in few days.
< bitcoin-git>
bitcoin/master fad3d76 MarcoFalke: fuzz: Avoid initializing version to less than MIN_PEER_PROTO_VERSION
< bitcoin-git>
bitcoin/master 4d5eaf7 MarcoFalke: Merge #20995: fuzz: Avoid initializing version to less than MIN_PEER_PROTO...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20995: fuzz: Avoid initializing version to less than MIN_PEER_PROTO_VERSION (master...2101-fuzzVersion0) https://github.com/bitcoin/bitcoin/pull/20995
< bitcoin-git>
[bitcoin] fanquake opened pull request #21022: [Not for merge] pthread sanity check (master...broken_shared_mutex_sanity_check) https://github.com/bitcoin/bitcoin/pull/21022
< MarcoFalke>
dongcarl: I think we still need some kind of centralized entity
< MarcoFalke>
I can't imagine our workflow when half the devs don't see half the pull requests
< MarcoFalke>
(You can only see the ones you "follow", according to the docs, haven't tried myself)
< dongcarl>
Right, that is the current behaviour but I can see how they can introduce "remote rebroadcasting" to solve this. Surely other projects will want the same thing.
< luke-jr>
MarcoFalke: at least half the devs already ignore half the PRs I suspect :P
< MarcoFalke>
Also, radicle doesn't work with the normal browser
< luke-jr>
but yes, it's probably important new devs get visibility
< MarcoFalke>
you need to download their own software to browse
< MarcoFalke>
luke-jr: Most new devs remove the word "experimental", so it would be good if no one could see those anymore. Though, rarely someone has an actual bug fix.
< MarcoFalke>
Same goes for issues
< wumpus>
dongcarl: the mirror should update every 15 minutes
< wumpus>
dongcarl: issues and PRs haven't been implemented in the frontend yet, unfortunately, this kind of limits its usefulness at the moment
< dongcarl>
Oh of course right now it's full of problems and is in alpha, I'm just thinking about a list of things still missing from radicle that perhaps can be advocated for.
< ariard>
it sounds finally to attract reviewers :)
< 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?
< aj>
hi-ish (laggy)
< jonatack>
hi
< wumpus>
ariard: added
< ariard>
thanks!
< wumpus>
12 blockers now! anything to add/remove or that's ready for merge?
< michaelfolkson>
Your #19820 is still chasing Concept ACK ariard. Keep it there or remove?
< jonatack>
thanks (being on the blockers list doesn't attract review)
< michaelfolkson>
ariard: Ok. I hope to drive it forward a tiny bit at some point.
< ariard>
michaelfolkson: I'll try to transfer in the wiki soon and trakc all related works in this area
< wumpus>
jonatack: it helps for some PRs, though not all for sure
< michaelfolkson>
ariard: I think everyone would give it a Concept ACK but needs more than that ;)
< 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
< jonatack>
wumpus: it's part of a larger roadmap to migrate to sat/vB
< jonatack>
we can't deprecate the feeRate options in BTC/kB as long as settxfee and estimatesmartfee are only in BTC/kB
< 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
< jonatack>
but that's ok, no worries
< wumpus>
anything else to discuss in regard to high prio?
< 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?
< dongcarl>
#21025 is potentially a pre-req for safely doing 2 other high-prios, but happy to table that till later
< jonatack>
wumpus: the idea is to make hidden/soft-deprecate settxfee and estimatesmartfee in favor of new setfeerate and estimatefeerate rpcs
< wumpus>
jonatack: also, introducing a new command with a new name to introduce a new unit , might be a bit overkill
< ariard>
but yeah libmultiprocess should be moved under bitcoin-core
< wumpus>
jonatack: okay
< ariard>
at least
< wumpus>
jonatack: I do agree the new names are better
< jonatack>
wumpus: i don't see a choice, but TBH i'm happy to close and move on to other things
< jonatack>
leave the migration to someone else
< ariard>
and yes I had a look on libmultiprocess but ofc needs more review
< jonatack>
we need review more than PRs to review
< wumpus>
jonatack: well don't let it up to me, it's just my opinion, I'm not going to get in the way
< wumpus>
ariard: if it needs more review, adding it to high prio for review makes sense :)
< wumpus>
jonatack: what does achow101 think about it?
< sipa>
jonatack: i think it's really the only convenient option to get an RPC with sat/vB units, so seems fine to me
< jonatack>
achow101 wrote that they should all be in sat/vB
< wumpus>
ok ,good
< jonatack>
sipa: ok. anyway, no rush. we have lots to do.
< sipa>
this is true
< wumpus>
absolutely
< wumpus>
not many topics for this meeting though, let's go to warren 's
< luke-jr>
jonatack: I wouldn't close it tho
< wumpus>
#topic Fedora packaging (warren)
< 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?
< warren>
I will not be able to stop them from distributing not-deterministic Bitcoin Core for much longer.
< warren>
Maybe TODO List?
< 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?
< warren>
2) Guix to additionally output .deb and .rpm packages that contain the same binary as the tarball.
< 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.
< luke-jr>
warren: distro packages *shouldn't* be identical to release binaries, but deterministic certainly does seem desirable
< luke-jr>
warren: the problems with distro pkgs were discussed at the last meeting regarding Debian (which has chosen to ignore them)
< dongcarl>
Status update on Guix from me: all architectures are packaged, codesigning is the main remaining task
< 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.
< achow101>
dongcarl: codesigning is easy now
< warren>
dongcarl: *all*? amazing!
< luke-jr>
warren: sure, that's fine - but they should dynamic link to most libraries
< achow101>
codesigning is also unreltaed to linux distros
< dongcarl>
right
< warren>
luke-jr: I believe that's an opinion not shared by most others?
< luke-jr>
warren: dunno, if not, they're wrong ;)
< luke-jr>
LevelDB is the one exception that might justify static linking
< wumpus>
i'm for 100% static release binaries
< luke-jr>
(in distro packages)
< warren>
dongcarl: so this soon to be process eliminates gitian? is there something to handle naming and versioning outputs like gitian used to do?
< luke-jr>
warren: it can't eliminate gitian..
< dongcarl>
warren: The output naming scheme is exactly Gitian's
< warren>
dongcarl: can this work entirely offline with provided pre-cached downloads? That's one of the requirements of Fedora's build system
< luke-jr>
Guix requires a trusted bootstrap
< sipa>
luke-jr: you trust the system you're building on, no?
< luke-jr>
sipa: yes, but Guix wants me to trust <random third party binaries>
< dongcarl>
luke-jr: Is gitian different?
< MarcoFalke>
luke-jr: Just use a vm
< luke-jr>
dongcarl: gitian runs all untrusted bins in a VM
< wumpus>
guix is an improvement to gitian in that regard, that's all
< luke-jr>
MarcoFalke: that's what gitian is for ;)
< wumpus>
you can run guix in a vm
< luke-jr>
Guix *within* gitian is an improvement
< wumpus>
you can run guix in gitian even
< wumpus>
:-)
< luke-jr>
Guix *without* gitian is a regression
< wumpus>
well that's entirely up to you
< wumpus>
guix doesn't care what you run it in
< wumpus>
that's thepoint
< 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
< MarcoFalke>
luke-jr: You are free to use guix in gitian, but you can't force everyone else to do the same
< warren>
MarcoFalke: +1
< 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.
< dongcarl>
warren: Yes, I believe it's designed to do so. I will double-check
< warren>
achow101: that's fine
< sipa>
achow101: yeah, i'd expect we'll just change the gitian descriptors to be thin wrappers around guix
< sipa>
but no reason they can't remain
< warren>
if people find it more convenient to use it that way
< luke-jr>
sipa: +1
< wumpus>
mind that gitian is effectively unmaintained
< MarcoFalke>
achow101: guix is included in debian, so it will be in Ubuntu soon. I don't see how another wrapper makes things easier
< achow101>
MarcoFalke: I already have gitian setup and can't be bothered to figure out gitian :p
< achow101>
* figure out guix
< luke-jr>
MarcoFalke: we should not be asking people to run third-party binaries on their system to build releases
< MarcoFalke>
luke-jr: Then they should be using a vm
< wumpus>
and it has some long-running issues, like the inability to upgrade base images leading to very long setup+build times
< luke-jr>
MarcoFalke: yes
< MarcoFalke>
luke-jr: The gitian guide starts by telling people how to install the vm, so nothing changes
< luke-jr>
wumpus: gitian's last merge was only a month ago, hardly unmaintained..
< 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?
< wumpus>
then again, i'm tired of this discussion every time, if you want to use gitian then do...
< wumpus>
i don't think it should be the default recommendation or 'a good way to onboard new builders'
< sipa>
gitian does a few things that guix doesn't, i assume (like the creation of assert files, signing, verifying them)?
< wumpus>
just make guix easy to use please
< wumpus>
sipa: there is no reason why the guix wrapper couldn't do that
< sipa>
wumpus: of course
< dongcarl>
making guix easy to use is very much my goal
< wumpus>
generating assert files is quite easy, signing them is done by gnupg
< wumpus>
dongcarl: right!
< wumpus>
and verifying them can be done without gitian now, e.g. see the gitian-verify.py script in maintainer-tools
< sipa>
ok!
< warren>
luke-jr: you can bootstrap guix yourself, why are you calling it untrusted?
< luke-jr>
warren: no, I cannot
< luke-jr>
warren: I spent hours trying and couldn't get anywhere
< MarcoFalke>
warren: What is the policy for packages that are EOL? What is the policy for packages that went from fedora->stream->rhel?
< wumpus>
I mean the whole point is that guix relies on a smaller trusted base than gitian
< warren>
MarcoFalke: i need to ask what is possible from Fedora Engineering Steering Committee. I have a few things in mind like:
< aj>
MarcoFalke: bitcoin's not going in stream/rhel, surely
< wumpus>
gitian installs an *ubuntu* VM, it has lots of cruft
< luke-jr>
wumpus: Guix is a smaller trusted base than Ubuntu, but larger than gitian for the host end
< warren>
1) Before a distro goes EOL the bitcoincore package is replaced with a final update that removes the binary.
< warren>
2) Build system CI could verify that the binary is reproducible and matches some URL upstream.
< wumpus>
luke-jr: otoh if the guix trusted base is compromised so will the bitcoin core binaries
< luke-jr>
warren: how about automatic upgrades and softforks? both deploying and not deploying the softfork are problematic without user consent
< 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
< wumpus>
luke-jr: it's kind of important
< wumpus>
same for ubuntu right now, btw
< MarcoFalke>
aj: shoudn't or can't?
< * dongcarl>
is here but is a bit overwhelmed by the convo
< warren>
luke-jr: why are you blindly trusting Ubuntu right now?
< wumpus>
one compromised package in ubuntu and our binaries can be compromised
< aj>
MarcoFalke: won't / isn't a rhel priority so doesn't make sense?
< wumpus>
this is kind of scary
< * warren>
hands dongcarl a calming Tribble.
< luke-jr>
wumpus: yes, but we already have that problem
< * sipa>
googles Tribble
< wumpus>
luke-jr: it is mitigated by guix
< luke-jr>
(with Ubuntu)
< MarcoFalke>
aj: Oh, I assumed they just take all packages from fedora
< 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
< luke-jr>
wumpus: the ideal solution would be a way to bootstrap Guix without the third-party binary blobs
< 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.
< wumpus>
luke-jr: i'm sure that's possible
< warren>
There is a way however for users to opt-out of automatic distro upgrades.
< wumpus>
guix is fully open source right? why couldn't you bootstrap it from an existing system?
< wumpus>
givn that you have compilers and such of course
< warren>
well that's one way to win the debate
< achow101>
wumpus: from my experience, there are some usability hurdles that can make setting up guix really frustrating
< wumpus>
achow101: well then we need to solve them
< aj>
warren: nah, he got too close to telling the truth, so the powers that be deplatformed him
< wumpus>
i don't see why that's an argument in favor of wrapping guix in ubuntu forever
< sipa>
it isn't
< warren>
achow101: people downloading a guix VM is no worse than people blindly trusting Ubuntu in current gitian.
< 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.
< sipa>
yay.
< aj>
dongcarl: <3
< 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
< MarcoFalke>
warren: Also, who would maintain the fedora package?
< 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.
< warren>
MarcoFalke: me, and everyone, because I intend it to be identical to bitcoincore.org's guix generated .rpm
< 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
< 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
< sipa>
i don't even invoke anything gitian related directly, all within perhaps several layers of wrapper scripts
< 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
< jonatack>
this ^
< warren>
gitian is already not user friendly, it's been mostly broken for me for a few years now.
< sipa>
agree
< wumpus>
warren: exactly my point, gitian was never easy to use or set up
< achow101>
true
< 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
< wumpus>
it's just fairly well documented now, that will happen for guix too i'm sure when we start using it
< MarcoFalke>
Are we aiming to ship guix packages for the next release?
< 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.
< wumpus>
warren: at least you have more flexibility in what VM then!
< sipa>
dongcarl: how realistic do you think it is to replace all release binaries for 22.0 with guix-built ones?
< wumpus>
it doesn't need to be ubuntu anymore, can be debian, or even a guix-as-a-distro VM
< 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
< jonatack>
i'm sure can do the same with guix
< dongcarl>
sipa, MarcoFalke: The missing steps before we ship 22 with guix are: codesigning, assert-file tooling, UX/non-UX debugging and testing
< warren>
How difficult are the remaining things needed to switch to guix/
< warren>
?
< MarcoFalke>
dongcarl: Would those be easier if the gitian setup was used?
< 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
< MarcoFalke>
I.e. replace the gitian build script with a guix build script, but still call gitian
< dongcarl>
MarcoFalke: No, I believe using the gitian setup will probably be much more difficult
< 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?
< dongcarl>
s/much more/a bit/
< wumpus>
there's still 4.5 months left before the 22.0 feature freeze
< warren>
Could we do a practice release using guix of 0.21?
< MarcoFalke>
If we switch, I'd prefer to do it at least two months before freeze
< warren>
0.21.x
< sipa>
dongcarl: what do you mean with "UX/non-UX debugging" ?
< wumpus>
nack on wrapping guix in gitian, i really don't want to do a build like that
< warren>
wumpus: +1
< wumpus>
this almost doubles the trusted base
< 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?
< wumpus>
dongcarl: thanks!
< 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?
< wumpus>
how can we help?
< 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
< warren>
dongcarl: isn't that the same problem we have with the gitian release process?
< warren>
not a new problem
< sipa>
dongcarl: i'd expect the former can be alleviated by just writing documentation
< sipa>
and perhaps in later steps make it more user friendly, so less needs to be documented
< MarcoFalke>
do we need any assert-file tooling?
< * dongcarl>
furiously typing
< MarcoFalke>
As I understand the assert-file will list the installed ubuntu packages, but we no longer use that
< 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?
< wumpus>
MarcoFalke: right, that
< achow101>
shoudl the assert file even try to look like gitian's?
< wumpus>
achow101: no reason it needs to
< MarcoFalke>
so a sha256sum with a wildcard would generate the "assert file"?
< achow101>
I would expect the guix assert file would be everything installed in guix
< sipa>
if it's not guix-in-gitian, i see no reason why the assert file needs to be anything similar
< dongcarl>
You're right, it doesn't need to.
< wumpus>
it's fine with me if the assert file loks like SHA256SUMS.asc
< * luke-jr>
kicks ISP
< sipa>
it's nice if it also commits to the exact source code it was built from
< wumpus>
i mean, sure, but that still assumes someone has all the gpg keys received and installed, but yeah
< wumpus>
any other topics?
< warren>
Question ... since 0.22 is months away could we aim to do a practice release on 0.21.x?
< luke-jr>
WOT issues are unavoidable and not going away XD
< wumpus>
warren: i would prefer to start using guix only in a major release
< MarcoFalke>
wumpus: My topic was 0.20.2 :)
< warren>
wumpus: not official for 0.21.x, but in parallel
< sipa>
warren: or just master?
< warren>
wumpus: partly because I need it to calm down the Fedora packagers
< MarcoFalke>
warren: I think we can also practice on master
< sipa>
why backport?
< wumpus>
it's too big a change to backport, and besides, it needs the more extensive rc cycle of a major release
< warren>
hmm
< wumpus>
yes, practicing can be done fine on master
< warren>
I'll live with that.
< sipa>
or, on the guix PR branch, as long as it's not merged
< dongcarl>
I'd be happy to practice with anyone and take notes :-)
< wumpus>
#topic 0.20.2 (MarcoFalke)
< MarcoFalke>
Basically asking if anything is left to do there
< MarcoFalke>
and whether to do an rc and upload binaries
< wumpus>
no idea, haven't kept track
< MarcoFalke>
the rc1 was never released?
< luke-jr>
MarcoFalke: I did end up finding a bug in the 0.19 bump
< luke-jr>
sorry I missed the rcs
< MarcoFalke>
luke-jr: huh?
< * luke-jr>
digs it out to see if it's relevant to 0.20
< 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
< luke-jr>
I thought MarcoFalke was?
< MarcoFalke>
I create the backports
< wumpus>
yes, he effectively does
< wumpus>
already
< MarcoFalke>
Haven't run any of the release stuff scripts
< luke-jr>
MarcoFalke: aha, it was a libevent dep for just bitcoin-tx builds
< luke-jr>
I think it was fixed before 0.20
< luke-jr>
so n/a for 0.20.2, and 0.19 will probably be dead before there's a chance to do another
< wumpus>
#endmeeting
< MarcoFalke>
luke-jr: 0.19 won't get any gitian binaries published, as I understood it
< luke-jr>
? this is when building from source
< wumpus>
feel free to open a PR against the 0.19 branch to fix it then
< sipa>
luke-jr: can i have a BIP number for bip-bech32m? (there are a few other things in the bips repo that want your attention too, i think)
< luke-jr>
sipa: I guess use 350
< sipa>
luke-jr: thanks!
< bitcoin-git>
[bitcoin] laanwj opened pull request #21026: doc: Document use of make-tag script to make tags (master...2021-01-make-tag) https://github.com/bitcoin/bitcoin/pull/21026
< wumpus>
^^ might be useful if anyone else is to have a go at making releases
< achow101>
is it possible to remove a task from CScheduler or maybe pause one?
< wumpus>
doesn't seem like it
< sipsorcery>
MarcoFalke: Did you change anything on the appveyor config? Or did one job just magically work again?
< dongcarl>
For those following along the assumeutxo/chainman-deglobalizing work, please take a look at this very short PR which aims to remove the m_active_chainstate r/w footgun: #21025
< dongcarl>
This is a prerequisite to having both work be safe, and I hope is simple enough to get in relatively quickly to unblock the two high-prio PRs