< cfields> gitian builders: detached sigs for v0.18.1 are up.
< fanquake> 🎉
< bitcoin-git> [bitcoin] kallewoof opened pull request #16566: util: refactor upper/lowercase functions (master...2019-08-casefuns-refactor) https://github.com/bitcoin/bitcoin/pull/16566
< fanquake> Pushed up some signed sigs: https://github.com/bitcoin-core/gitian.sigs/pull/1065
< ariard> cfields: hey if you are around and have time, could you have a look on https://github.com/bitcoin/bitcoin/pull/16503 :) ? People are uncertain on it
< fanquake> promag: I've put together a AppleScript that spams wallet loads and unloads in the GUI: https://github.com/bitcoin/bitcoin/issues/16307#issuecomment-519355809
< fanquake> You might be able to use that to recreate the issue.
< jonasschnelli> promag: Re #16562: do you mean reallocation because of the vector::insert at the beginning? Yeah. I need to look for a better way.
< gribble> https://github.com/bitcoin/bitcoin/issues/16562 | Refactor message transport packaging by jonasschnelli · Pull Request #16562 · bitcoin/bitcoin · GitHub
< jonasschnelli> heh
< setpill> what is the recommended way to cleanly shut down bitcoind running in the background?
< setpill> seems like sending sigterm does an unclean shutdown
< belcher> setpill this is a question more for #bitcoin than here, but try running `bitcoin-cli stop`
< setpill> belcher: it's related to the default systemd service file of bitcoin core not shutting it down cleanly when using `systemctl stop bitcoind.service`
< setpill> hm it might also be a timeout issue
< setpill> ie. systemd going for the sigkill before the db has been flushed to disk
< jonasschnelli> Unfortunate that our current ChaCha20Poly1305@Bitcoin implementation works on a single buffer.
< jonasschnelli> Makes it harder to avoid vector::insert's / possible relocations
< jonasschnelli> Ideally the AEAD would work on three buffers, 1| the "header" (3 byte packet length a.k.a. AD + command), 2| the message payload, 3| the 16byte MAC tag
< provoostenator> setpill: that would be useful to know; I imagine that can cause serious problems for low end devices, e.g. some raspebbery pi that needs to reboot after a system update
< provoostenator> I use more or less the default systemd example one of my own machines and haven't had issues with unclean shutdowns that I know, but I never stress tested that.
< setpill> provoostenator: it depends on how big your dbcache is and how much syncing you have done since the last time bitcoind was started
< setpill> I just tried `bitcoin-cli stop` (rather than `systemctl stop bitcoind.service`) and it took almost 9 minutes.
< setpill> But that's with a node that had synced non-stop from ~block 500000
< setpill> And with a 15GB dbcache
< setpill> I think setting `TimeoutStopSec=infinity` in the bitcoind.service file should fix it properly (though you'll want to be cognizant that shutdown of your device might take ages)
< setpill> Will make a PR
< provoostenator> That seems reasonable at first glance, but I'm no systemd expert. I assume reboot will run out of patience?
< setpill> Not sure about that, good question.
< provoostenator> Is it possible to "fail" the stop, instead waiting forever?
< setpill> Well that's what it does now, I guess.
< provoostenator> At least it makes sense to ask for the user to intervene if the node doesn't gracefully stop.
< setpill> Simply sigkills.
< setpill> It's possible to disable the sigkill at end of timeout.
< setpill> But imho that's worse because it doesn't properly restart the service.
< provoostenator> No that's not what I mean. I mean "systemctl stop bitcoind" could return an error without doing sigkill, basically "I can't stop this process"
< setpill> Ie. `systemctl restart bitcoind.service` is a `stop` followed by a `start`
< setpill> If the `stop` timeouts without successfully stopping the service, it will not perform the `start`
< setpill> Which might be worse than the restart happening 10 minutes later than you'd expect, but still as soon as possible.
< provoostenator> From the docs: "If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=…", this may cause the stop time to be extended"
< wumpus> SIGTERM and SIGHUP do a clean shutdown
< wumpus> @setpill
< setpill> wumpus: thanks for the confirmation :)
< wumpus> sorry, SIGTERM and SIGINT
< setpill> provoostenator: that might *also* be an option yes. I will open an issue about this so these points can be recorded for later reference
< provoostenator> If we wanted to switching from type "forking" to type "notify" that involves changes in the code to use sd_notify. Systemd docs seem to prefer that.
< setpill> Just feels conceptually "wrong" to let the shutdown timeout when it's still hard at work and has not frozen at all.
< provoostenator> setpill: that sounds like the right ticket to update
< bitcoin-git> [bitcoin] setpill opened pull request #16569: Disable systemd stop timeout (master...fix-systemd-shutdown) https://github.com/bitcoin/bitcoin/pull/16569
< bitcoin-git> [bitcoin] davereikher opened pull request #16570: Make descriptor tests deterministic (master...make_descriptor_tests_deterministic) https://github.com/bitcoin/bitcoin/pull/16570
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16571: gui: Make Bitcoin Core logo pure black (master...1908-guiIcoPureBlack) https://github.com/bitcoin/bitcoin/pull/16571
< MarcoFalke> #proposedmeetingtopic Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak?
< luke-jr> I tried to make a flatpak but couldn't get it to work :/
< elichai2> I added the control block to the `SignatureData` struct, and I'm filling it in `ProduceSignature`(right now it's greedy and takes the first script that it can sign for) but for the signing support itself i'll wait for achow101's native descriptors PR :) until then i'll rebase my psbt stuff to use the new descriptor
< dongcarl> Wondering anyone had thoughts on a generic feature-signaling message for non-monotonic features that don't fit in the protocol version model
< dongcarl> Has there been prior art?
< sipa> BIP 36 perhaps
< sipa> long ago
< dongcarl> Was there any reason why this wasn't adopted? Or just no one implemented?
< achow101> maybe it will be better than travis?
< dongcarl> #proposedmeetingtopic [maybe short] generic feature-signaling message for non-monotonic features that don't fit in the protocol version model (like BIP 36)
< sipa> FWIW, i think the "sendX" type negotiation works pretty well
< dongcarl> sipa: works pretty well = overhead + the extra message types not that big of a deal?
< sipa> they're sent exactly once
< dongcarl> true... okay perhaps this isn't that big of a problem.
< * dongcarl> wishes there were a #cancelproposedmeetingtopic
< MarcoFalke> Thanks
< MarcoFalke> :eyes:
< sipa> i'd be concerned about centralizing more of our workflow around github, if we'd move from travis to the built-in CI...
< MarcoFalke> travis only works with GitHub, so I fail to see how it would make anything worse
< jonasschnelli> I'm also concerned to add more crucial stuff around github
< MarcoFalke> If it is the same thing with the only difference that we don't have to manually re-run every build, I'd consider it a huge win
< jonasschnelli> Well,.. don't forget the https://bitcoinbuilds.org/ option. :)
< jonasschnelli> But I agree that travis, with github only is not much of a difference
< MarcoFalke> jonasschnelli: It needs some sort of integration with GitHub
< jonasschnelli> BTW: semaphore2 has now public PR build support
< jonasschnelli> MarcoFalke: I can integrate it with GitHub's "checks" API.
< jonasschnelli> Done in 1-2 days...
< jonasschnelli> But I first want to prove that my CI can run for 2-3 month without issues
< sipa> i think a self-hosted CI is over time going to be a better solution anyway
< jonasschnelli> Then a next integration step could be done
< MarcoFalke> jonasschnelli: Also, it needs to be open to the public (forked repos)
< MarcoFalke> And offer free minutes for open source
< jonasschnelli> MarcoFalke: it won't
< jonasschnelli> The CI will only build PRs and master branch (eventually older branches as well at some point)
< achow101> MarcoFalke: so long as a config file that can be used elsewhere is present, I don't see a problem with also using bitcoinbuilds.org
< achow101> Why not just have both?
< MarcoFalke> How would I run all the ci settings when my workstation is a laptop? Create a pull request against core?
< jonasschnelli> MarcoFalke: the bitcoinbuilds.org CI is our last check. How developers check their work is their thing
< jonasschnelli> (prior to PR)
< achow101> jonasschnelli: it's nice to be able to run the CI checks on your own branch before a PR
< sipa> meeting?
< MarcoFalke> It takes a long time to compile and run the tests with all possible sanitizer options and configure options
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 8 19:01:03 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< moneyball> hi
< kanzure> hi
< jnewbery> hi
< jonasschnelli> hi
< MarcoFalke> hi
< achow101> hi
< ariard> hi
< sipa> hi
< phantomcircuit> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
< wumpus> hi
< fanquake> Hi
< real_or_random> hi
< meshcollider> hi
< MarcoFalke> I'd rather stick with some GitHub specific stuff that works than to ditch GitHub specific stuff and make running the tests harder for developers
< wumpus> any last-minute proposed topics?
< aj> hey
< wumpus> there's one by MarcoFalke: Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak
< dongcarl> wumpus: could you remove my proposed?
< wumpus> dongcarl: moneyball already did
< MarcoFalke> We can always keep the bitcoin-builds as a backup fallback ci
< phantomcircuit> MarcoFalke, it really depends on how powerful their build servers are, for a relatively small price a very powerful server could be acquired and used for builds
< MarcoFalke> #proposedmeetingtopic GitHub ci
< wumpus> #topic High priority for review
< MarcoFalke> phantomcircuit: Not every developer has a credit card, even if they can afford the price of the ci
< achow101> I don't see why we can't just use both. would it not be possible to make bitcoinbuilds just read the same config file as github's?
< wumpus> 6 blockers, 6 chasing concept ACKs
< wumpus> why are we talking about credit cards ?
< MarcoFalke> Agree with achow101
< jonasschnelli> (lets take the CI discussion to #bitcoin-builds plz)
< MarcoFalke> wumpus: Sorry, will shut up now about ci
< wumpus> I think the BIP9 bury PR is very near merge-ready
< wumpus> #16060
< gribble> https://github.com/bitcoin/bitcoin/issues/16060 | Bury bip9 deployments by jnewbery · Pull Request #16060 · bitcoin/bitcoin · GitHub
< wumpus> anything to add/remove/replace from the project?
< MarcoFalke> It is still in the process of review and some fixups keep getting found
< MarcoFalke> (re 16060)
< wumpus> MarcoFalke: mostly small nits on nits about RPC behavior, from what I've seen
< aj> #8994 can be removed from chasing concept ack?
< gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
< phantomcircuit> MarcoFalke, no what im saying is that we could collectively buy a server that could do the builds, in general things where you're buying "packaged" cpu time from third parties end up being very expensive
< jnewbery> wumpus: there was at least a bug in the test case which I'm fixing now
< jnewbery> I would appreciate rereview after I push that fix
< wumpus> jnewbery: sure
< MarcoFalke> jnewbery: Will take another look in the next couple of days
< MarcoFalke> Also, I plan to review sdaftuar's pr (it has been on my list for a while, but I haven't gotten to it yet)
< wumpus> thanks
< fanquake> wumpus: first topic?
< wumpus> we're done with high priority for review?
< * jonasschnelli> waves at #16202 (quick review, on the path to p2p encryption)
< gribble> https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub
< wumpus> #topic Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak (MarcoFalke)
< achow101> who currently maintains it?
< jonasschnelli> can someone explain flatpak?
< MarcoFalke> It isn't created yet
< MarcoFalke> jonasschnelli: It is like a snap package
< wumpus> it's a distribution agnostic binary package distribution format
< MarcoFalke> Different name, though
< wumpus> for linux
< jonasschnelli> Okay. Sounds acceptable.
< wumpus> it's especially good for GUI applications, it has some features like sandboxing and desktop UI integration which simply dropping static binaries has not
< MarcoFalke> I will be a repository hosted under the flatpak org, so not in our org. Which is why I am asking for co-maintainers.
< wumpus> see #16550
< gribble> https://github.com/bitcoin/bitcoin/issues/16550 | Distribute via flatpak · Issue #16550 · bitcoin/bitcoin · GitHub
< wumpus> i'd love to help but can't promise to have any time and motivation for any extra work at the moment, sorry
< MarcoFalke> Sure. Maybe jonasschnelli?
< MarcoFalke> Or fanquake?
< sipa> it seems flatpak is also usable independent of a central repo
< sipa> while snap really needs canonical's infrastructure?
< MarcoFalke> jup, snap needs the Ubuntu infrastructure
< fanquake> MarcoFalke: what’s required to maintain? Just uploading releases and managing issues?
< sipa> flatpak has flathub, but it's not required
< MarcoFalke> fanquake: Only requirement is that you are a less agressive jaywalker
< sipa> (just reading and learning)
< fanquake> 👀
< jonasschnelli> Sorry... already at my timelimit
< sipa> MarcoFalke: one must know how to spell aggressive correctly, however
< MarcoFalke> right
< fanquake> Can’t promise anything 🏃‍♂️
< MarcoFalke> Is there an autocorrect for IRC?
< MarcoFalke> fanquake: Cool, I'll sign you up.
< wumpus> hehe,switch to matrix, it has message editing
< fanquake> MarcoFalke: heh, I was worried that just by asking a question that would happen
< fanquake> wumpus: Next topic then?
< wumpus> #topic GitHub ci (MarcoFalke)
< MarcoFalke> I.e. bump version every 3 months
< MarcoFalke> So nothing too fancy
< MarcoFalke> ok, next topic
< fanquake> MarcoFalke: ok 👍
< MarcoFalke> I think everyone knows by now that travis isn't the most stable ci solution
< wumpus> PSA: first deadline (soft translation string freeze) for 0.19.0 is in less than a month, 2019-09-01
< MarcoFalke> So in exploring alternatives, the GitHub ci might be a good medium-term replacement
< wumpus> MarcoFalke: definitely, it's not a good fit for how we're using it at least
< moneyball> MarcoFalke: is the GitHub CI public info?
< MarcoFalke> Both, travis and the GitHub ci, will be GitHub-centered. That should be fine, imo.
< moneyball> ah, i see it is
< achow101> they just announced it today, it's in beta
< wumpus> I've never heard of github ci
< MarcoFalke> moneyball: Yes, according to achow101
< moneyball> when Pieter, Cory, Matt, and I visited GitHub, they demo'd this
< wumpus> but if it can take over what travis does and does it beter, without too much work from our side, that'd be very useful
< moneyball> cfields has strong views on this
< MarcoFalke> wumpus: Jup, agree
< achow101> moneyball: any opinions about it from the demo you saw?
< MarcoFalke> moneyball: cfields: Elaborate, pls
< wumpus> cfields can't be here today afaik
< jnewbery> moneyball: can you summarise the strong feelings?
< fanquake> Also agree.
< achow101> strong feelings in a good or bad way?
< sipa> bad.
< moneyball> Concerns about increasing dependence on GitHub/Microsoft
< jonasschnelli> Yes
< MarcoFalke> Again, I don't think it gets worse. Also, we can use jonasschnelli's ci as a fallback (running in the background 24/7)
< fanquake> jonasschnelli: do you want to update on the state of your CI? As an alternative?
< moneyball> Which I agree is a valid point. My response was "What kind of productivity improvement over Travis would we need to see to want to move in that direction?" but I didn't really get a good answer. So, I'd pose that question here.
< jonasschnelli> Update on the self hosted custom open source CI (bitcoinbuilds.org): it does now (since a week) successfully builds all PRs, mostly quicker than travis (though less envs). Integration with Github is doable and easy. But first lets see how it runs for at least 2 months.
< jonasschnelli> Plan is to use the Github checks API when we think it has been proven to be reliable (2 month)
< wumpus> moneyball: "no false positives"
< moneyball> Another point made was concern that GitHub 3rd party API might suffer / degrade over time making 3rd party tools like Travis even worse (relative to GitHub CI)
< wumpus> (or at least, neglible amount of, the problem with travis is false positives)
< sipa> one point is that it seems to provide far more entry points than a normal CI does (it does much more automation of workflows, not just CI), and starting to depend on those seems like it would make it harder to move away (if ever needed)
< jonasschnelli> good point
< MarcoFalke> Yeah, good point.
< wumpus> I wouldn't want to rely on it for automation of workflows
< fanquake> Heh. We’ve already got plenty of GH “turned off” as well.
< moneyball> I'm not sure if their announcement today means anyway can experiment with it not, but if not, then we have an invitation to experiment with it, if anyone is interested.
< wumpus> just taking over what travis does now
< jonasschnelli> They tend to mix auto-fix (code format correction and stuff) with CI which is indeed not only good
< sipa> as long as it's a drop-in replacement of one CI for another, i agree there isn't much impact
< MarcoFalke> We should only use it for the purpose of ci builds
< wumpus> auto-fix ? no way
< MarcoFalke> " You’re in the queue for the beta—we’ll let you know as soon as you have access. "
< wumpus> that sounds realllllly scary
< wumpus> damn
< sipa> that's just an example of something you can configure
< sipa> not a default thing
< MarcoFalke> yes, all of the other stuff is just scary
< wumpus> so now you CI doesn't only have false positives, it can introduce bugs and backdoors into your code !
< MarcoFalke> Like self-driving cars for software development
< wumpus> yea, lt's disable it, as fanquake says we have plenty of gh features disabled, what is one more … though it's something to watch
< wumpus> yes, exactly
< luke-jr> jonasschnelli: we've "tested" other CIs live - no reason not to do it with our own
< fanquake> So is the resolution here to just wait until we can look at GH CI properly? Maybe test it in production alongside Travis?
< wumpus> that sounds good to me
< jonasschnelli> ack
< achow101> ack
< luke-jr> Does GH CI work with non-GH repos?
< MarcoFalke> no
< achow101> luke-jr: i highly doubt it
< wumpus> luke-jr: only if you mirror them to github, I guess
< sipa> luke-jr: embrace, extend, ...
< luke-jr> I'm with cfields on that then…
< MarcoFalke> luke-jr: Does travis work with non-GH repos?
< luke-jr> I mean, if it's the only thing working, fine temporarily I guess, but I'd rather get away from GH dependency, not more entrenched
< wumpus> luke-jr: definitely agree on that
< luke-jr> MarcoFalke: not sure
< achow101> I really thing we should just do both GH CI and bitcoinbuilds and just have them use the same config file
< jonasschnelli> It looks like GitHub is taking over Git the same way gmail took over email... be aware
< moneyball> does anyone want to test the GitHub CI now? let me know and I will introduce
< luke-jr> achow101: +1
< luke-jr> I wonder how long until there's some kind of standard for CIs
< jonasschnelli> Nice centralized development functionality comes at a price
< achow101> so we aren't entirely dependent on Github, but for individual developers, they can still run CI checks
< sipa> achow101: i like that idea; it also forces us to keep the configuration to be compatible with non-GH features
< wumpus> luke-jr: seems no, travis cannot use anything else than github, unless you have the enterprise version
< luke-jr> moneyball: does it require permission to use?
< aj> jonasschnelli: could test in production, but have it report "success" or "neutral" rather than "success" or "failure" maybe?
< sipa> luke-jr: during the beta, yes
< luke-jr> achow101: "make cichecks" would be nice :D
< achow101> luke-jr: can't run on all of the platforms on one machine
< luke-jr> achow101: why not? :\
< dongcarl> qemu
< jonasschnelli> aj: Yes. That would make sense.
< dongcarl> so, perhaps _someone_ should try out the GitHub CI, and see if it's better than Travis, as a stop gap
< wumpus> dongcarl: from my testing a few years ago, qemu-user works pretty well for the tests, at least if you stick to platforms with the same endianness
< luke-jr> it sounds like bitcoinbuilds is further along than GitHub CI?
< MarcoFalke> Could someone share a writeup of how to run the functional tests in qemu, pls?
< luke-jr> MarcoFalke: write a shell script that runs the bitcoind bin, and export BITCOIND=/path/to/script
< achow101> moneyball: you said we have an invitation to experiment with github CI?
< moneyball> Yes
< achow101> can we skip the queue?
< moneyball> Presumably since they offered to let us use it a month ago
< dongcarl> Is there a zero-effort Travis yml -> GH CI transition?
< sipa> i doubt that
< MarcoFalke> dongcarl: no
< dongcarl> :-/
< dongcarl> Why not stick to Travis till bitcoinbuilds is ready?
< MarcoFalke> But the travis.yml mostly specifies the env, so it shouldn't be too hard either
< achow101> dongcarl: because travis false positives too much
< luke-jr> yeah, I imagine at least some of the scripts should be portable
< MarcoFalke> I'd still like to run a ci with free minutes along of bitcoinbuilds
< jonasschnelli> Me 2
< luke-jr> "free minutes along of bitcoinbuilds"?
< achow101> moneyball: can you ask them let some of us into the beta so we can try it out on our own repos first?
< MarcoFalke> fee cpu time
< jonasschnelli> I think centralized development tools are fine as long as there is an alternative running in parallel
< MarcoFalke> *free
< luke-jr> ah
< luke-jr> I have lots of free ppc64le CPU time I think
< jonasschnelli> The problem is lock-in, suddenly they charge for it or make it incompatible with your needs, ...and you'r screwed
< dongcarl> jonasschnelli: Agreed.
< moneyball> achow101: yes would you like access?
< achow101> sure
< phantomcircuit> achow101, travis is mostly hitting fp on resource exhaustion issues
< luke-jr> moneyball: they can't just enable the entire repo +forks? :/
< moneyball> i don't know
< sipa> yeah, let's ask them how this works
< moneyball> i will clarify with them
< achow101> just enable it for anyone in the bitcoin and bitcoin-core orgs :)
< MarcoFalke> Let's not enable the repo for now and keep testing in forks only
< jonasschnelli> I'd also hope we consider some ethos and not further extend our reliance on github
< wumpus> jonasschnelli: I agree, it's just, if we don't rely on anything further then switching from travis to github for CI doesn't make a difference, they're both centralized and githyb only
< fanquake> wumpus: any other topics?
< wumpus> nope
< jonasschnelli> wumpus: There is maybe no technical difference,... but the signal to the community/world is different
< MarcoFalke> Ok, that is a point I buy. They might say the GitHub ci is "approved by Bitcoin Core"
< wumpus> Could someone share a writeup of how to run the functional tests in qemu <- I'll try if I get around to it, I think the most difficult part is setting up the faux-root filesystem for the target, though on some distros you can install that as package
< wumpus> MarcoFalke: yes, that's scary
< jonasschnelli> "Bitcoin Core implemente GitHub CI after talks with their CEO,... a week after they acted in massive censorship"
< jonasschnelli> (I know I overstretch it)
< fanquake> Then we’d all have to jump on Medium and explain our actions in an emoji filled post mortem.
< luke-jr> might be a harder story to spin if we have our own CI at the same time
< achow101> we could deploy both github CI and bitcoinbuilds simultaneously?
< wumpus> haha way to go, fly ahead of the rumors in the meeting 😅
< luke-jr> "We're migrating to our own CI, but helping GitHub test theirs too"
< MarcoFalke> I'll experiment with the ci a bit in the coming days to see if it fits our use case. We can discuss more after everyone had a look
< jonasschnelli> thanks MarcoFalke
< achow101> +1
< wumpus> yes, let's try that, maybe it's worse a match for our CI needs than travis is, then it's not even worth discussing further
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 8 19:45:46 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< * fanquake> back to sleep
< jamesob> sorry I missed the meeting - can I get #16443 thrown on the high prio list?
< gribble> https://github.com/bitcoin/bitcoin/issues/16443 | refactor: have CCoins* data managed under CChainState by jamesob · Pull Request #16443 · bitcoin/bitcoin · GitHub
< wumpus> jamesob: sure
< jamesob> thanks wumpus
< wumpus> HUH did anyone know you can add notes to the project pages?
< wumpus> this could be useful to add some information, like who proposed a blocker
< wumpus> (if it's not the author)
< jamesob> ah that's kind of cool - are the notes themselves separate from the PRs?
< wumpus> yes they're simply cards like the PRs and issues but aren't actually PRs and issues
< MarcoFalke> I forgot to raise the topic, but what happened to 0.18.1? can we ship tomorrow?
< wumpus> so can be used as sub-headers and such
< aj> oh, if you put the issue number in a note it includes the issue summary info too
< wumpus> MarcoFalke: the signatures are uploaded now, I'll upload the binaries shortly
< aj> ... if you have exactly one issue number, anyway
< bitcoin-git> [bitcoin] JeremyRubin opened pull request #16572: Fix Char as Bool in Wallet (master...fix-wallet-charbool) https://github.com/bitcoin/bitcoin/pull/16572