Some feedback here -> reddit.com/r/Monero/comments/j5qbq1…01701_oxygen_orion_released/g7wvk09

dEBRUYNE: replied, I’m skeptical at that comment

selsta: I'm able to reproduce

"Some problems at connect, message: Socks request rejected or failed"

"Problems at shutdown: Transport endpoint is not connected"

Turning off Socks5 proxy in settings allows wallet to connect to localhost daemon.

I don't have time to debug this any further atm

xiphon: ^ any idea?

tobtoht: thanks

selsta: works as expected

a user tries to connect to a remote node using socks proxy

that's what GUI is doing

^ They shouldn't use remote node mode to connect to local node with socks proxy enabled

guess that require monero-project/monero-gui #2956

to select custom port on tails?

All we need is just fix local node mode, i.e. to add local rpc bind port configuration and set it to some Tails "allowed" local port

"guess that require monero-project/monero-gui #2956" -> don't like the particular implementation

but yep, basically we need a way to configure local daemon rcp bind port

due to torsocks?

ok

i will have a look a bit later

*maybe* we will fix it in the point release

xiphon: i peeked at the guix package of monero-gui and they are certainly having the same problem i have. see git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/finance.scm#n713. VERSION_IS_RELEASE is being manually patched

could you provide a link to monero source they use?

rnhmjoj: ^

i think they are just downloading the archive from relase 0.17.0.1 from github

on this line: git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/finance.scm#n672

the sha256 hash is identical to mine, nice

i don't see they fetching monero-gui repo recursively

anyway, i need a steps to reproduce the issue

^ please open a Github issue with the steps

if you have nix installed it would be pretty simple. otherwise, i guess i could give you a trace of the cmake command invocation and other stuff

"i think they are just downloading the archive from relase 0.17.0.1 from github"

you can't use it

please follow the official building docs and recursively clone monero submodule

at this point it seems to me that you are using outdated monero sources

why not? if you mean because it won't fetch the submodule it doesn't matter because the monero directory is copied from the monero package source, which is itself fetched recursively with git

cause github archives doesn't contain submodules, as you said

alright, we have a CI set up

please have a look at the command we actually run on every commit / pull request

xiphon: the monero sources are from 0.17.0.1 and yes, they contain the submodules all right. in any case the issue is coming from a file within monero-gui source tree, not the monero submodule

it shouldn't use Version.cmake from monero-gui repo, that is clearly a bug

that i fixed a while ago

please let me know if there is something left regarding this

but we already have a PR removing this and all the other unused cmake code from the monero-gui repo

^ it requires another monero PR to be merged first though

uhm, so monero-gui/cmake/verison.cmake should have never been used?

right

rnhmjoj: selsta: sorry, i have to go right now. Will be back in a few hours

ok, see you later

rnhmjoj: i will double-check the case, so will remove just Version.cmake from monero-gui repo and see if there is something left that still uses it from monero repo

will let you know

xiphon: ok, thank you

rnhmjoj: found it. There is a combination of bugs. Another one: monero's Version.cmake uses wrong version.cpp.in file location (monero-project/monero #6867)

could you please do a test? remove monero-gui/cmake/Version.cmake

and apply the patch from monero-project/monero #6867 to monero-gui/monero/cmake/Version.cmake

xiphon: looks like CI failed

CMake Error: File /home/runner/work/monero/monero/src/src/version.cpp.in does not exist.

on it, will fix in a few seconds

updated

xiphon: that's good news. i'm building monero with the patch rn

rnhmjoj: let me know the results

sure thing. so, the problem is the variable is a reference to the root (which is monero-gui) but it should be monero, right?

xiphon: it seems to have worked. monero-gui is now building without manually patching the IS_RELEASE macro

"the problem is the variable is a reference to the root (which is monero-gui) but it should be monero, right?" -> right

rnhmjoj: thanks for reporting and testing all the stuff

xiphon: no problem, thank you for figuring it out. btw, i still don't understand why no one else noticed this: what exactly is triggering it?

"what exactly is triggering it?" -> didn't dig it further, my best guess is that due to some environment difference monero-gui/cmake directory gets searched first (instead of monero/cmake) from monero-gui/monero/CMakeLists.txt

something like CMAKE_PREFIX_PATH or another similar variables gets set improperty

Make due to different CMake versions (they sometimes change the behaviour between the releases)

What CMake version do you use?

s/Make/Maybe

"i still don't understand why no one else noticed this" -> as i said before, we even have a non-stopping CI running on each commit/PR, works just fine

on 3 operating systems

indeed

xiphon: cmake is 3.18. the explanation it make sense: nix adds a bunch of cmake flags by default and one must be doing it, though it not obvious to me: hastebin.com/raw/zedafotani

CMAKE_INSTALL_PREFIX

Looks like this is what breaks the search path

so monero-gui folder will be searched first

that also explain why the guix folk had the same problem. guix is surely setting the prefix in a similar manner

once we merge the patches mentioned earlier, it will work out of the box (by accident though, but still)

yeah, i'm leaving a comment to myself to remove the fix for the next release

xiphon: should we PR these to branch too?

else it will take a while until we can merge it in gui

are there any other fixes for monero core point release?

currently not

not good, point release just for these couple patches doesn't look good

would not do a monero core point release, just PR to branch and once we have more fixes we can do a release sometime in the future

yep, sounds good

I just meant that we won’t branch master to a release branch for at least 6 months or so

yep