17:45:36 Research meeting in -lab starts at 18:00 UTC (15 minutes from now) 17:53:57 hi 17:55:23 my mingw64 is closing after trying to build using source ./build.sh release-static 17:55:33 where can I see a log error? 18:11:03 rating89us: Is the monero-gui folder in C:/ ? 18:11:16 Is it top level directory? 18:11:31 Also can you try `./build.sh release` 18:11:47 without source and static and without make deploy 18:31:30 test 18:31:58 test failed 18:32:05 thanks! 19:21:40 Now I get '/mingw64/bin/libicudt64.dll': No such file or directory 19:21:57 there is a libicutud65.dll in my dir 19:23:21 do I need to downgrade? 19:24:25 What is the exact you used? 19:24:55 exact command? 19:24:55 all files in my dir are version 65 19:25:17 make deploy 19:25:33 git clone https://github.com/monero-project/monero-gui.git 19:25:38 cd monero-guisource ./build.sh release-staticcd buildmake deploy 19:25:46 monero-gui does not expect you to have an up-to-date MSYS2. I feel like it's always been that way. 19:26:24 Modify windeploy_helper.sh accordingly. 19:27:58 I think you just do `./build.sh release` 19:28:13 https://paste.debian.net/hidden/3c65d213/ 19:28:14 no make deploy step is necessary 19:28:29 make deploy is necessary. 19:32:04 Now when I open monero-wallet-gui.exe I get can't find libzstd.dll 19:32:24 Have a look at my paste. 19:32:40 I’m trying to compile in a Windows VM currently. Will update the repo if some steps are necessary. 19:36:24 iDunk: see the windows build script: https://github.com/monero-project/monero-gui/blob/master/.github/workflows/build.yml#L36 19:36:30 that’s why I thought make deploy is not necessary. 19:37:26 iDunk: thanks, it worked with your windeploy_helper.sh 19:37:34 I mean, it's necessary if you want to run monero-gui outside of MSYS2. 19:44:16 rating89us: Btw you should join #monero-gui 19:46:25 iDunk: oh btw you seem familiar with Windows 19:46:56 do you want to help me debug why cmake can’t find openssl 19:47:25 64 bit build ? 19:47:31 I added Windows support here https://github.com/monero-project/monero/pull/6270/ 19:48:03 together with this PR: https://github.com/monero-project/monero/pull/6267 19:48:19 but it kept failing with cmake not finding openssl, the gui builds fine with exactly the same setup 19:49:10 logs are here: https://github.com/selsta/monero/commit/3a52f0fbabfb42f46e710882d925406e1dccc864/checks?check_suite_id=378861637 19:51:47 Is "update pacman" step handled accordingly ? 19:52:21 here you can see the branch: https://github.com/monero-project/monero/compare/master...selsta:windows-workflow-tmp 19:52:32 `msys2do pacman -Syu --noconfirm` looks correct 19:52:52 L46-L48 19:54:06 You have to terminate MSYS2 (not exit), and run pacman -Syu again. 19:54:45 the GUI script writes the same so I’m not sure if that’s the problem 19:55:06 https://github.com/monero-project/monero-gui/runs/378548907 20:08:07 L15 in build "-D MSYS2_FOLDER= ". Is the gui script using 6267 ? 20:09:56 it uses the equivalent https://github.com/monero-project/monero-gui/pull/2690 20:13:03 Maybe add "echo $MINGW_PREFIX" somewhere at the beginning of the script to see whare it thinks it is. 20:13:25 ok will try thanks 20:13:43 Anyway, I don't think $MSYS2_FOLDER is being set correctly. 21:16:31 iDunk: $MINGW_PREFIX is empty 21:17:19 weird thing is it also adds `"-D MSYS2_FOLDER=` for the GUI and it works fine, this whole thing is just confusing 21:19:29 The problem may be the non-interactive shell, as you can see in lines 12 and 13 in build step. 21:21:02 it says that for every step, I don’t think it is the problem, anyway thanks for looking into it 21:24:00 Every time cmake config cannot find openssl here is when I build the 32 bit release. I immediatelly know I forgot to fix the "-D MSYS2_FOLDER=" in Makefile. 6267 is supposed to fix that, but could be it doesn't work so well in non-interactive shells. 21:26:30 right that sounds plausible but the GUI uses the same non-interactive shell and builds the same monero (just with GUI-DEPS) and it finds openssl there 21:26:36 but I have a few more ideas I’ll try now 22:06:54 hi, Im wondering about this function get_last_n_blocks_weights() which leads to BlockchainLMDB::get_block_info_64bit_fields(). It is used for calculating max block size. Does it return the 100 blocks PREVIOUS to the current block, or INCLUDING the current block? 22:08:54 also used for penalty and fees 22:25:30 depends what you mean by 'current block' 22:25:44 If you mean the block in the process of being mined then no that wouldn't be included 22:25:55 if you mean the most recent block added to the chain then yes it would 23:32:05 is update_next_cumulative_weight_limit() used when someone wants to sync a new node (i.e. to verify block weights and so on)? If so, it seems pretty inefficient since every block seems to calculate the long term median twice (to get block B's long term weight it calculates the previous block's long term median, and then to get the cumulative median 23:32:06 for block B it calculates the long term median for B... move on to block C which will recalculate block B's long term median. Am I missing something here? 23:34:54 Is the median of 100000 blocks meaninglessly fast? 23:38:56 Fairly slow, but there's an incremental mode for the common case of pushing one block. 23:42:13 yeah that much makes sense, is there some other function used for syncing? Or are my premises flawed..