00:37:28 jpk68: Is the Rust implementation of FCMP still going to be used for the hardfork, and is it supposed to be temporary?
00:37:38 jpk68: Apologies for being out of the loop
05:36:10 j​effro256:monero.social: 1) Yes 2) No
11:00:50 xmr-pr: DUQUEredes opened pull request #10332: tx_pool: fix early return in remove_transaction_keyimages
11:00:50 xmr-pr: > https://github.com/monero-project/monero/pull/10332
11:15:50 xmr-pr: DUQUEredes opened pull request #10333: tests: add mempool throughput benchmark
11:15:50 xmr-pr: > https://github.com/monero-project/monero/pull/10333
12:15:50 xmr-pr: DUQUEredes opened pull request #10334: tests: add key image spent status lifecycle test
12:15:51 xmr-pr: > https://github.com/monero-project/monero/pull/10334
15:12:33 jpk68: j​effro256: Thanks. I might be missing something, but if the Rust toolchain is required as a dependency, does that not already break compatibility with older GCC versions?
15:13:13 jpk68: I know Rust doesn't use GCC, I'm just talking about what sech1 mentioned yesterday
15:15:56 m​ilas900:matrix.org: Is midnight cordano privacy share any technology with monero ?
15:18:13 m​ilas900:matrix.org: Is midnight cordano privacy share any technology with monero ?. I know the answer is no but just curious why two coins call them privacy
16:07:26 s​pirobel:kernal.eu: all of these "layer 2 privacy solutions" are half baked nonsense. the ux is absolutely horrific
16:08:45 s​pirobel:kernal.eu: this topic is more something for the mrl lounge
16:09:03 s​pirobel:kernal.eu: https://matrix.to/#/#monero-research-lounge:monero.social
16:11:35 luigi1111: .merges
16:11:35 xmr-pr: 10161 10162 10299 10312 10314 10315 10316 10317 10318 10319 10320
16:42:38 j​effro256:monero.social: Jpk68: what do you mean by "break compatibility with older GCC versions"? Our code uses C FFI to call the Rust crypto code, whose interface is determined by the Linux x64 ABI , which shouldnt be broken
17:09:31 jpk68: jeffro256: What I mean is, based on your messages from yesterday, you seem to be in favor of keeping GCC 7 instead of upgrading to GCC 14. Is the downside of upgrading GCC (breaking compatibility with older machines) not already existent due to the need of a recent Rust compiler?
17:10:38 jpk68: This matters for compiling of course, but also potentially the dynamically linked runtime libraries. The monero-oxide repo uses the 2021 Rust edition, which is a lot newer than the current GCC version
17:13:31 sech1: actually yes, Rust dynamic libs will likely need a newer glibc than what is available on old systems
17:17:23 selsta: .merges
17:17:23 xmr-pr: Merge queue empty
17:17:39 selsta: fixed it
17:36:45 Guest15: Is there anyone familiar with https://github.com/jtgrassie/monero-pool?
17:37:00 Guest15: With sources, not just set up
17:39:05 Guest15: Or maybe anyone knows how I can find jtgrassie?
18:45:54 selsta: jeffro256: 10332 is also fully AI generated, should I just close it?
18:46:00 selsta: or is the change itself ok?
18:47:57 j​effro256:monero.social: The change itself seem okay. There wasn't any active issue with that code AFAIK, but the idea is alright
18:57:00 sech1: jeffro256 I reviewed 10038, and found some issues
18:58:09 j​effro256:monero.social: jpk68: I see what you mean. You're basically asking "Does the existence of a new Rust toolchain basically make the old GCC support pointless?" Maybe. FCMP++ needs Rust 1.69, which released in March 2023. RandomX needs GCC 14, which released in May 2024. So RandomX's GCC dependency is definitely newer than the Rust dependency. As for which standard library Rust 1.69.0 requires, I'm not ure
18:58:14 j​effro256:monero.social: *sure
20:18:15 selsta: v0.18.4.6 is tagged
20:33:43 plowsof: 🥳