09:34:29 <narodnik> https://invidious.fdn.fr/watch?v=FKlnwwOgInc
09:34:31 <narodnik> loool
14:02:25 <selsta> does anyone have gcc 14.1.1 and can confirm this build issue? https://github.com/monero-project/monero/issues/9359
14:02:30 <selsta> e.g. arch should have 14.1.1
14:03:10 <m-relay> <s​yntheticbird:monero.social> selsta
14:03:23 <m-relay> <s​yntheticbird:monero.social> yes I had the same issue trying to build spackle private testnet build
14:03:40 <m-relay> <s​yntheticbird:monero.social> thought I had done something wrong but yes I've the exact same error
14:10:56 <selsta> s​yntheticbird: do you know how checkout miniupnpc_2_2_8 tag?
14:11:25 <m-relay> <s​yntheticbird:monero.social> no
14:11:47 <selsta> have you compiled monero before?
14:11:48 <sech1> p2pool uses miniupnp but it doesn't have this problem with gcc 14. The version in Monero is 4 years old, it's time to update it
14:12:24 <m-relay> <s​yntheticbird:monero.social> yes, 8 months ago
14:14:02 <m-relay> <s​yntheticbird:monero.social> 4 years old is pretty unfortunate
14:19:21 <selsta> can you try the following changes first and then compile using these steps? first https://paste.debian.net/hidden/9892c4ee/ then https://paste.debian.net/hidden/f74b4854/
14:20:32 <selsta> if it works I'll PR it
14:20:38 <m-relay> <s​yntheticbird:monero.social> i'll try
14:20:59 <selsta> alternatively I can also prepare a branch so that you just have to enter make
14:21:08 <m-relay> <s​yntheticbird:monero.social> more I'm trying*
14:25:47 <m-relay> <s​yntheticbird:monero.social> selsta posted log in issue
14:26:27 <selsta> hmmm
14:28:22 <sech1> actually, what I did for p2pool was turning off a bunch of stuff in miniupnp's CMakeLists: https://github.com/miniupnp/miniupnp/compare/master...SChernykh:miniupnp:master
14:29:02 <sech1> try to leave only UPNPC_BUILD_STATIC = TRUE and UPNPC_NO_INSTALL = TRUE, everything else = FALSE
14:30:03 <sech1> minihttptestserver seems to be one of those binaries which aren't needed for building Monero
14:50:10 <selsta> will add UPNPC_BUILD_TESTS FALSE
14:52:31 <selsta> syntheticbird: can you try again with the changes to `external/CMakelists.txt` https://github.com/selsta/monero/commit/c4d50476d840e0b5d7e5fdd81d15423d604b6763
15:14:33 <m-relay> <s​yntheticbird:monero.social> selsta trying right now
15:14:47 <selsta> ty
15:31:31 <m-relay> <s​yntheticbird:monero.social> I forgot to run with -j 8. Wondered why it was so slow
15:35:36 <m-relay> <s​yntheticbird:monero.social> selsta Compiled successfully
15:56:06 <selsta> will PR
15:57:18 <selsta> seems it fails on older compilers now
15:59:22 <m-relay> <s​yntheticbird:monero.social> oh
17:15:24 <m-relay> <w​oodser:monero.social> somehow with binaries running on different OS, we're creating a multisig wallet where the participants apparently have different public spend and view keys after completion. was wondering if we can add a check in the multisig creation process to validate that the keys are the same, to prevent creating a broken wallet
17:24:40 <m-relay> <r​brunner7:monero.social> Doesn't the additional last multisig data exchange round that was added a year ago or so by UkoeHB already test that? Anway, if what you describe is a genuine problem, this seems to be pretty much the worst-case scenario to me.
17:28:10 <UkoeHB> woodser: do the OS have different endianness, or perhaps different sizes for certain ints?
17:43:54 <UkoeHB> woodser: have you reproduced the problem yourself? It's odd for the view keys to be different, since the view key derivation is quite simple. It could be a serialization bug, but user error is also possible.
17:44:16 <m-relay> <w​oodser:monero.social> probably a mix of linux arm64 and linux, mac, or windows x86, which as far as I know, usually use the same little endian and int sizes
17:45:01 <m-relay> <w​oodser:monero.social> I can reproduce being a participant which fails to import multisig hex due to different public keys, by creating a multisig wallet with this participant
17:47:38 <UkoeHB> woodser: Are binaries are built from the same commit?
17:49:53 <m-relay> <w​oodser:monero.social> yes they should be
17:55:15 <UkoeHB> woodser: Multisig account creation is deterministic from original wallet seeds. If you perform setup ceremonies with multiple combinations of OS using the same set of wallet seeds and compare the multisig kex strings passed between them, can you identify which string diverges?
18:07:42 <m-relay> <w​oodser:monero.social> I can look into that but that will take some time
18:57:07 <UkoeHB> Ok. I looked through the multisig account setup code and didn't see any obvious issues that could be relevant.
19:15:40 <selsta> size_t and uint64_t are different on mac, not sure if relevant to this issue https://github.com/monero-project/monero/pull/7321/files
19:18:52 <sech1> size_t can be 4 or 8 bytes depending on if it's 32- or 64-bit compiler
19:38:56 <selsta> not sure if it's 32-bit or 64-bit related, mac is on 64bit for ages now
19:40:33 <sech1> it's 64-bit there, but it's defined differently, so the uint64_t serialization functions are not called
19:41:49 <sech1> in any case, size_t shouldn't be ever used in serialization code