< 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> does anyone here have knowledge regarding bind-now, relro and such hardening flags on POWER64? it looks like on POWER64 architecture, the .plt section remains writable: https://github.com/bitcoin/bitcoin/pull/14066#pullrequestreview-520439303
< wumpus> any idea why? is this unavoidable?
< wumpus> or just a compiler/linker limitation
< 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
< wumpus> luke-jr: ^^
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20268: ci: Move s390x build to cirrus (master...2010-ciS390x) https://github.com/bitcoin/bitcoin/pull/20268
< real_or_random> fwiw, I'm playing around with the "shippable" ci for secp256k1. it took me just an hour to migrate the travis config (ignoring a minor issue with apt-get) and deploy it my secp fork https://app.shippable.com/github/real-or-random/secp256k1/runs/6/1/console
< 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
< hebasto> s390x on travis works again
< bitcoin-git> [bitcoin] hebasto closed pull request #18077: net: Add NAT-PMP port forwarding support (master...20200130-natpmp) https://github.com/bitcoin/bitcoin/pull/18077
< bitcoin-git> [bitcoin] hebasto reopened pull request #18077: net: Add NAT-PMP port forwarding support (master...20200130-natpmp) https://github.com/bitcoin/bitcoin/pull/18077
< real_or_random> hebasto: yes, what worries me is the travis migration to .com, see my comment here https://github.com/bitcoin/bitcoin/issues/17802
< real_or_random> I wonder if people here are happy with cirrus. so far we stuck with travis for secp
< AdulrunaRedviva> hi
< 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
< sdaftuar> thanks!
< bitcoin-git> [bitcoin] vasild closed pull request #20234: net: don't extra bind for Tor if binds are restricted (master...bind) https://github.com/bitcoin/bitcoin/pull/20234
< bitcoin-git> [bitcoin] vasild reopened pull request #20234: net: don't extra bind for Tor if binds are restricted (master...bind) https://github.com/bitcoin/bitcoin/pull/20234
< luke-jr> wumpus: so what do you recommend?
< ariard> sdaftuar: fyi, it's displayed properly if you go directly on the commit https://github.com/bitcoin/bitcoin/pull/20187/commits/e8b215a086d91a8774210bb6ce8d1560aaaf0789
< 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] vasild opened pull request #20272: Add missing thread safety annotations (master...add_missing_tsa) https://github.com/bitcoin/bitcoin/pull/20272
< 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
< bitcoin-git> [bitcoin] hebasto opened pull request #20274: util: Drop redundant NDEBUG check (master...201030-ndebug) https://github.com/bitcoin/bitcoin/pull/20274
< 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?
< vasild> it is too recent ;)
< bitcoin-git> [bitcoin] ryanofsky opened pull request #20275: wallet: List SQLite wallets in non-SQLite builds (master...pr/exist) https://github.com/bitcoin/bitcoin/pull/20275