< ja>
wumpus: i propose adding a README.txt in the secure 0.9.5 directory that says "The compiled binaries of this release are vulnerable to CVE-X, but the source release is unaffected. Before compilation, make sure you have a libupnp release with version at least Y. See other 0.9.5 directory for the vulnerable binaries."
< wumpus>
that would definitely work, for release notes a brief description is generally apt
< wumpus>
though the important thing is to describe the activation mechanism i think
< harding>
I can write something tomorrow.
< harding>
(But re using stuff from Optech, please feel free anytime. Everything there is MIT licensed.)
< harding>
I think we'd want to descibe a little bit about what taproot is for anyone who hasn't been paying attention do dev, what users need to do for activation, and what miners need to do for activation.
< harding>
Alos mention that ST can fail and, if it does, that doesn't mean we're done with taproot.
< wumpus>
yes that would be perfect
< harding>
I'll get something up on the devwiki by this time tommorrow and will post a link here for others to review and edit.
< wumpus>
and good to know stuff from optech is freely licensed i don't think i realized that
< wumpus>
for now i'm going to send an announcement mail with just the change list
< MarcoFalke>
fanquake: Ist there a way for git to properly display the permission change?
< MarcoFalke>
For me it just shows the change in a white color (like the file name), so my brain skips it
< bitcoin-git>
[bitcoin] theStack opened pull request #21728: remove executable flag for src/net_processing.cpp (master...2021-remove-exec-flag-from-net_processing) https://github.com/bitcoin/bitcoin/pull/21728
< wumpus>
there is only a very limited number of files that should have execute permission
< sipa>
.sh files, perhaps some .py ones?
< wumpus>
"scripts that have a hash-bang" i guess
< wumpus>
we would never check in an actual binary
< MarcoFalke>
./contrib/guix/guix-clean doesn't have an extension, but a bang
< wumpus>
yea i commented on that when it was renamed, the idea behind having no extension was that it doesn't have to be renamed again when porting to python, but it does make things harder in this regard :-)
< Arvidt>
I have a Bitcoin binary download script that determines the latest version by parsing the output of 'wget -q -O - https://bitcoin.org/bin/' but there is no subfolder bitcoin-core-0.21.1/ in the output, while when I open https://bitcoin.org/bin/ with Firefox, the 0.21.1 subfolder is shown? Before I never had problems with my script. Also tried wget with --no-cache, but that did not help.
< Arvidt>
With the above wget command the output I get is
< harding>
Arvidt: I don't see a 0.21.1 folder on bitcoin.org/bin/ ; are you sure you're seeing it? In any case, the preferred location to get the binaries is from https://bitcoincore.org/bin/
< bitcoin-git>
bitcoin/master 4e06133 Hennadii Stepanov: qt: Elide long strings in their middle in the Peers tab
< bitcoin-git>
bitcoin/master 13d27b4 Hennadii Stepanov: Merge bitcoin-core/gui#276: Elide long strings in their middle in the Peer...
< Arvidt>
I changed the hostname in my script from bitcoin.org to bitcoincore.org now it is working again. And the download speed is very fast now that's fine
< promag>
who knows the correct doxygen format as of today?
< hebasto>
kindly asking ppl who is interested in improving translation process to look into #21694
< gribble>
https://github.com/bitcoin/bitcoin/issues/21694 | build: Use XLIFF file to provide more context to Transifex translators by hebasto · Pull Request #21694 · bitcoin/bitcoin · GitHub
< midnight>
ls
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #21731: Update msvc build to use Qt5.12.10 binaries. (master...msvc_qt5.12.10) https://github.com/bitcoin/bitcoin/pull/21731
< ja>
how can i know, on transifex, the progress of my submitted translation, and whether i had incorrectly translated anything?
< hebasto>
ja: for v22 the Transifex translation will be opened on 2021-06-01 and merged into the code base during the release process
< harding>
Disclosure, the "development history overview" set of links points to things almost all written by me. I've been told by others that they think it's a particularly useful resource, but please anyone feel free to remove it if you think its's inappropriate.
< ja>
harding: i dunno if this is deliberately omitted but wouldn't it be good to have a estimated time of the lock-in block?
< ja>
if a single estimated value cannot put, because it would lead some people to think it is exact, maybe it would be helpful to point to some resource that lets people estimate, or which explains the distribution. like e.g. http://r6.ca/blog/20180225T160548Z.html
< belcher>
harding might be worth mentioning batch validation as a benefit of taproot too
< harding>
ja: oh, I thought that was in there; maybe I deleted it from an earlier draft. I do agree it would be good.
< harding>
belcher: I'll try to work that in if I can keep it short. Thanks!