05:51:23 <m-relay> <k​ayabanerve:matrix.org> jberman: tobtoht jeffro256 What's our required MSRV?
05:52:08 <m-relay> <k​ayabanerve:matrix.org> So far, the code has been operating on a MSRV of 1.69, due to how Monero's cross-compilation infra ran on... Ubuntu 22?
05:52:38 <m-relay> <k​ayabanerve:matrix.org> which had LLVM from 2021 which didn't play nice with newer Rusts when cross compiling
05:54:49 <m-relay> <k​ayabanerve:matrix.org> I knew there was work to move to Guix, and I see Guix supports the latest Rust, but do we still have any infra which would fail with a MSRV of Rust 1.85? That's where _most_ of the ecosystem has jumped to (which Debian Trixie packages).
05:55:39 <m-relay> <k​ayabanerve:matrix.org> I'll also note the issue isn't that Rust doesn't work on Ubuntu 22. The issue was Ubuntu 22 was the build-host for cross compilations and when we plugged in newer versions of Rust, there were toolchain issues during the cross compilation process which I didn't have the time/energy to retrofit. I also think that only brought us down to Rust 1.7x or so, but then issues with msys bro<clipped message>
05:55:40 <m-relay> <k​ayabanerve:matrix.org> ught us down to 1.69? There were a few rough edges were 1.69 was the one which was 'just right' for all standing infra
05:58:02 <m-relay> <k​ayabanerve:matrix.org> FWIW, we can use such an old version of infra. There's just libs requiring Rust 1.85 which would notably speed things up.
09:08:13 <m-relay> <s​yntheticbird:monero.social> let ubuntu dies already
09:08:47 <m-relay> <s​yntheticbird:monero.social> (very verbose argument i know)
13:36:53 <m-relay> <j​pk68:matrix.org> If only gcc-rs would be ready soon
13:38:22 <m-relay> <j​pk68:matrix.org> Would probably be so much easier to bootstrap
13:59:10 <m-relay> <w​oodser:monero.social> I'm seeing that after opening wallets and syncing them (which can be a very long sync), calling `import_multisig` will revert the wallet's height to before the sync and do it all again, and only then does the call succeed. the result is that the user waits a long time unexpectedly when creating a multisig tx. is this expected somehow, or unexpected, or could be better avoided? may<clipped message>
13:59:10 <m-relay> <w​oodser:monero.social> be a good question for jberman , but any insight would be helpful
14:00:36 <m-relay> <w​oodser:monero.social> jberman ^ (just in case the tag above isn't right :))
14:46:15 <tobtoht> kayabanerve: We will build FCMP++ release builds with Guix, which will have at least Rust 1.93. See #10331 and #9440.
14:46:29 <tobtoht> We support depends on Ubuntu 22.04 until April 2028 (EOL + 1y, see #9446). Before 2nd April 2026, we supported 20.04.
14:46:58 <tobtoht> This is so downstream projects can build monero libraries for Linux while targeting a reasonably old version of glibc. This isn't relevant when cross-compiling for Windows, so I wouldn't mind making an exception to increase the build system requirements there.
14:47:20 <tobtoht> RandomX v2 requires GCC 14 or above for riscv64, so we're already allowing an exception for that target.
14:47:49 <m-relay> <k​ayabanerve:matrix.org> jpk68: You can bootstrap Rust from LLVM in ~2 hours with a nicer Ryzen. It isn't actually that bad nowadays.
14:49:20 <m-relay> <k​ayabanerve:matrix.org> tobtoht: Supporting Ubuntu 22.04 isn't an issue if one is allowed to install a modern Rust. Supporting its shipped version of Rust or mandating its toolchain apply is potentially, but it shouldn't be an issue here.
14:49:52 <m-relay> <k​ayabanerve:matrix.org> so sounds like I'm all clear to use Rust 1.93?
14:51:21 <tobtoht> I'm fine with installing a modern rust.
14:51:45 <tobtoht> I think so? Would need to check if there are other CI failures.
14:52:32 <m-relay> <k​ayabanerve:matrix.org> Heard
17:47:27 <m-relay> <w​oodser:monero.social> I see now that importing multisig always causes the wallet to be re-synced from the last export point. that explains the re-sync
19:21:30 <m-relay> <w​oodser:monero.social> I'm thinking `import_multisig` in wallet2 should take a flag to specify if `refresh` should be called at the end. the current code forces an immediate refresh from the last export height, but apps might have a custom sync routine e.g. to monitor progress
21:13:19 <m-relay> <j​berman:monero.social> This commit here avoids that refresh by using the background sync mechanism for multisig ( https://github.com/seraphis-migration/monero/pull/291/changes/27db6ba86e3a9b5eb284999304dd819f6c9cc039 ), we could upstream it sooner than FCMP++, but that definitely will need to be in for FCMP++ multisig
21:16:46 <m-relay> <j​berman:monero.social> There are only like 2 lines in there relevant to FCMP++ stuff, it's by and large a change to the existing approach to avoid that refresh()
21:17:56 <m-relay> <j​berman:monero.social> It maayyyy be a little complicated to upstream it sooner, if e.g. a multisig wallet has already synced outputs but doesn't have key images constructed for them, then they'd be screwed
21:18:53 <m-relay> <j​berman:monero.social> Soo ya ideally it would probably be simplest to hold it until FCMP++