< promag>
fanquake: github could do that when someone forks the project -> it could ask for altcoin name and then it would rename everything
< sipa>
promag: coingen :)
< promag>
sipa: ah that's a thing already
< promag>
err, fucking libevent
< sipa>
i think it died in 2014
< promag>
`nc localhost 18443` doesn't trigger any callback
< promag>
only if a http request goes through
< sipa>
promag: there's also forkgen
< sipa>
oh, that died too
< promag>
lol "and the world is kind of sort of back to normal."
< promag>
quoting satoshilite from bitcoincore slack:@fanquake you should point him to https://build-a-co.in/ :)
< sipa>
based on litecoin 0.8.5.1, lol
< esotericnonsense>
lol, that's great (16616). could only be improved slightly if it were an s/bit/something-else. wonder how many important instances of 'bit' are in the code. :P
< phantomcircuit>
promag, i assume you're using the libevent http stuff and not the socket handling stuff?
< promag>
phantomcircuit: right
< promag>
phantomcircuit: are you suggesting to create a read event on evhttp_bound_socket_get_fd?
< bitcoin-git>
bitcoin/master a2714a5 Andrew Chow: Give QApplication dummy arguments
< bitcoin-git>
bitcoin/master 8fc7f0c fanquake: Merge #16578: Do not pass in command line arguments to QApplication
< bitcoin-git>
[bitcoin] fanquake merged pull request #16578: Do not pass in command line arguments to QApplication (master...no-qapp-args) https://github.com/bitcoin/bitcoin/pull/16578
< fanquake>
wumpus #16400 now has 3 ACKs. I'm going to add it to the HPFR list. Maybe we could save merging anything into validation while this gets some final review over today and tomorrow?
< bitcoin-git>
bitcoin/master 37f2784 practicalswift: tests: Use colors and dots in test_runner.py output only if standard outpu...
< bitcoin-git>
bitcoin/master e00501e MarcoFalke: Merge #16561: tests: Use colors and dots in test_runner.py output only if ...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16561: tests: Use colors and dots in test_runner.py output only if standard output is a terminal (master...parsable) https://github.com/bitcoin/bitcoin/pull/16561
< fanquake>
wumpus: I know exactly how you're feeling at the moment.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16620: util: Move ResolveErrMsg to util/error (master...1908-utilErrorResolveErrMsg) https://github.com/bitcoin/bitcoin/pull/16620
< elichai2>
achow101: is there a way for me to sign a psbt using a descriptor with private key instead of the wallet? (I'm doing `utxoupdatepsbt` with it and now i want to do `walletprocesspsbt`, or should I use `importmulti` instead?)
< bitcoin-git>
[bitcoin] jonatack opened pull request #16622: autoconf: property tests status and options (master...property-tests-autoconf-improvements) https://github.com/bitcoin/bitcoin/pull/16622
< elichai2>
I wish people would've used more switch/case for enums instead of if/else that way the compiler will warn you on all the uses of that enum if you modify it
< gleb>
wumpus: I just figured out something, and I feel like we can remove #16599 from "seeking conceptual review" for now to not distract people until I implement something.
< provoostenator>
gleb: that's not a bad idea. I'll probably have a stronger opinion (as opposed to no opinion) if I can see the implemations for both options.
< wumpus>
gleb: ok, will remove it
< MarcoFalke>
Short update on the ci stuff:
< MarcoFalke>
* GitHub ci is in early beta and there is not much I can evaluate
< MarcoFalke>
They don't have caching, nor can own hardware be attached
< MarcoFalke>
* Travis timeout was bumped to 90 minutes, so we shouldn't see any timeout anymore
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Aug 15 19:00:21 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< MarcoFalke>
But the good news is that the ci can be run locally (or anywhere now). See ./ci/ subfolder
< jonasschnelli>
nice
< gleb>
hi
< Chris_Stewart_5>
hi
< sipa>
MarcoFalke: nice
< cfields>
Glad to see you're trying it out, though :)
< jonasschnelli>
Though I still not fully buying into the concept that a CI configuration should be part of the main repository
< wumpus>
right, at least we know its limitations now, thanks!
< MarcoFalke>
cfields: Yeah, I guess in the end we'll go with jonasschnelli's ci
< jonasschnelli>
(once it's mature enough)
< ryanofsky>
fun fact: the ci folder contains 4 mentions of the word "poop"
< MarcoFalke>
jonasschnelli: Why not? travis.yml is part of the main repo
< achow101>
hi
< jonasschnelli>
Just conceptually I don't understand why the CI configuration needs to be part of the project sources
< jonasschnelli>
Could be another repo, config-file, whatever
< jnewbery>
hi
< MarcoFalke>
jonasschnelli: Because the config needs to be updated atomically with the source code
< jonasschnelli>
why?
< MarcoFalke>
Let's say I add a new dependency boost-process, the ci runner needs to install it
< jonasschnelli>
Yes. But it could be update in that secondary config file / repository then
< MarcoFalke>
And in the meantime the ci couldn't run?
< MarcoFalke>
Also you couldn't run it on older branches
< jonasschnelli>
Maybe...
< jonasschnelli>
It just feels this would not scale with multiple build systems / CI
< jonasschnelli>
With the Appvayor, it's already a problem IMO
< jonasschnelli>
but I'm probably complicating things...
< MarcoFalke>
My plan was to only have one place to put the config and have all build systems use that config
< MarcoFalke>
I tested it with GitHub CI, Cirrus CI, Travis CI. They all use the same config and it works
< jonasschnelli>
Wouldn't that lead to a monotonic CI/test system?
< MarcoFalke>
It includes the whole build matrix. But I agree
< kanzure>
hi
< ryanofsky>
i think it's convenient for things like ci and lint to be in the main repository, it would be a headache to have a change like #16367 that requires a ci update and have to stage it in multiple prs
< jonasschnelli>
I think removing is something that could be done after 1y of inactivity or if someone explicitly wants to be removed
< MarcoFalke>
why is the latest merge not signed and done with GitHub?
< MarcoFalke>
(ot)
< jonasschnelli>
valid point... some merge policy would probably be wise
< sipa>
we should probably add merge checks in CI just like in bitcoin core itself
< real_or_random>
MarcoFalke: yeah I think there are a few related issues to discuss
< provoostenator>
Could reuse some of the Bitcoin Core tools over?
< sipa>
yeah.
< real_or_random>
also e.g., I have an open issue about a security.md file
< real_or_random>
which raises the question who should be in there. secp256k1 maintainers or bitcoin-core maintainers?
< * MarcoFalke>
has set a bash alias `ghm` for "github-merge.py" that works on any repo
< real_or_random>
and we also don't have super clear guidelines for what should be in the repo and what not (e.g., we have the JNI bindings that we may want to remove)
< wumpus>
we should probably move github-merge.py to maintainer-tools
< wumpus>
instead of having it in the bitcoin core repository
< wumpus>
that way it's much easier to use it for different projects
< sipa>
i think that libsecp256k1 issues which don't directly affect bitcoin core can be kept inside the secp256k1 project (bitcoin core has no need for JNI... :p)
< sipa>
and discussed on the #secp256k1 channel
< wumpus>
secp256k1 issues should probably be reported to secp256k1 maintainers, in general
< sipa>
agree; though very serious issues that impact bitcoin could of course also be reported to bitcoin core
< real_or_random>
wumpus: yes this seems sensible they can escalate to core if necessary
< sipa>
wumpus: agree on moving over github-merge to maintainer-tools
< sipa>
i use it for unrelated projects too :)
< wumpus>
yes, if it affects use in bitcoin, or is even an issue that threatens bitcoin, that seems an exception
< wumpus>
sipa: ok!
< real_or_random>
ack on a using github-merge and/or related tools
< real_or_random>
core vendors secp256k1, so the changes need to be accepted there too
< wumpus>
#action move github-merge.py to bitcoin-maintainer-tools repo
< sipa>
real_or_random: occasionally we open a PR to core that updates the subtree, summarizing the changes
< real_or_random>
but tbh, if we open a large +500/-500 PR from time to time, it's too late to spot weirdnesses
< sipa>
yeah perhaps that's a question whether people here prefer more regular updates of the subtree
< real_or_random>
yes, indeed. I think my point is that these tend to get ACKed with the idea in mind that they're fine because they were merged in secp256k1
< wumpus>
it's another opportunity for review, though yes, if it groups too many different things it'll likely not get more than cursory glances
< real_or_random>
so it makes sense to have the same careful committing/merging process for secp too
< wumpus>
also a lot of bitcoin core reviewers don't have much knowledge of the details of the cryptography and implementation
< wumpus>
yes
< real_or_random>
right
< real_or_random>
sipa: this question is also related to possible releases
< real_or_random>
AFAIK it was always planned to have releases, we may reconsider that
< sipa>
yeah
< sipa>
i guess not everything needs to be resolved in this meeting
< real_or_random>
sure
< sipa>
but it's good to have some communication
< wumpus>
yes, it's fine, it's not like there's other proposed topics for this meeting :) and I don't think sharing a meeting with secp256k1 stuff is that bad so people are aware what is happening there
< sipa>
high priority for review?
< wumpus>
oh yes, we could do that
< wumpus>
#topic High priority for review
< BlueMatt>
an I add #16421 to the list?
< gribble>
https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub
< wumpus>
sure we can always add more, I'm most interested in whether some things are getting ready for merge though :)
< aj>
BlueMatt: fanquake did that already i thought?
< jeremyrubin>
correct
< BlueMatt>
oh, maybe
< BlueMatt>
I just want to get it in for .19, and its gotten very little review
< BlueMatt>
despite being an incredibly simple pr
< instagibbs>
BlueMatt, will review
< MarcoFalke>
I think we got three high-prio things merged this week
< bitcoin-git>
[bitcoin] ariard opened pull request #16624: wallet : encapsulate trransactions state (master...2019-08-encapsulate-tx-state) https://github.com/bitcoin/bitcoin/pull/16624
< fanquake>
I put 16400 in there because it had 3 ACKs and was much closer to being merged than 15799 at the time (also didn’t need a rebase). Guess someone merged into validation and broke it.
< fanquake>
I don’t think it should necessarily matter which PR was in there “first”. As there are things that have lingered in HP for weeks. It should also matter what has had recent/active review.
< roconnor>
Hi all. After building bitcoin-0.18.0 and bitcoin-0.18.1 when I run the test_bitcoin program it lists a large number of "Error: Specified -walletdir "wallets" is a relative path ... followed by "*** No errors detected". I didn't have this issue with bitcoin-0.17.1. Have I made some sort of configuration error here?
< lightlike>
roconnor: that was described in #15944 and recently fixed (#16277): as a side effect of a negative test these messages are written to stderr. so it's no problem.