01:00:37 so CI tests sometimes fail at this step: https://github.com/monero-project/monero/blob/master/tests/functional_tests/mining.py#L109 01:00:52 AssertionError: Failed to mine successor to block 13 (initial block = 12) 01:00:57 which timeout should we increase? 01:01:25 hyc: you are familiar with randomx so maybe you have an idea 01:33:08 Do you have a log level 1 log of one failure ? It'll show whether it was busy mining or errored out. 01:43:41 Don't have log, it only happens occasionally so I would think some timeout issue 01:43:56 Can try to let it run a couple times with log level 1 01:48:36 these free Github CI servers are probably super overworked, but theoretically they should have 2 cores and 7GB RAM 01:50:04 It looks like it allows 5 seconds per block, that sounds generous, except if it hits an epoch boundary. Which that test does since it sets it to somehting like 8 IIRC. 01:50:44 I guess bump the 5 to... I dunno what kind of delay an epoch change can cause on those. 02:06:48 10? 15? no idea lol 02:10:43 If it's only occasional, it hints the delay's likely almost good. Double it, and if it happens again, then something darker may be afoot *menacing music* 02:15:15 Sounds good, will PR 02:31:08 -xmr-pr- selsta opened pull request #6927: functional_tests: inrease mining timeout 02:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6927 09:16:08 -xmr-pr- 00-matt opened pull request #6928: actions: Upload binaries after build 09:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6928 09:47:34 Could somebody who uses safari take a look at the preview of this PR https://github.com/monero-project/monero-site/pull/1138#issuecomment-713880192 and confirm you don't see the "cicled i" thinghy? 10:10:48 Guest59496: have you tried? https://www.browserstack.com/screenshots 10:11:01 it can do safari screenshots (apparently, i haven't created an account to test it yet though) 10:13:16 Guest59496: it's also broken in chrome on macos - https://i.imgur.com/uDGUgsg.png 10:26:27 I did try that, but it had very limited free features afaik. Will give it another shot. 10:26:27 Works in chromium. Can somebody check if it breaks on chrome on another OS? 10:26:46 I need to remake my browser testing VM 14:35:18 asymptotically: regarding 6928 14:35:33 github storage is quite limited that's why I didn't add this 14:35:56 also these are not static builds, but that could be fixable 14:36:46 is the storage limit not unlimited for public repos? 14:38:22 hmm last time I looked this up it was not 14:38:28 would be nice if it changed 14:38:31 https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions 14:40:00 oki apparently unlimited storage, nice 14:42:59 then only issue is dynamic linking 17:18:03 asymptotically: we could do nightlies with `make depends` and upload them as artefacts, and leave current CI as it is, what do you think? 17:24:16 selsta: sure, i'll create a new workflow to do that instead. i think we can add a button to run it manually too 17:24:38 might be useful if e.g. mooo wants someone to run with a patch he's made to sprinkle in extra logging 17:25:27 does button work? afaik we can do if some text is included in PR title 17:25:41 I would do a matrix with `make depends target=$TOOLCHAIN` 17:27:13 and build linux, mac, win, don’t think the others are necessary for nightlies 18:14:13 selsta: iirc they made it so that you can add a button to the workflow page a couple of months ago 18:25:27 yea I’m not super up to date 18:25:49 how would that work with permissions? currently only core can press the rebuild button 18:39:25 not sure, the docs aren't super clear :/. it's separate to the "rerun workflow" button though. i'll test it out now 20:02:29 @selsta, we've started having issues with tx broadcasting again, despite the trusted nodes. 20:02:54 You recommended setting something with peers if I remember correctly. 20:03:00 Increasing the maximum amount of peers, right? 20:03:15 you can increase out_peers to 32 or so 20:03:28 but I think there still is a bug with tx propagation 20:03:39 increasing out_peers will most likely not help 21:14:55 We hope that the Monero devs can prioritize fixing the tx propagation issue that first appeared after v0.16, as it has quite a substantial impact on business operations. 21:20:15 +1, most of the recent support related questions are related to tx propagation 21:31:08 -xmr-pr- selsta opened issue #6929: Tx propagation sometimes failing after Dandelion++ timeout 21:31:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6929 22:47:38 so I tried installing monero on iPhone with this: https://github.com/ish-app/ish/ 22:49:49 but getting some clock / time related symbol not found on start, would have been too easy I guess 22:50:50 Might need to link with... librt ? 22:51:56 I used the alpine linux monero package, guess probably have to compile myself to get this working 22:52:13 can monero be built with musl libc? 23:18:25 Transactions getting stuck, or rather nodes failing to relay them, has been an issue for quite some time 23:18:33 I made this issue last year (~v0.14): https://github.com/monero-project/monero/issues/5745 23:18:50 I had "fixed" this by scraping the transaction pools of hundreds of public nodes and manually relaying any transaction that did not appear in my mempool or chain 23:19:11 Dandelion++ (or another change in v0.17) seems to have exacerbated the issue quite significantly 23:19:33 With D++ i'm no longer able to obtain stuck transactions from public nodes as the pool is now hidden by default 23:22:04 tobtoht: your issue specifically talks about remote nodes 23:24:00 do you think it is the same issue? 23:27:05 I don't think so, what I meant is that tx relay was already fragile before D++ and that it is even more fragile now