< bitcoin-git>
bitcoin/master f3b51eb Wladimir J. van der Laan: Fix occurences of c_str() used with size() to data()
< bitcoin-git>
bitcoin/master 5728f88 Wladimir J. van der Laan: Merge #17280: refactor: Change occurences of c_str() used with size() to d...
< bitcoin-git>
[bitcoin] laanwj merged pull request #17280: refactor: Change occurences of c_str() used with size() to data() (master...2019_10_c_str_size) https://github.com/bitcoin/bitcoin/pull/17280
< elichai2>
wumpus: you could "clone" it like `std::string str2(str1);` (pretty sure that will clone the data)
< wumpus>
there must be a 'proper' way right?
< wumpus>
hm maybe just wrapping in std::string(...) would do it
< elichai2>
if you ever find a guide for "idiomatic" C++ please tell me :)
< wumpus>
point taken
< wumpus>
I don't understand why ThreadRename would take a move argument anyhow, it seems a pointless case of over-optimization
< wumpus>
but not going to address that here
< elichai2>
i like that the rust `.clone()` makes it really easy to see all the allocations going on, while in C++ it's way more subtle
< wumpus>
yes, in general rust seems to be better thought out
< wumpus>
I guess its whole point is to make it harder to make subtle mistakes and avoid all C++'s footguns
< bitcoin-git>
bitcoin/master 3187934 Wladimir J. van der Laan: cli: Add "headers" and "verificationprogress" to -getinfo
< bitcoin-git>
bitcoin/master edd9d07 Wladimir J. van der Laan: Merge #17302: cli: Add "headers" and "verificationprogress" to -getinfo
< bitcoin-git>
[bitcoin] laanwj merged pull request #17302: cli: Add "headers" and "verificationprogress" to -getinfo (master...2019_10_getinfo) https://github.com/bitcoin/bitcoin/pull/17302
< setpill>
wumpus: re #16994 there is no status label that can be applied to "blocked" or "waiting" PRs? not sure how differentiation between "abandoned" and "will be picked up later again after external issues are resolved" is made if both are closed without label.
< wumpus>
no, there's no label for that; I'm asking you to close the PR instead of doing it myself, because then you can open it again when you deem the time is there
< wumpus>
it's the closest thing, it basically means that it should be revisited at some unspecified time in the future
< setpill>
personally prefer terminology like "blocked" to indicate this kind of situation. "future" has prioritization connotations that don't really apply to a project like this where people are welcomed to just pop in and out to contribute whatever they feel like contributing :)
< wumpus>
but 'blocked' has 'we should first do some other work' connotations (e.g. "blockers" in high priority for review), usually things are blocked on other things that need to be done
< setpill>
ah, fair point
< setpill>
either is probably fine, before you know it you have 10 different labels for all the subtle variations of this kind of situation
< setpill>
anyway, closed for now, let's hope i remember to revisit it (:
< wumpus>
yes, though I'm sure someone will pick it up as soon as systemd starts rejecting the setting :)
< jtimon>
I've been rebasing a commit similar to https://github.com/bitcoin/bitcoin/pull/16681 for years (which is a bit annoying as new instances appeared) and people are still complaining because it is not complete and more instances may appear.
< jtimon>
Sometimes I really don't understand the criteria, guys. Not a big deal, but it doesn't seem consistent.
< wumpus>
I'm sorry for the whitespace nit but I disagree it is 'incomplete', it's a small change that makes sense
< wumpus>
as I've commented in the PR I think it's a bad idea if you have conceptual and code review on a PR, and two ACKs, to extend the scope, feel free to do the rest in a new PR
< wumpus>
if you did replace all the other occcurences it could have easily have been drawn out to a PR that takes months, because there would be a discussion about what to change and whatnot
< wumpus>
in this case there was general agreement
< wumpus>
maybe you could learn from it and do more small, targeted PRs :)
< bitcoin-git>
[bitcoin] laanwj opened pull request #17316: refactor: Replace all uses of boost::optional with our own Optional type (master...2019_10_optional) https://github.com/bitcoin/bitcoin/pull/17316
< bitcoin-git>
[bitcoin] adamjonas opened pull request #17318: replace asserts in RPC code with CHECK_NONFATAL and add linter (master...replace-rpc-asserts-for-CHECK_NONFATAL) https://github.com/bitcoin/bitcoin/pull/17318
< JeremyCrookshank>
or using more advanced QT features?
< luke-jr>
JeremyCrookshank: minimum Qt version needs to be something available on stable releases of major distros (typically RHEL or Debian are the bottlenecks)
< luke-jr>
and if some people might consider it worse than before, you might have an issue
< luke-jr>
but otherwise should be same as any other improvement: slow moving, but eventually get in
< sipa>
JeremyCrookshank: hard to discuss without knowing what you're talking about
< wumpus>
do you have any specific thing you'd like to work on?
< wumpus>
what kind of more advanced qt features? there's a PR that adds qr code recognition (and would need qtmultimedia), as well as one adding a qml-based GUI for android
< wumpus>
nothing is ruled out if you have a good reason'
< JeremyCrookshank>
I don't have specifics but noted the general design hasn't really changed(not a bad thing). I would love to work on the GUI but still a c++ noob :p
< luke-jr>
I think it's just lack of people focussed on it
< luke-jr>
although otoh someone recently tried to revamp icons and ended up with all of them removed entirely :/
< JeremyCrookshank>
I would love something small to work on on the side on the GUI which would be useful
< luke-jr>
menu icons*
< JeremyCrookshank>
Yeah I saw icons went, quite liked them :)
< wumpus>
be careful to not fall into the trap of trying to make a 'cool gui', that's not the point of it, akin to industrial UIs the important thing is that it's hard to make mistakes
< wumpus>
because payments are inherently irreversible
< luke-jr>
wumpus: arguably reversible payments could be done, just nobody cares to :p
< wumpus>
it could be done as a layer on top, but yeah, that's not my point here :)
< luke-jr>
eg, BIP70-workalike + time locked tx
< JeremyCrookshank>
wumpus I understand
< bitcoin-git>
[bitcoin] practicalswift closed pull request #17320: Make compiler warn about tautological run-time comparisons (master...static_assert) https://github.com/bitcoin/bitcoin/pull/17320
< bitcoin-git>
[bitcoin] practicalswift reopened pull request #17320: Make compiler warn about tautological run-time comparisons (master...static_assert) https://github.com/bitcoin/bitcoin/pull/17320
< BlueMatt>
dongcarl: lol, stop telling me how to fix build system shit...I dont know what any of your comments mean
< dongcarl>
BlueMatt: Lol they were more for cfields and fanquake than for you (since we decided to work on the build system changes on ur PR instead of a separate one)
< moneyball>
that issue was punted to the next release. at minimum we should test the signed final release of .19 on MacOS
< wumpus>
I don't think this is a rc versus final issue, the rcs are signed in the same way as final
< wumpus>
you might want to post that screenshot in the issue
< dongcarl>
Yeah my subconscious has been blocking this problem... It seems Apple has gone mad with platform power...
< wumpus>
one of these days it's just not possible to distribute binaries anymore for open source software
< dongcarl>
So, after a cursory glance... It seems like if we don't want to have to tell users to right click > open, we need to use OSX-only tools...
< sipa>
ugh.
< dongcarl>
wumpus: I'm not sure if Apple's notarization tools care about reproducibility... So in the worst case it seems we will end up with 2 binary dists for osx: One which is reproducible, but not notarized, and another one which is non-reproducible, but notarized...
< wumpus>
awesome, that'd rule out cross-platform deterministic builds for OSX
< wumpus>
I'm unwilling to upload non-reproducible builds to bitcoin(core).org
< wumpus>
so that's the end of OSX support
< dongcarl>
wumpus: Perhaps we shall discuss this in the meeting tomorrow?
< wumpus>
sure
< sipa>
dongcarl: can we submit our build for notarization? or does the whole building process need to be built inside the Reality Distortion Field?
< achow101>
I think there's a decent chance that our binaries get rejected by their automatic scanner for being "crypto mining malware"
< sipa>
won't hurt to try
< sipa>
worst case it fails, and we ignore it?
< bitcoin-git>
[bitcoin] practicalswift closed pull request #17320: Make compiler warn about tautological run-time comparisons (master...static_assert) https://github.com/bitcoin/bitcoin/pull/17320
< dongcarl>
sipa: I'm looking into the process right now... I think we can. ryanofsky mentioned that _if_ we can prove to the users that the output of the notarization process comes from our reproducible build process, then it might be okay, since anyone running a Mac is trusting Apple anyway
< sipa>
dongcarl: or have a simple way to strip the notarization out, back to the binary that can be compared to the reproducible buils
< dongcarl>
"After uploading your app, the notarization process typically takes less than an hour."
< wumpus>
I guess the notarization data itself could be handled in the same way detached signatures are handled now
< wumpus>
assuming it's like an additional signature of apple
< fanquake>
Me and Cory have been looking at macOS toolchain issues all day. Can add this to the TODO list..
< wumpus>
the extra waiting time isn't really ap roblem
< dongcarl>
Oh it seems like GateKeeper will contact Apple for the notarization if we don't staple it to the app itself
< wumpus>
(assuming a normal release cycle like this)
< dongcarl>
We _should_ staple it though, for offline people
< wumpus>
so getting apple to greenlight the thing is first priority...
< dongcarl>
wumpus: yup. Perhaps someone should submit the RC just to see what Apple says?
< fanquake>
Just discussed with Cory and he said "we'll deal with it tomorrow". Might be something to fix for 0.19.1.
< wumpus>
I guess people installing the old releases run into the same problem? or is it based on the signing timestamp?
< bitcoin-git>
bitcoin/master d314e8a Wladimir J. van der Laan: refactor: Replace all uses of boost::optional with our own Optional type
< bitcoin-git>
bitcoin/master 08e2947 fanquake: Merge #17316: refactor: Replace all uses of boost::optional with our own O...
< bitcoin-git>
[bitcoin] fanquake merged pull request #17316: refactor: Replace all uses of boost::optional with our own Optional type (master...2019_10_optional) https://github.com/bitcoin/bitcoin/pull/17316
< moneyball>
wumpus: i just tried installing .18.1 and it installed without an issue. so only the new signed binaries are affected. (also i don't see the google advanced protection warning with .18.1 like i do with .19.* RCs)