in the GUI, if you send a tx and for the amount choose "send all", does the change output go back to your wallet, or are both outputs sent to the destination?

or is the change output a zero output sent to a dummy address

should be same as CLI

hey all. I'm currently trying to compile monero-gui on my gentoo box. Apparently my cmake is to new so I can't build the latest release (0.16.3) but have to switch to master. I was playing around and realized that librandomx can't be found because it gets installed into monero/lib64. After copying it to monero/lib the build continues but now throws errors about a missing reference to

monero_crypto_amd64_64_24k_generate_key_derivation and I started to wonder if there is any supported way to build master and not a release

did you follow the readme?

what command did you enter?

selsta: yeah, following the readme was my first attempt :)

also which cmake version are you using? :D

selsta: `LANG=C QT_SELECT=5 ./build.sh` most of the time. While playing around I was building single components with the according cmake+make commands just to speed debugging up but for the "final test" I always used build.sh

cmake 3.16.5

I doubt that 3.16.5 is too new, I use 3.18.2

can you do a fresh git clone, enter ./build.sh and post logs?

selsta: ah, I might have mixed something up. It was complaining about library_version_type which comes from boost (not cmake - my fault). Given github.com/monero-project/monero/bl…fb3fa73c90/src/wallet/wallet2.h#L38 I figured I need to build from master

master should build fine

see github.com/monero-project/monero-gui/runs/986292713

builds on all OS with cmake and qmake

hmm, I might know the problem

selsta: slap me if I totally misunderstand something but the linked job also builds the latest tag/release, no? "You are building a tagged release"

sqozz: github.com/monero-project/monero-gu…lob/master/get_libwallet_api.sh#L20

change this to `git -C $MONERO_DIR checkout origin/master`

then it should work, the PR to change submodule to master is not merged yet

and the boost bugfix is only in master

selsta: I commented the line in my attempt but then I end up with the issue I talked about in the beginning about a missing/wrongly installed librandomx.a (in monero/lib64 instead of monero/lib) :)

you "commented" the line?

can you try changing it to master? or did you manually change the submodule to master?

as a first step it might be a good idea to try to build monero-cli first github.com/monero-project/monero

as in "put a # in front of the line". And yes, afterwards I did a manual "git checkout master" for the monero submodule

did you do git fetch, git checkout origin/master ?

I had issues in the past when only doing `git checkout master`

no, just a "checkout master". Let me try this exercise again :)

also make sure to delete your build directory before retrying to avoid any weird problems

sure

alright so with the checkout removed from get_libwallet_api.sh (paste.opensuse.org/view/raw/4fb529f4) I'm back to the randomx issue. Here is a log of ./build.sh: paste.opensuse.org/view/raw/6d90cb38

why `LANG=C` ?

I don’t really see an error in the logs (apart from the linking issue), weird.

because I was stupid in the past and installed my system with a german locale

okay, different idea

remove the build folder and do `USE_SINGLE_BUILDDIR=ON DEV_MODE=ON make release -j3`

with master monero submodule checked out

and the linking error is kind of expected given how librandomx got installed: paste.opensuse.org/view/raw/2ba17912

the build folder inside monero-gui you mean, right? And I guess I need "qmake ../monero-wallet-gui.pro CONFIG+=release" before "USE_SINGLE_BUILDDIR=ON DEV_MODE=ON make", no?

no

remove build folder inside monero-gui

and then just `USE_SINGLE_BUILDDIR=ON DEV_MODE=ON make`, qmake is not involved

we have two build systems currently because we migrate from qmake to cmake

understood, running now

FWIW, you are getting that error because libwallet-crypto.a is missing somewehere. It's a supercop submodule issue, not randomx.

iDunk: yeah the missing reference seems to be provided by supercop. But since I had to tinker around so much to reach that point I figured I might miss something before which is causing this missing reference ;)

selsta: unfortunately also no luck with make release, it now complains about QT_LINKED_OPENSSL: paste.opensuse.org/view/raw/a5e18be8

