-
m-relay<jeffro256:monero.social> This is the CI issue I mentioned a couple of weeks earlier! Look at the logs, the log states that the error occurs in file tests/functional_tests/multisig.py on line 388. Actually look at that line of code, it is different from what the Python stack trace says it is. I think that the repo inside the CI environment is somehow corrupted. Are you able to completely delete it and re-run the tests?
-
SapphireSpireA hash is like a cypher text, right?
-
sech1Hash can't be decyphered back, it's the main difference
-
m-relay<jeffro256:monero.social> Hashes are meant to be irreversible "fingerprints" of data, without actually storing any data itself. Ciphertexts inherently "contain" data that can be deciphered if you have knowledge of another piece of information called a "key".
-
m-relay<jeffro256:monero.social> You can hash your favorite movie down to 32 bytes, but if you want to encrypt that same movie, the ciphertext will be at least as big as the movie file
-
selstajeffro256: CI always uses a fresh VM image and clones from scratch on, I don't see how anything can be corrupted
-
m-relay<jeffro256:monero.social> Are you sure it uses a fresh VM image every single time? When you force-push to a branch, it takes much less time to build. I always assumed that this was due to the CCache of the existing VM image
-
m-relay<jeffro256:monero.social> Are you sure it uses a fresh VM image every single time? When you force-push/commit a second time to a branch on Github, it takes much less time to build. I always assumed that this was due to the CCache of the existing VM image
-
selsta
-
selsta
-
selstamatches exactly, unless I misunderstood what you are trying to explain
-
selstayes, always a fresh VM image. ccache gets uploaded and downloade to ~/.ccache, that's the only cache we have but there is no source code cache.