09:03:47 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? 09:10:34 or is the change output a zero output sent to a dummy address 09:24:47 should be same as CLI 10:08:53 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 10:08:55 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 10:09:42 did you follow the readme? 10:09:57 what command did you enter? 10:10:54 selsta: yeah, following the readme was my first attempt :) 10:11:07 also which cmake version are you using? :D 10:12:11 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 10:12:17 cmake 3.16.5 10:13:10 I doubt that 3.16.5 is too new, I use 3.18.2 10:13:33 can you do a fresh git clone, enter ./build.sh and post logs? 10:14:44 selsta: ah, I might have mixed something up. It was complaining about library_version_type which comes from boost (not cmake - my fault). Given https://github.com/monero-project/monero/blame/61dd04b68121b4057b4b88356761fbfb3fa73c90/src/wallet/wallet2.h#L38 I figured I need to build from master 10:15:16 master should build fine 10:15:24 see https://github.com/monero-project/monero-gui/runs/986292713 10:15:37 builds on all OS with cmake and qmake 10:17:46 hmm, I might know the problem 10:18:17 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" 10:18:24 sqozz: https://github.com/monero-project/monero-gui/blob/master/get_libwallet_api.sh#L20 10:18:36 change this to `git -C $MONERO_DIR checkout origin/master` 10:18:47 then it should work, the PR to change submodule to master is not merged yet 10:18:54 and the boost bugfix is only in master 10:20:01 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) :) 10:20:33 you "commented" the line? 10:20:53 can you try changing it to master? or did you manually change the submodule to master? 10:21:31 as a first step it might be a good idea to try to build monero-cli first https://github.com/monero-project/monero 10:21:36 as in "put a # in front of the line". And yes, afterwards I did a manual "git checkout master" for the monero submodule 10:21:58 did you do git fetch, git checkout origin/master ? 10:22:31 I had issues in the past when only doing `git checkout master` 10:22:40 no, just a "checkout master". Let me try this exercise again :) 10:23:52 also make sure to delete your build directory before retrying to avoid any weird problems 10:25:33 sure 10:49:21 alright so with the checkout removed from get_libwallet_api.sh (https://paste.opensuse.org/view/raw/4fb529f4) I'm back to the randomx issue. Here is a log of ./build.sh: https://paste.opensuse.org/view/raw/6d90cb38 10:50:15 why `LANG=C` ? 10:51:26 I don’t really see an error in the logs (apart from the linking issue), weird. 10:51:31 because I was stupid in the past and installed my system with a german locale 10:52:18 okay, different idea 10:53:03 remove the build folder and do `USE_SINGLE_BUILDDIR=ON DEV_MODE=ON make release -j3` 10:53:19 with master monero submodule checked out 10:55:40 and the linking error is kind of expected given how librandomx got installed: https://paste.opensuse.org/view/raw/2ba17912 10:57:09 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? 10:58:50 no 10:59:01 remove build folder inside monero-gui 10:59:14 and then just `USE_SINGLE_BUILDDIR=ON DEV_MODE=ON make`, qmake is not involved 10:59:26 we have two build systems currently because we migrate from qmake to cmake 10:59:38 understood, running now 11:05:20 FWIW, you are getting that error because libwallet-crypto.a is missing somewehere. It's a supercop submodule issue, not randomx. 11:11:19 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 ;) 11:26:15 selsta: unfortunately also no luck with make release, it now complains about QT_LINKED_OPENSSL: https://paste.opensuse.org/view/raw/a5e18be8 11:27:19 ah, but in /usr/include/qt5/Gentoo/gentoo-qconfig.h so most likely not related to monero-gui at all 11:35:15 sqozz: remove -Werror from CMakeLists.txt 11:35:22 seems to be gentoo related https://forums.gentoo.org/viewtopic-t-1099482-start-0.html 11:35:29 but removing -Werror might work 11:35:36 yeah, also found qt5-build.eclass 11:35:45 wrong buffer: https://bugs.gentoo.org/652650 11:40:54 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 11:49:33 nice, though not sure why it failed with qmake, does not matter I guess 11:51:48 if you're in the progress of switching away it really doesn't matter 14:35:41 Hi everyone, what's the release date of the Monero client 0.17.0.0? 14:36:09 Soon. 15:24:31 Hey grydz , the goal is by 9/17 15:24:42 Not sure if there have been changes, but that's been the goal for a while now. 15:34:28 Weekly meeting in #monero-research-lab is today at 17:00 UTC (about 90 minutes from now) 15:38:46 Is the testnet fork height already fixed? And where in the source are the fork heights defined? 15:39:48 not yet 15:39:54 and src/hardforks/hardforks.cpp 15:40:25 probably worth setting the testnet height soon tho 15:42:46 yes 15:43:01 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 :) 15:43:08 I'm sure the Ledger and Trezor teams need to set this in their code somehow? 15:44:56 Sounds logical. I don't think you can query the network for hardfork heights, or can you? 15:47:58 don't recall offhand 15:48:08 I would assume there's a daemon rpc for fork info 16:17:12 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! 16:18:49 Waiting till mainnet switch would defeat most of the point, would it not. 16:27:08 Sure ;) 16:41:51 Yeah, and whatever happened to beta-testing ... 17:53:07 yeah, testnet ought to have forked ... right around now 17:55:19 I wanted to fork it shortly after it got merged, but forgot. I'll PR now. 17:56:41 Forking in 24 hours is fine ? 18:00:59 sounds ok to me 18:01:15 anyone who is likely to squawk is probably in this channel 18:03:10 PRed, but still building. 18:06:04 ok I'm building it now too 18:06:11 hmm, haven't fired up testnet in ages 18:12:29 my monerod on ubuntu still has undef'd references to libgss_krb5 18:12:39 I thought someone patched this in cmake already? 18:16:15 -xmr-pr- moneromooo-monero opened pull request #6794: hardforks: add v13/v14 for testnet 18:16:15 -xmr-pr- > https://github.com/monero-project/monero/pull/6794 18:19:04 Rings a bell. 18:21:20 I think I scared them away by saying they should use zmq's pkgconfig file instead of just adding -lgss_krb5 18:22:10 hm, that's a good point 18:32:51 That's in about 24 hours then 18:33:06 Ah, saw you wrote it 18:33:22 Nothing to squawk from me :) 20:17:59 Quick update: the Trezor team plans to make a Monero codebase PR for Trezor support tomorrow 20:19:30 but otherwise it sounds like they will be ready to go 21:08:49 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 21:09:07 knaccc: ^ 21:09:28 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 21:09:53 this of course can be changed, but thats why its only used for wallets atm 21:10:39 vtnerd_ oh cool, so there is a speedup for wallet scanning but not for node tx verification 21:11:24 one idea would be to use ASM for initial sync and then switch to normal EC lib 21:11:47 as speed is only really relevant for the initial sync 21:12:05 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 21:14:07 so even more speeds up theoretically possible, nice :) 21:14:22 I think that makes more sense to investigate for now than GPU scanning 21:15:32 Interesting idea selsta. 21:15:38 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 21:16:01 moneromooo: would there be any major risks left? 21:16:15 also arm64 has the advantage of guaranteeing more SIMD instructions than base x86-64 iirc 21:16:21 if a different result gets calculated it would simply stop syncing? 21:16:30 Well, a different result for those blocks :) 21:16:54 But at least it's when people are likely to pay attention, not after htey leave their node unattended for a long while. 21:17:05 Yes. 21:17:21 also, with apple moving to arm, arm64 speedups could be useful