14:48:08 b​oog900:monero.social: great work on the PRs btw!
14:48:48 b​oog900:monero.social: 2 of them just need to be rebased but they look good, thank you!
14:50:57 d​unateiio:matrix.org: boog900: Hi sir, can you please triage my report on github? (Monero oxide)
14:58:10 r​edsh4de:matrix.org: on it!
15:18:58 r​edsh4de:matrix.org: rebased and fp'd both
16:11:01 b​oog900:monero.social: I don't think we need `TorMode::Off` with your PR
16:11:42 r​edsh4de:matrix.org: disabling Tor shouldn't be an option?
16:12:07 b​oog900:monero.social: it is disabled if you don't turn it it on for P2P right?
16:13:00 s​yntheticbird:monero.social: i've the feeling that simply removing `TorMode::Off` is gonna hurt readability/comprehension of Tor code in `cuprated`
16:13:28 b​oog900:monero.social: its already not that pretty but currently it does nothing
16:13:57 b​oog900:monero.social: we are defaulting to auto which wont turn on Tor if you don't set the p2p to turn on Tor
16:15:20 s​yntheticbird:monero.social: i see
16:15:43 s​yntheticbird:monero.social: well i blame conf file being a UX mayhem
16:16:01 b​oog900:monero.social: it makes sense to me :)
16:16:08 r​edsh4de:matrix.org: I think the readability can be fixed by specifying in comment docs that this setting takes effect only if tor is enabled in p2p
16:16:25 s​yntheticbird:monero.social: i only see you. But all the voices in my head have numeric superiority. Check mates
16:16:35 s​yntheticbird:monero.social: lol
16:17:24 b​oog900:monero.social: yeah you can do that
16:17:52 b​oog900:monero.social: Tor should only be turned on if it is being used currently only P2P uses Tor
16:17:57 s​yntheticbird:monero.social: im sure this will alleviate the issue. But `cuprated` initialization right now have some hard readability anyway
16:18:58 s​yntheticbird:monero.social: If so is done, may i propose that after this change is merged, the PR (i can't open github right now) for Tor architectural/user book get updated and merged
16:19:16 b​oog900:monero.social: probably will need updating
16:20:44 s​yntheticbird:monero.social: like beyond this change?
16:21:13 b​oog900:monero.social: oh you said it needs updating lol
16:22:01 s​yntheticbird:monero.social: lol i wasn't sure you picked it up
17:00:44 r​edsh4de:matrix.org: updated the PR
17:16:20 b​oog900:monero.social: Meeting here in 45 minutes
17:57:52 s​yntheticbird:monero.social: meeting here in 1 minute
17:58:51 s​yntheticbird:monero.social: DROP DOWN IN
17:58:52 s​yntheticbird:monero.social: 5
17:58:54 s​yntheticbird:monero.social: 4
17:58:56 s​yntheticbird:monero.social: 3
17:58:58 s​yntheticbird:monero.social: 2
17:59:00 s​yntheticbird:monero.social: 1
17:59:13 b​oog900:monero.social: !meeting
17:59:15 m​oo:monero.social: Starting meeting: https://github.com/monero-project/meta/issues/1336
17:59:18 b​oog900:monero.social: 1) greetings
17:59:27 s​yntheticbird:monero.social: hello there
17:59:35 r​edsh4de:matrix.org: hello
18:01:18 b​oog900:monero.social: 2) updates
18:02:49 h​into:monero.social: hello
18:03:38 b​oog900:monero.social: I wasn't able to work much on Cuprate last week, however the new database is pretty much ready. It has all the functionality of the current DB I just need to clean it up a little then PR it.
18:06:25 r​edsh4de:matrix.org: In PR #578, added a guard to TorMode::Auto resolution to skip the resolve step if tor is disabled to prevent a useless socks5 query
18:09:36 h​into:monero.social: me: have been trying out docker reproducible builds perhaps as an interim; took a small break last week
18:10:12 b​oog900:monero.social: 3) Project: What is next for Cuprate?
18:10:41 b​oog900:monero.social: I plan to PR the new DB after the meeting, do we think we should do a new release once it is merged?
18:10:56 b​oog900:monero.social: or wait for RPC
18:14:28 h​into:monero.social: How long would it take to open + review RPC?
18:15:23 b​oog900:monero.social: at least a month most likely 2
18:17:26 h​into:monero.social: releasing after DB asap seems better in that case IMO
18:19:48 b​oog900:monero.social: itll probably take a while to review too
18:21:11 h​into:monero.social: after DB is merged I think we'll know if/when to release
18:23:37 h​into:monero.social: any thoughts on using docker for repro builds in the interim before (hopefully, eventually) moving onto something like StageX?
18:25:25 s​yntheticbird:monero.social: i'm completely for. This is a cheap and easy solution for the short-term. I initially proposed that we built inside snapshotted debian machines since debian repository are archived
18:25:28 h​into:monero.social: I said previously I'd prefer going straight to bootstrappable builds although having at the least reproducible builds in-time for a beta release is enticing
18:25:30 s​yntheticbird:monero.social: for it
18:26:21 b​oog900:monero.social: yeah I would be ok with that
18:28:53 k​ayabanerve:matrix.org: Using StageX would still require using Docker, so this moves along the right path. Why can't StageX be used now?
18:29:03 k​ayabanerve:matrix.org: (I recently went on a Linux arc and made a bunch of PRs upstream)
18:30:49 k​ayabanerve:matrix.org: https://github.com/serai-dex/serai/blob/737dbcbaa78ab817cc1c435cb2b6c5d24d1c4391/orchestration/runtime/Dockerfile#L1-L11 is old code of mine to use a Debian snapshot in a container
18:31:50 h​into:monero.social: I'd be ok with StageX right now as well, although the maintenance for just docker would probably be less complex for boog900 if changes are needed without me
18:32:38 k​ayabanerve:matrix.org: I mean, the pitch of StageX is that you can do FROM stagex/pallet-rust instead of FROM rust:stable and immediately be premised on StageX.
18:33:01 k​ayabanerve:matrix.org: The only issue with StageX is if some dep is incompatible/not yet packaged for StageX, hence my question.
18:33:27 k​ayabanerve:matrix.org: *should be if
18:34:23 h​into:monero.social: yup I'd assume it would have more things to workaround and would take longer and be more of a pain to maintain
18:34:47 k​ayabanerve:matrix.org: Here's Serai's use of a StageX package to build one piece of our code: https://github.com/serai-dex/serai/tree/next-polkadot-sdk/orchestration/runtime/bootstrap/Containerfile
18:34:57 k​ayabanerve:matrix.org: Ideally, yes, it's literally just the `FROM` command.
18:35:18 k​ayabanerve:matrix.org: Eh, maybe, but I'd try with StageX first and go from there before deciding to start from Debian.
18:35:48 k​ayabanerve:matrix.org: I did have to upstream support to StageX for LLVM 21, Rust 1.93.0, to get _specific_ goals of mine achieved, but that isn't generally necessary 😅
18:36:15 k​ayabanerve:matrix.org: And also, I already upstreamed LLVM 21 and Rust 1.93.0 😅 So those are available now if you use the repository and not a binary release
18:37:57 k​ayabanerve:matrix.org: I'd try it and I'll be happy to help if anything comes up :) Heard if it does become something to work through and not in the current scope though
18:42:17 b​oog900:monero.social: anything else to discuss today?
18:44:54 b​oog900:monero.social: I think we can end here
18:44:59 b​oog900:monero.social: thanks everyone!
18:45:04 b​oog900:monero.social: !meeting
18:45:08 m​oo:monero.social: - Logs: https://github.com/monero-project/meta/issues/1336#issuecomment-3880045525
18:45:08 m​oo:monero.social: - Next meeting: https://github.com/monero-project/meta/issues/1339