when will 0.20.1 be released? (sorry if it was answered earlier i wasnt able to follow)
belcher: do you mean 0.21.1? (0.20.1 was released months ago).
the node which has ST
I haven't heard any issues in regards to the rc1. Likely be discussed in the meeting tomorrow. If we bump to final after that, then a day or two for gitian builds, and 0.21.1 could be released just after that.
fanquake: only issues i've seen are code signing ones
[bitcoin] practicalswift opened pull request #21795: fuzz: Terminate immediately if a fuzzing input ever causes a DNS lookup (belts and suspenders) (master...fuzz-terminate-on-dns-lookup) https://github.com/bitcoin/bitcoin/pull/21795
I've been meaning to test whether this bug I encountered is fixed in GCC 10.3, but in any cases, libsecp256k1 now has its own definition of memcmp that it uses.
sipa: there is some evidence that it isn't present in glibc since glibc isn't amoung the libraries profiled that emitted an warning with real_or_random's bug profiling enabled: http://r6.ca/blog/20200929T023701Z.html
BTW, I've been left with the impression that it shouldn't be hard to write a Nix expression to produce the same binaries that Guix produces. Someday I'd like to give it a try. It would be cool to have two different build systems producing the same binaries.
though it would only take a single wrinke to cause a problem.
Less vaguely: say you introduce a new function. Where do the unit tests go?
roconnor: You can do a 'reflections on trusting trust'. If guix produces a gcc with compile flags X set, all you need is to create a *functioning* gcc, compile another gcc with compile flags X set, and then use that gcc to compile itself. So any eventual errors are self-correcting.
in case if TR ST would fail to activate, what is the time limit by which TR overall should activate using some other mechanism that would be attempted after the (hopefully avoidable) ST failure?