< gkrizek>
Hmm might have died. It’s hosted on wumpus server. Let me see if I still have access
< gkrizek>
We'll have to ask wumpus. I still have access to the server, but not enough privileges to see anything. The process appears to be running still, but not sure where logs are being sent.
< wumpus>
gkrizek: oh thanks for restarting the bot!
< wumpus>
gkrizek: "but not sure where logs are being sent" ~/ghi.log :)
< gkrizek>
wumpus no problem. I saw that log but it looked like it didn’t have any logs for days. I’ll keep an eye on it though.
< wumpus>
jonasschnelli: it was an intermittent error, happened exaxtly once, I haven't been able to reproduce it
< wumpus>
MarcoFalke: adding dongcarl sounds good to me, will do
< wumpus>
gkrizek: once we're sure the bot is stable I'll add it to crontab etc to automatically (re)start
< wumpus>
does it run for merges to 0.17? just merged 15252 but nothing
< gkrizek>
wumpus sounds good It should message about any PR merges. It only comments about pushes to specific branches, but 0.17 should be one of them. Looking at the logs
< gkrizek>
I'm going to restart it with debug enabled to try to catch some of this.
< gkrizek>
wumpus you can resend those payloads if you want to test it out
< wumpus>
gkrizek: yeh i'll rewind the 0.17 one
< sipa>
provoostenator: with my latest PR pubkey entries in the expansion are only created for "pkh", "wpkh" and "combo" descriptors
< gkrizek>
wumpus so that worked sending the PR message, but I see the commit push messages failed. I'll go fix that now
< wumpus>
gkrizek: any idea why it was missed the first time around?
< gkrizek>
No, I could see that it connected to IRC successfully but just stalled after that. So something happened with the IRC server. I'll leave debug on for a while so I can catch little errors like this.
< wumpus>
gkrizek: ohh okay thank you
< wumpus>
no big deal github's own service was also not 100% reliable in delivery
< gkrizek>
Good to know! haha. I'll make some updates to hopefully fix these issues. Then I'll monitor the logs throughout the day and try to catch any new problems and fix them.
< gkrizek>
Thanks everyone for being patient with this! It's very hard for me to adequately mimic the bitcoin repo payloads and IRC stuff, so naturally the bugs happen in "production".
< provoostenator>
sipa: I know. I want to check that I understand _why_ correctly (see my comment on your PR).
< provoostenator>
tl&dr iiuc it's to prevent e.g. with multisig A+B, when A redeems to an address wpkh(a) that suddenly B sees that as part of his wallet.
< sipa>
provoostenator: it's more that you only happen to need pubkey entries in the signprovider when pubkeys need to be looked up by hash
< sipa>
provoostenator: it's a bit of a coincidence that that is exactly compatible with what's needed for importmulti
< MarcoFalke>
Anyone interested in trading reviews on #15043?
< bitcoin-git>
bitcoin/master 6f6514a Hennadii Stepanov: Correct units for "-dbcache" and "-prune"
< bitcoin-git>
bitcoin/master 77339e5 Wladimir J. van der Laan: Merge #15163: Correct units for "-dbcache" and "-prune"
< bitcoin-git>
[bitcoin] hebasto merged pull request #15163: Correct units for "-dbcache" and "-prune" (master...0190114-correct-info-units) https://github.com/bitcoin/bitcoin/pull/15163
< wumpus>
hebasto: good point, will take a look
< wumpus>
gkrizek: i think the merger name is wrong^^
< gkrizek>
Looking at the comments before it, I'm guessing you merged it?
< wumpus>
the bot makes it look like everyone (even those without commit access) merge their own PRs :$
< wumpus>
yep!
< gkrizek>
Ok, yep. Fixing that now.
< gkrizek>
I believe I have fix the other issues though! Found some bugs that were causing it to basically be inoperable. So should be working much better now, but I'll watch it today
< gwillen>
win goto #cslounge-finance
< gwillen>
whoops
< gkrizek>
wumpus username issue fixed so all known issues are fixed, but I'll keep an eye on it
< meshcollider>
gkrizek: thanks!
< gkrizek>
No problem! :D
< wumpus>
gkrizek: yay !
< wumpus>
I'll set it up for secp256k1 too
< gkrizek>
Awesome
< wumpus>
gkrizek: ok I've added the webhook in the secp256k1 project and updated the ghi config to add a new 'pool' for it
< wumpus>
i think this should do it
< gkrizek>
Ok, great. I see in the logs: "Received repository 'bitcoin-core/secp256k1', but no pool is configured for it.", but I'm guessing you added the webhook before the update to the config?
< MarcoFalke>
wumpus: Mind to create a https://github.com/new for bitcoin-core/qa-assets ?
< MarcoFalke>
To hold Bitcoin Core related blobs used for quality assurance
< wumpus>
gkrizek: yes; i also guess it needs to be restarted before the change to the config takes effect?
< wumpus>
MarcoFalke: sure!
< MarcoFalke>
kewl
< gkrizek>
No it shouldn't actually. So I'm guessing it was just a timing mismatch
< wumpus>
gkrizek: i'll resend the event just in case
< gkrizek>
"Received the 'ping' event Sent 'pong'"
< gkrizek>
It works!
< wumpus>
woohoo!
< MarcoFalke>
I think #15043 is ready for merge, since there is no substantial review and it is holding back my work on the fuzz test runner
< gkrizek>
Simple, but it's the thing that caused our master CI failures that we couldn't find the cause
< wumpus>
I mean one great advantage of having split repositories is that we could spread the load of maintenance a bit
< MarcoFalke>
Merging of fuzz seeds could even be automatic. I am going to write a script for that
< wumpus>
cool!
< MarcoFalke>
Only seeds that increase node-coverage are going to be merged
< wumpus>
promag: "is there a 0.17.2 date?" → no, we never plan release dates for minor releases, usually they're motivated by some more serious bug
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15295: fuzz: Add test/fuzz/test_runner.py and run it in travis (master...Mf1901-qaFuzz) https://github.com/bitcoin/bitcoin/pull/15295
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15296: tests: Add script checking for deterministic line coverage in unit tests (master...test_deterministic_coverage) https://github.com/bitcoin/bitcoin/pull/15296