ah, but in /usr/include/qt5/Gentoo/gentoo-qconfig.h so most likely not related to monero-gui at all

sqozz: remove -Werror from CMakeLists.txt

seems to be gentoo related forums.gentoo.org/viewtopic-t-1099482-start-0.html

but removing -Werror might work

yeah, also found qt5-build.eclass

wrong buffer: bugs.gentoo.org/652650

with the define removed in /usr/include/qt5/Gentoo/gentoo-qconfig.h it was able to build successfully \o/ thanks a lot for your help

nice, though not sure why it failed with qmake, does not matter I guess

if you're in the progress of switching away it really doesn't matter

Hi everyone, what's the release date of the Monero client 0.17.0.0?

Soon.

<grydz "Hi everyone, what's the release "> Hey grydz , the goal is by 9/17

Not sure if there have been changes, but that's been the goal for a while now.

Weekly meeting in #monero-research-lab is today at 17:00 UTC (about 90 minutes from now)

Is the testnet fork height already fixed? And where in the source are the fork heights defined?

not yet

and src/hardforks/hardforks.cpp

probably worth setting the testnet height soon tho

yes

Thanks, hyc. I was searching everywhere except for its own folder ... I also think forking soon is probably a good idea. After all, we had September 17 as tentative date for the release :)

I'm sure the Ledger and Trezor teams need to set this in their code somehow?

Sounds logical. I don't think you can query the network for hardfork heights, or can you?

don't recall offhand

I would assume there's a daemon rpc for fork info

Thanks sethsimmons. Would be great if the hardfork height for v13 on testnet could be set to approximately the release date of 0.17.0.0!

Waiting till mainnet switch would defeat most of the point, would it not.

Sure ;)

Yeah, and whatever happened to beta-testing ...

yeah, testnet ought to have forked ... right around now

I wanted to fork it shortly after it got merged, but forgot. I'll PR now.

Forking in 24 hours is fine ?

sounds ok to me

anyone who is likely to squawk is probably in this channel

PRed, but still building.

ok I'm building it now too

hmm, haven't fired up testnet in ages

my monerod on ubuntu still has undef'd references to libgss_krb5

I thought someone patched this in cmake already?

Rings a bell.

I think I scared them away by saying they should use zmq's pkgconfig file instead of just adding -lgss_krb5

hm, that's a good point

That's in about 24 hours then

Ah, saw you wrote it

Nothing to squawk from me :)

Quick update: the Trezor team plans to make a Monero codebase PR for Trezor support tomorrow

but otherwise it sounds like they will be ready to go

selsta : I didn't use ASM speedupds for node synching at luigi's suggestion. the concern was over multiple ed25519 implemenations and possible chain forking

knaccc: ^

it would suggest a bug in either implementation, which is pretty serious, but I then decided to do the "safe" approach and only use it for wallets

this of course can be changed, but thats why its only used for wallets atm

vtnerd_ oh cool, so there is a speedup for wallet scanning but not for node tx verification

one idea would be to use ASM for initial sync and then switch to normal EC lib

as speed is only really relevant for the initial sync

there's also the possibility of extending stuff with SIMD ops - the ASM assumes base x86-64 only. I haven't done much investigation into that though; donna64 has some SSE2 speedups that bump it above the ASM we use

so even more speeds up theoretically possible, nice :)

I think that makes more sense to investigate for now than GPU scanning

Interesting idea selsta.

ok, just took a quick looks. I think all of the accelleration is in choose_t SIMD ops, which is the obvious thing I was going to try

moneromooo: would there be any major risks left?

also arm64 has the advantage of guaranteeing more SIMD instructions than base x86-64 iirc

if a different result gets calculated it would simply stop syncing?

Well, a different result for those blocks :)

But at least it's when people are likely to pay attention, not after htey leave their node unattended for a long while.

Yes.

also, with apple moving to arm, arm64 speedups could be useful