What kind of person steals from their own community? www.reddit.com/r/Monero/comments/6d5yt5/what_fluffypony_just_did_is_not_ok/

Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin?

ErCiccione, do you know which strings to pull in order to reduce the boost dependency list for Monero Debian packages?

I meant Monero Debian package managers. Brain Off.

monero-project/monero #7574 cc anyone that can report this guy and close the PR. only drama

SerHack, I report everybody who shits on my lawn with that BS. And I did, because he mentioned the PR in the last Pr on the list ("Test: core_test...")

mj-xmr: thanks, by the way it's sad to see people creating fake account only to spam their useless drama.

It should be easy for GitHub peeps to delete all the reported spam with one query, but first Monday coffee and meetings :)

SerHack, I have almost no emotional attachment to this.

It's just another attack vector to learn your AI on :)

Mothaf'n AI wars!

mj-xmr: yeah, the repo is here: salsa.debian.org/cryptocoin-team/monero, but i can give you the email of jonas if you want (the dev maintaining the package)

ErCiccione, yes please

merge list: 6810 7005 7274 7332 7349 7366 7368 7373 7394 7398 7400 7401 7402 7412 7413 7418 7419 7422 7417

.merge- 6810

merge list: 7005 7274 7332 7349 7366 7368 7373 7394 7398 7400 7401 7402 7412 7413 7418 7419 7422 7417

Thanks :D

I'm going to have a small tweak to 6810. I'll ping when it can be added again.

Oh nvm, the MM proxy isn't in monero anyway, the PR does not change.

I think this is not the wrong time to ask this question. Since moneromooo told, that the branches are added to the merge list in order, and I have some approved ones, which aren't on the list, what should I understand from this?

For instance, this would be very important for me and is also a blocker for others:

Are there remaining things to do on it ?

If not, ask the reviewer to OK it.

Nope. We both agreed

I did not add it yet as it is a larger change and it would probably be good if it gets tested on other OS too.

Fair enough.

e.g. on Mac

Makes sense.

CI only tests on Linux

Personally, I don't like it, it's a lot of stuff for close to nothing, so I did not review or say anything :)

I also would have found it easier to just set an env var for CI and set larger timeouts for it.

I remember, but if you don't want to solve the random mining crash by just increasing timeouts up to the point, that the test cant tell anymore if something regressed, then please consider this.

the problem is the issue only seems to happen on github actions so I’m not fully convinced that it is timeout related in the first place

in theory all VMs should have 2-core CPU with 7GB RAM

Oh, there's a crash ?

I thought it was only timeouts.

sure it depends on how active the other VMs are on the physical host

I don't think it was a crash

moneromooo, timeouts are sometimes exceeded.

(not a crash)

selsta, exactly

but even if it depends on load it should not be so that a 20 sec timeout is fine in most cases and suddenly 60sec timeout is required

And a RPi user would have to set totally different timeouts than a power user.

Yeah well if the timeouts are exceeded, you can't tell anymore if the PR didn't break mining.

anyway will run it on my mac and check if it succeeds

Thank you

So there are 2 timeouts. The second timeout of 10s, which I left without change sometimes isn't enough.

This one is related to mining on a single core exclusively.

Which is a different situation than the RX init, which takes all available cores. The number of available cores also varies from system to system, so it's even more futile to be satisfied with constants.

mj-xmr: should your PR work on windows?

Yes

It's Python and C++11 code.

selsta, if it helps, I'll branch from this one to showcase this on a modified builds.yml, which executes the tests. Sounds like a plan?

*executes on Windows, and Mac

selsta, github.com/mj-xmr/monero/actions/runs/651972903

We need to give it about 45 minutes.

ccache is disabled for each build of course.

if `psutil monotonic` are required now to run tests this should be documented as it will break things for existing users

True, but I guess we should merge the other documentation PR first?

yes it will be merged first

Or should I put all 3 into this one?

(incl. requests)

does not matter

Then I propose to let the tests run, if they're OK I will update the documentation for the mining test in the original branch and give it for a final review.

Dang it. I need to install these for Mac and Windows somehow.

msys failed to install the Python dependencies, but so far Mac is rollin'.

BBL.

.merges

.merges

.merges

selsta, that link above. The job finished with a success. You can see the mining test's logs.

(on the Mac I mean)

yep also trying it locally

Oddly enough, when you compare the timings of Mac and Linux, it appears that Mac indeed has 3 physical cores, while Linux has one physical and the other one virtual, since the calculation job on all Mac's cores takes the same time, while under Linux it takes twice the amount of time of calculating on a single Linux core.

But that's secondary.

Although this is a perfect example, showing that constants would fail.

.merge+ 6810 7005 7274 7332 7349 7366 7368 7373 7394 7398 7400 7401 7402 7412 7413 7418 7419 7422 7417

.merges

needmoney90: Let me quote your hero. 'How do I ban FUK? AAAHHHH I don't remember. youtube.com/watch?v=mdLfkhxIH5Q Keep tryin' champion.