05:59:49 <MexicanTakeout96> Is there way to get wallet info of opened wallet over rpc call?
06:13:35 <MexicanTakeout96> I can't find any call for this in getmonero's wallet rpc methods document
06:15:36 <NakedKing> Hello. Where can i download stageNet blockchain directly?
06:16:08 <NakedKing> and which is smaller? stagenet or testnet
06:19:10 <moneromooo> MexicanTakeout96: depends on what info you want, doens't it.
07:00:37 <MexicanTakeout96> I want wallet file name specifically
07:01:46 <MexicanTakeout96> I want multiple wallets in a pool to pick from so this feature is needed
07:20:33 <moneromooo> You can add arbitrary attributes (so, a name) to wallets, and query them. see get_attribute/set_attribute.
07:21:00 <moneromooo> You can't get the filename unless you set it as attribute AFAICT.
07:21:29 <moneromooo> But you could also add such a RPC, though if you don't kow which wallet is loaded in the first place, you might have bigger problems.
07:23:32 <moneromooo> You can query the main address though, if that's good enough.
07:23:56 <moneromooo> And it'll also work if the wallet is moved.
07:35:23 <MexicanTakeout96> OK thank moo, I'll look more to it tmr. It's getting late here
07:47:17 <ErCiccione> Anyone who can do a final review of rbrunner's https://github.com/monero-project/monero/pull/8076? We are considering adding it to the Monero binaries we ship with Haveno to improve people's experience with remote nodes, but would be better if it was merged upstream
11:00:08 <kayabaNerve> Why do we name downloads os-arch yet then have a differing folder name of extended_arch-extended_os?
11:00:47 <kayabaNerve> And I get why we'd specify linux-gnu (the extended part). I don't get why we'd specify it when we don't offer any other flavors and we acknowledged that when we decided what to name the archives
11:01:51 <kayabaNerve> I just tried adding Monero to a CI and had to quetion what to do about that because I have os + arch, so I can download the file without issue, yet I can't copy out monerod :/
11:04:19 <kayabaNerve> This is partially me discussing naming scheme history, as I do know x86_64-linux-gnu follows some pattern out there, partially asking for suggestions on how to copy out monerod in a universal way, and partially identifying we've already simplified this for files as advocacy for simplifying it for the folder too
11:04:42 <kayabaNerve> And yes, bad time to ask 3 days after we release 0.18, I know :p
11:04:43 <moneromooo> Might have been done by different people :)
11:20:25 <selsta> kayabaNerve: we rename the archive so that it's easier for users to understand what they are downloading but the folder is named after the compiler toolchain used
11:21:08 <kayabanerve[m]> selsta: Is there value in preserving full toolchain when we have already accepted this reduction?
11:21:30 <kayabanerve[m]> It's not like linux-musl would work as-is already. The archives would conflict when they're dropped to just linux
11:22:28 <kayabanerve[m]> Users won't care. Developers may appreciate the info. Anyone who's actually running musl won't complain when they get a GNU binary which doesn't tell them it's GNU because the status quo lol
11:23:12 <selsta> ErCiccione: quite sure jberman[m] is still working on reviewing it, they already made a lot of progress
11:23:36 <kayabanerve[m]> Like if we actually offered musl, or there was a much wider musl user base... I guess this would have value? But as-is, it'd require updating archive scheme. While this forces it's updated... that's not an additional bound. Just further enforcement of it.
11:24:42 <selsta> kayabanerve[m]: i'm not sure if there is value, it's just how the depends build script names it
11:25:34 <ErCiccione> ok cool. Thanks selsta 🙂
11:25:50 <selsta> it's the gitian script that names the archive*
11:26:19 <kayabanerve[m]> Sure. I'll look for anyone who does think this is valuable and consider a PR to solely use the archive naming scheme.
15:43:31 <rbrunner> ErCiccione: selsta is correct, jberman is on it and expects to finish the review any day now. With a bit of luck no additional round of corrections may be necessary.
17:01:07 <jberman[m]> +1^
17:02:01 <ErCiccione> nice. Thanks to both