nope i was just confused, the long compile time makes me forget what I was doing, it's still not playing ball with my GENESIS_TX lmao

i'd just forgotten to erase the original .mdb between executions and ended up loading the one with the original genesis_tx accidentally

nope it was the genesis_tx

i was setting the amount to 0 this time woops

why is the output amount so high in the monero genesis tx btw?

got the max of a uint8 as the output, seems like a small data type to use for amount in monero coins

so does that output even refer to a pre-mine quantity?

wow so I got it working, with a new genesis_tx, then on another machine i pulled the git and it failed... so i was like wtf, i went back to the machine I tested it on and erased the mdb files and executed, created them fine, same code

so then i delete it on that machine, the git and the mdb

download from the git again - same code - same genesis_tx - and this time it fails to launch, some height issue on create genesis or whatever

this is insane

WTF LMAO

HOW can this be X'D

monologue?

i don't knwo I think the ultimatum here is that I hate monero

.merges

Merge queue empty

selsta, I get your point about not wanting to launch too many jobs on GH, especially after I learned how much space the caches of each job take. That said, the extremes also have to taken care of. I was thinking of 2 things: either a weekly (scheduled) and optional GH Action, that would test the extremes, or a script (Docker?) that would do this locally. I could add the results to my bi-weekly report as well.

Either will serve as an inspiration for PRs, that fix the specific issues, while having the default settings and versions checked on each PR, like now.

What do you guys think makes more sense? A scheduled GH run or all local and

and presented on my report?

mj-xmr: we already test the latest version of everything on mac CI