< sipa>
one is for messages that are always to be printed, the other only conditionally
< giaki3003>
Hello! I would like to have some more info on the debug executables Gitian spits out at the end of each build. How are they used?
< jonasschnelli>
giaki3003: they are compiled with debug flags...
< jonasschnelli>
giaki3003: sorry,... more specific: the symbols are available there... gitian compiles with -O2 -g
< jonasschnelli>
The non debug binaries go though contrib/devtools/split-debug.sh
< giaki3003>
Okay, so are they meant to be used with the visual studio debugger? Or something like gdb?
< jonasschnelli>
I'm not familiar with visual studio... but gdb, yes.
< jonasschnelli>
I guess you can also symbolicate a stack trace with the non-debug version if you have the deterministic built debug version of the same build
< giaki3003>
Great, because reading around I saw dbg files popped up as visual studio debugger files
< giaki3003>
Gdb complains about the .dbg files not being executable, already set 775 perms so not sure what is wrong
< giaki3003>
What do you usually use for debugging?
< wumpus>
phantomcircuit: no, LogPrintf is not deprecated.
< wumpus>
please, don't do so, either
< * wumpus>
still remembers in the old bitcoin source, satoshi had remapped 'printf' with a macro, now that was confusing, but we should make a habit of switching around log function names that just adds to cognitive load
< _flow_>
else I could do to help getting the PR merged?
< wumpus>
_flow_: will have a look
< wumpus>
yes, I'm somewhat scared of that one
< _flow_>
wumpus: Since I have looked at how bitcoind assembles its configuration and touched the code, I fully understand
< _flow_>
The main issue is that the configuration is not assembled first and then validated, some things happen here and there
< wumpus>
so as I've probably said in the PR, the reason no one dares to touch this stuff is because there are no exhaustive tests for all cases users might be relying on in practice
< wumpus>
if there were it would be easier to say that something is correct
< _flow_>
yep, I hoped that re-activating previously disabled tests would be enough to green light my PR…
< wumpus>
so in absence of me being truly convinced that this won't come back to haunt me later because someone's use-case broke, I'm kind of scared to touch it
< wumpus>
I'm sorry to have to be like this, I really hate it too, but I want to be honest about it
< wumpus>
yes, that does help !
< _flow_>
no worries :)
< wumpus>
and if everyone else agrees this is an improvement I'm willing to merge it of course, but I just haven't been able to look at it in detail and I'm not, myself, convinced I can think through all impilcations of it now
< _flow_>
wumpus: MarcoFalke disabled the tests, would surely be interesting to hear his thoughts
< wumpus>
yes!
< _flow_>
I've pinged him in the PR. We'll see what happens.
< wumpus>
hopefully we can get this in soon, would be good to have the behavior fixed (without breaking anything else :-) )
< BlueMatt>
github support mailed back last night and said they've fixed the 500 issues
< BlueMatt>
so folks should probably email them again if you still see them anywhere
< provoostenator>
They mailed me as well and mine works again.
< ken2812221>
Hope that someone can review #14009, functional tests for Windows are enabled on Appveyor.
< gribble>
https://github.com/bitcoin/bitcoin/issues/14009 | Simple refactoring: Common code for decoding of hex "objects" by domob1812 · Pull Request #14009 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< cfields>
jonasschnelli: gentle detached sig reminder for 0.17.0rc3
< jonasschnelli>
cfields: thanks.. will submit in a couple mins
< provoostenator>
*SSHing into Gitian machine, fingers above enter key...*
< * provoostenator>
bangs head on table
< cfields>
jonasschnelli: no rush. I've already pushed mine. I have to head out soon, so feel free to merge and tag if you're comfortable. Otherwise I'll check later tonight.