< aj>
sipa: you mistyped "No, you're wrong, here's the full explanation dumbass: ___"
< sipa>
oh, silly me.
< AdulrunaRedviva>
good morning
< AdulrunaRedviva>
I have many addresses in my wallet. and I want to pay with the address I chose. So I want to choose the address I will send to?
< jonasschnelli>
AdulrunaRedviva -> head over to #bitcoin (this is the development channel)
< vasild>
hmm, it just occured to me (after staring at some fuzzing failure) that some CNetAddr objects do not ser+deser into the original. For example a torv3 address when serialized (as done by the fuzzer, ADDRV2_FORMAT is not set) end up with 16 zeroes.
< vasild>
When 16 zeroes are deserialized the result is not equal to the torv3 address.
< wumpus>
that's expected, right?
< vasild>
What about extending AssertEqualAfterSerializeDeserialize() so that when called with CNetAddr it also uses ADDRV2_FORMAT.
< vasild>
wumpus: exactlty, that is expected
< vasild>
... but not expected by the fuzzer :-D
< wumpus>
could do that; there would need to be some exception there, the fuzzer shouldn't generate, do this test on objects that are not valid to be serialized in the target representation
< AdulrunaRedviva>
I will have another important question. Is there anyone to answer?
< vasild>
wumpus: yeah, something like that
< jonasschnelli>
AdulrunaRedviva: please go to the channel #bitcoin
< vasild>
AdulrunaRedviva: this is the development channel, do you have any suggestions on the above fuzzing issue?
< wumpus>
it looks like it is a harmless detail of how .plt is handled on POWER64: in the ELF binary it's part of the LOAD program header with 'RW ' permissions (not 'R E'), something else like the dynamic linker or program initialization code needs to mprotect it to 'R E' after loading, before it can be used
< bitcoin-git>
[bitcoin] gwillen closed pull request #20264: test: Make secp tests optional in `make check` (master...feature-optional-secp-check) https://github.com/bitcoin/bitcoin/pull/20264
< real_or_random>
and no need to give write permissions to the code
< real_or_random>
just linux for now but they offer windows and mac os for money.
< real_or_random>
(money is not a big issue) but I was surprised that my builds on the free plan get scheduled immediately. it's just limited to one build at a time
< sdaftuar>
anyone have workarounds for github not properly expanding comments that are hidden? in my case, someone left comments on a PR and marked as resolved, but i can't expand to see them (#20187)
< gribble>
https://github.com/bitcoin/bitcoin/issues/20187 | Addrman: test-before-evict bugfix and improvements for block-relay-only peers by sdaftuar · Pull Request #20187 · bitcoin/bitcoin · GitHub
< hebasto>
sdaftuar: search for that comment in email notification, and open it via emailed link
< sdaftuar>
thanks, i think that may have worked (slightly confusing but i believe github duplicated the comment on their website, as part of someone else's review and in-thread with an earlier review comment - ugh)
< fanquake>
sdaftuar: if you can be bothered documenting any exmaples, please pass them on to me, and pass them through to GH
< fanquake>
Although they don't seem too concerned about any of the issues we've raised so far
< sdaftuar>
fanquake: sure, not sure what documentation is helpful exactly but the last "show resolved" on https://github.com/bitcoin/bitcoin/pull/20187 is failing to expand for me, just get the spinny github logo
< sdaftuar>
under ariard's review
< sdaftuar>
would be curious to know if it loads for you!
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20271: doc: Document that wallet salvage is experimental (master...2010-docWalletSalvage) https://github.com/bitcoin/bitcoin/pull/20271
< fanquake>
sdaftuar: heh nice. It doesn't load for me issue.
< fanquake>
*either
< fanquake>
I'll open another issue about things continuing to not load
< ariard>
at least on my side, but I can't load it on the main PR thread
< sdaftuar>
ariard: got it, thanks for confirming that -- it did load for me as well higher up on the page (threaded with other comments on same chunk of code)
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #20273: Extend support for nested commands to bitcoin-cli (master...2020/10/client_rpc_nested) https://github.com/bitcoin/bitcoin/pull/20273
< vasild>
hebasto: "Is -Wthread-safety-negative on by default in Clang 12 for you?" -- I am not sure how to check that.
< vasild>
Definitely it is not present explicitly in the compilation commands
< hebasto>
me neither :)
< hebasto>
does `-Wno-thread-safety-negative` silence warnings?
< vasild>
aha! let me try...
< vasild>
hebasto: no, it does not silence them
< hebasto>
hmm...
< vasild>
but now I see it prints blockchain.cpp:121:5: warning: calling function...ility '!cs_main' [-Wthread-safety-analysis]
< vasild>
it is due to -Wthread-safety-analysis
< vasild>
MarcoFalke: ^
< vasild>
what "negative annotations" where merged? was this recently?
< vasild>
It used to compile for me a few days ago and now I assume that those warnings are due to a clang upgrade, but maybe they are due to some recent changes in the source?
< vasild>
actually I have a backup of the previous clang...
< hebasto>
vasild: you keep backups of compilers?
< vasild>
:-D
< vasild>
the upgrade script keeps backup of previous packages, not just compilers
< vasild>
it is convenient if the new stuff bricks
< hebasto>
is it freebsd feature?
< vasild>
yes, to one of the tools I use - portmaster
< vasild>
right now I am with llvm-devel-12.0.d20201027
< hebasto>
with `apt` one could set package version explicitly
< vasild>
and I see llvm-devel-12.0.d20200811.txz and llvm-devel-12.0.d20200925.txz lurking here
< hebasto>
October number is 10, right?
< hebasto>
:)
< vasild>
llvm-devel-12.0.d20200925 -- no warnings
< hebasto>
so it seems not our problem
< vasild>
yes, Oct is 10 :)
< vasild>
a recent compiler is issuing warnings on our code and that is not our problem?