< sipa>
prayank: you'll need to ask whoever implemented the android support, but i suspect it's because daemon processes on android work very differently
< hebasto>
prayank[m]: idk what
< hebasto>
to answer to you
< laanwj>
if you really want to use android like a linux terminal, there's always termux, fairly sure you can compile bitcoind/bitcoin-cli in that
< laanwj>
fairly sure it's possible to compile bitcoind and bitcoin-cli using the NDK but it leaves the problem 'how to use them'
< warren>
I found my bitcoin-0.21.0 x86_64 (gitian build) mysteriously dead. Nothing in debug.log. Any reports like this?
< jonatack>
over the weekend, and i'm waiting on confirmation from two people yet
< jonatack>
i understand that it shouldn't hold up an rc though
< fanquake>
Confirmation of what?
< laanwj>
i don't think having the list that up to date is so important
< laanwj>
i understand updates somewhat more often with I2P being new, but at some point we should just trust the address gossip mechanism
< fanquake>
I agree, just assumed any changes would have been merged into the previous PR, rather than another update opened right after that was merged.
< jonatack>
sure. (confirmation of address change due to port 0 transition. some are deleting their peers.dat)
< fanquake>
We can backport #22589, but I would like to do an rc2, given rc1 was doa
< laanwj>
a lot of this refactoring and code restyling just creates work for the sake of creating work
< kalle>
Yeah, that seems to be the consensus and I've gotten that feedback myself when I want to sneakily fix whitespace, so color me surprised. (Personally I think whitespace indentation fixes are fine as the refactoring is usually trivial, but I've been shot down more than once on that one.)
< laanwj>
if i'
< laanwj>
if i'm the last person pushing back on this it's fine just do it
< jonatack>
#21940 merged an hour ago broke the build for me when DEBUG_ADDRMAN is defined (I've been building and running with it defined for the past month or so)
< laanwj>
i'm sick of always having to be the party pooper on things like this
< laanwj>
just remove the section about restyling PRs from developer-notes.md and go wild
< laanwj>
jonatack: what error do you get?
< MarcoFalke>
laanwj: I don't like it either, but the alternative would be to leave the wrong whitespace forever and make it forever frustrating to edit those files with a "smart" editor or formatter.
< laanwj>
there are so many levels of "frustration"
< MarcoFalke>
I still think #22562 was closed correctly, since it was a standalone refactor, which are discouraged. I think bundling with other changes (in a separate commit) is fine
< MarcoFalke>
jonatack: Are you working on a fix already?
< jonatack>
MarcoFalke: had a quick look at just adding or removing a const but it didn't look to be as trivial as that and am in the middle of something else, so no :)
< laanwj>
it's like the warning "fixes", warnings are useful to point at potential problems, no argument there, but at some point it gets a life of its own
< laanwj>
the mission becomes to make the tools hapy
< MarcoFalke>
laanwj: Agree, which I think they shouldn't happen in standalone pull requests, but bundling to other (more meaningful changes) seems fine
< laanwj>
instead of the other way around
< MarcoFalke>
jonatack: Will take a look. Hope it is not too involved
< jonatack>
yes, if PRs like that are accepted, it would open the door to lots of similar ones that would take valuable attention away from better things (ISTM)
< laanwj>
though there is some continuum between 'reformat a few lines around that what you're changing' versus 'reformat the entire file', but i dunno, as said i'm fine with doing this once now but please don't normalize it
< laanwj>
like okay maybe this file specifically is very bad
< laanwj>
jonatack: yeah exactly
< MarcoFalke>
I am not aware there are any other "bad" files right now, so it should be a one-off.
< jonatack>
i think when people are new to the codebase, they see lots of stuff because it's a legacy codebase with many layers of change over a decade, and then they gradually become more used to it and focus relatively less on the style than in the beginning. of course everyone has their personal preferences, but it seems like leaving style fixups to the
< jonatack>
long-term contributors makes more sense for all the reasons mentioned
< laanwj>
jonatack: agree, i always have to get used to the coding style in a new project too, espeically as there's a lot of variability in that in C and C++, with some languages it's much more normalized (which whas advantages and disadvantages ofc)
< laanwj>
i don't see any reason to not close #22549
< _aj_>
laanwj: tend to agree with you on whitespace refactoring. it's annoying for "git blame" though "-w" and "-M" and the like can help with that
< _aj_>
MarcoFalke: could probably work around the indentation by wrapping in a namespace and adding a "using" to make it available again
< laanwj>
"yes, you can move various statements around"
< MarcoFalke>
laanwj: I think the goal was to not put the password in memory twice unless needed? Though with argument parsing moving to RPCHelpMan, this will likely become obsolete.
< laanwj>
unless i'm really missing something, this applies to a lot of places, and it seems pointless
< laanwj>
i think that' a weird reasoning, no one is going to call that function witht he expectation to hit that exception
< laanwj>
it seems such a minimal edge case, is this worth even discussing
< laanwj>
apparently it is, i'll leave it alone then
< MarcoFalke>
laanwj: Left a NACK on that particular diff.
< bitcoin-git>
bitcoin/master 5d37cc4 Patrick Kamin: Generate doxygen documentation for test sources
< bitcoin-git>
bitcoin/master dcd1169 W. J. van der Laan: Merge bitcoin/bitcoin#22001: doc: Generate doxygen documentation for test ...
< bitcoin-git>
[bitcoin] laanwj merged pull request #22001: doc: Generate doxygen documentation for test sources (master...issue/19248) https://github.com/bitcoin/bitcoin/pull/22001
< kalle>
Remember that one time I tried to whitespace-fix RPC commands, when I was adding the RPCHelper tweak? :P <MarcoFalke> I am not aware there are any other "bad" files right now, so it should be a one-off.
< MarcoFalke>
_aj_: git blame breaks for any other (refactoring or non-refactoring) change as well, even non-whitespace ones. I found `git log -S "foobar"` to be more useful
< kalle>
Sure, if there's an ongoing progress that makes sense to me.
< kalle>
RIght, that comment is what surprises me about laanwj's pointed-to PR which seems to be doing exactly that? I'm not sure what the distinction is.
< MarcoFalke>
progress is stalled right now, but it is still on my list
< MarcoFalke>
kalle: The difference would be that there are multiple whitespace changes in succession
< kalle>
Is there a project somewhere? Side projects are fun sometimes
< kalle>
TODO I mean.
< _aj_>
MarcoFalke: i find git blame works pretty well