02:13:50 <luigi1112> .merges
02:13:50 -xmr-pr- 8414 8425 8432 8433 8435
02:16:28 <luigi1112> what are we thinking about these others
02:16:35 <luigi1112> 7760
02:17:01 <luigi1112> 8426?
02:23:11 <jeffro256[m]> selsta: about your question yesterday: yeah you’re correct, OpenSSL 1.1 has a lot of the features we need for forwards compatibility without deprecating the older stuff 
03:53:39 <willshu[m]> <spirobel[m]> "can you post a link to the repo?" <- spirobel: Here is the repo: https://github.com/luigi1111/xmr.llcoins.net/blob/master/site/js/crypto.js
03:55:58 <willshu[m]> It seems it does not implement the `_free` function: `function _free() { }`
04:11:46 <selsta> .merge+ 8426
04:11:46 <xmr-pr> Added
04:11:54 <selsta> luigi1112: i would say let's include it
04:13:10 <selsta> it's been a year now and it's more well tested than any other patch and it significantly improves node connectivity
04:14:25 <TrasherDK[m]> <jeffro256[m]> "selsta: about your question..." <- The "without deprecating the older stuff" part gives me hope, that I can continue running nodes on all 3 networks 🙂 
04:18:30 <selsta> gingeropolous: master-beta contains other patches but it's included in there
04:29:15 <willshu[m]> <TrasherDK[m]> "I'm curious. How does this fit..." <- Please see my link above. It seems the crypto.js does not implement the `_free` function.
04:51:50 <TrasherDK[m]> Hmm. `function _free() {}`
06:09:19 <BigmenPixel[m]> Latest commit monero-gui:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/068983ae38d8f03e552b24f4011a54a43b624223)
06:33:30 <BigmenPixel[m]> * Latest commit monero-gui:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/fd443d0d72e00fbb95b6e1040342820433e99e10)
06:40:58 <selsta> BigmenPixel[m]: yes, it was merged accidentally
06:41:21 <selsta> it will be fixed tomorrow once we update the submodule l
06:41:29 <selsta> or later today
06:44:49 <selsta> i added it to the merge queue because i didn't want to forget it in the release but forgot to write a do not merge for now comment
06:48:41 <BigmenPixel[m]> <selsta> "BigmenPixel: yes, it was..." <- Okay, thank you.
06:49:33 <selsta> the patch is correct but requires us to update the monero submodule to v0.18
06:52:01 <r4v3r23[m]> now that 7760 has been decided can we tag/branch today?
06:56:42 <selsta> yds
06:56:44 <selsta> yes*
06:57:00 <selsta> once luigi wakes up and has time
06:57:19 <selsta> nothing left to decide at this point
06:57:49 <selsta> ledger users will have to continue using the old version due to their useless version lock, so that's something we have to warn about
07:03:49 <willshu[m]> <selsta> "once luigi wakes up and has time" <- Is luigi the author of https://github.com/luigi1111/xmr.llcoins.net/blob/master/site/js/crypto.js?
07:04:27 <selsta> he maintains the site but no idea if he wrote he code
07:04:31 <selsta> the
07:11:20 <willshu[m]> luigi1111: luigi1112 Can you take a look at the https://github.com/luigi1111/xmr.llcoins.net/blob/master/site/js/crypto.js? It seems it does not implement the _free function: `function _free() { }`, which causes a bug:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9265231f1bb59786749044f1a598df2bf17fc5c9)
09:21:55 <r4v3r23[m]> <selsta> "nothing left to decide at this..." <- whats the status of the rest of anon/ooo
09:22:05 <r4v3r23[m]> * of anon/ooo's ccs work?
09:22:44 <selsta> what status? there is a second rewrite patch that's not reviewed yet, but i have it in the master-beta branch as it works well
09:27:53 <r4v3r23[m]> was all the work completed/PRd? or were 7760/7999 the final bits?
09:30:41 <sech1> .merges
09:30:41 -xmr-pr- 8414 8425 8426 8435
09:31:24 <rbrunner> "was all the work completed/PRd?" Well, how would we know?
09:31:29 <sech1> I guess these 4 need to be merged, then branch and tag?
09:31:37 <selsta> there was way more than 3 months of work done
09:31:38 <selsta> sech1: yes
09:31:43 <sech1> as soon as luigi wakes up
09:32:15 <selsta> I have a Mac VPS now you can SSH into to debug the RandomX issue. Though at this point it's unclear if it's an OS bug or not.
09:32:34 <selsta> still trying to get everything setup.
09:32:35 <r4v3r23[m]> selsta: i see only 1st milestone was completed so wondering how much work is left on the p2p layer and if it will even happen given the recent issues dealing with ooo
09:33:21 <sech1> I'm not sure what to debug on Mac there, it's clearly a CPU cache invalidation not working
09:36:11 <selsta> any way to confirm that? wouldn't this also cause issues with other programs? so far everything works fine apart from randomx / monero
09:36:35 <selsta> i assume something like a browser would also show issues
09:37:18 <selsta> r4v3r23[m]: there is still a lot of daemon code left that needs work
09:38:54 <sech1> RandomX tests sometimes passing and sometimes not passing is a clear indicator
09:48:35 <selsta> Always call sys_icache_invalidate(_:_:) before you execute the machine instructions on a recently updated memory page. On Apple silicon, the instruction caches aren’t coherent with data caches, and unexpected results may occur if you execute instructions without invalidating the caches. It’s also safe to call the sys_icache_invalidate(_:_:) function on Intel-based Mac computers, where the function does nothing.
09:48:51 <selsta> I assume we do that already? Otherwise it wouldn't have only showed up after the OS update.
09:49:32 <selsta> I'm just surprised that I find nothing about this on Google and this sounds like a large issue.
09:55:51 <tevador> probably because RandomX is the only program that overwrites code pages rapidly
09:56:48 <selsta> There is a second issue that wallet sync crashes after a while, but I assume that wouldn't be related to cache invalidation?
09:57:38 <tevador> I don't think there is any JIT code in wallet sync code
09:57:51 <selsta> yep
09:58:20 <selsta> trying running monero tests now with MONERO_RANDOMX_UMASK=8, let's see
10:11:55 <sech1> "sys_icache_invalidate" xmrig calls it, and __builtin___clear_cache should also translate to it
12:08:11 <hyc> right, if that wasn't getting called it would already be failing on older MacOS
12:13:05 <hyc> does anyone know of any websites that make heavy use of WASM? hard to imagine they hadn't tested their browser against that, but you never know
12:13:36 <hyc> the other possibility is they've introduced some other syscall that must be used in advance to prepare for JIT use
12:29:52 <luigi1111> willshu[m]: yeah I didn't write that part, patches welcome
12:30:56 <selsta> hyc: https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon
12:32:17 <selsta> nothing here
12:32:17 <selsta> I noticed we don't add MAP_JIT to all mmap calls but that also didn't help
12:35:06 <hyc> yeah, the other mmap calls are only used for data, not to hold instructions
12:37:31 <hyc> ok, so the apple docs haven't changed at all
12:58:44 <selsta> hyc: so interestingly starting the intel version with rosetta works fine
13:00:41 <selsta> both monero wallet sync and xmrig benchmark
13:02:13 <selsta> ok, false alarm. monero wallet sync still crashes, but randomx works fine
13:06:34 <hyc> I wonder if freeBSD behaves the same way. macos and tcp/ip support seems really flaky
13:07:35 <selsta> hyc: now this makes it even weirder, the xmrig arm binary also works fine with jit
13:08:18 <hyc> hm, then that ought to mean we can find something xmrig did differently
13:08:31 <selsta> but i tried xmrig self compiled and it crashed
13:08:34 <hyc> but afaics the only thing was the explicit sys_icache_invalidate
13:08:41 <hyc> oh
13:08:48 <hyc> then a compiler flag is missing
13:09:42 <hyc> just like what sech1 pointed out https://github.com/SChernykh/p2pool/pull/189
13:09:55 <hyc> but for some other rev, not cortex-a53
13:11:23 <selsta> but wouldn't that compiler flag not also be missing on their release bins? they use the same cmake file
13:11:30 <hyc> hmmm
13:11:43 <hyc> if same flags, then different compiler version?
13:15:02 <selsta> it's a beta version of xcode so could be compiler bug
13:15:11 <selsta> can that cause a different hash on every run?
13:15:16 <selsta> still can't imagine how this work
13:15:23 <hyc> compiler bugs can break anything, who knows
13:16:26 <selsta> so for our release binaries it shouldn't matter since we use an older sdk
13:17:07 <hyc> can you try building xmrig with the old sdk?
13:18:07 <hyc> or randomx
13:18:11 <hyc> just to run its tests
13:19:06 <selsta> yes
13:21:34 <selsta> all pass, at least with intel version of rosetta
13:22:34 <selsta> apart from [90] Cache initialization: AVX2               ... SKIPPED but that's expected as rosetta doesn't support AVX2
13:30:02 <selsta> i can try compiling clang myself and see if i can reproduce the issue
13:32:32 <selsta> arm version of randomx-tests also pass so definitely compiler error
13:38:31 <hyc> ok, that's good to know
13:39:16 <hyc> hmmm. can you try just compiling to asm source and comparing the output of both compiler versions?
13:46:11 <selsta> for which file?
13:49:57 <hyc> good question. I have no idea where a compiler bug could cause this exact problem
13:51:04 <hyc> I guess jit_compiler_a64.cpp to start
13:52:30 <selsta> trying to compile clang13 first, which i know doesn't have this issue
13:52:47 <selsta> clang master did crash
13:53:26 <hyc> which version is apple using in macos 13?
13:53:39 <selsta> clang14
13:54:38 <hyc> might be worth opening a bug report on that even tho we haven't nailed it down. maybe someone else has already hit similar
13:55:58 <selsta> if it doesn't show up with clang13 i can bisect the issue
13:56:28 <hyc> cool
13:59:28 <selsta> also crashes with clang13 hmmmmmm
13:59:41 <selsta> doesn't make sense
14:01:09 <sech1> maybe it's random, try to run the version that passed a few more times
14:01:41 <selsta> i even managed to do randomx-benchmark for 1M hashes
14:02:03 <sech1> and it was green?
14:02:05 <selsta> yes
14:02:12 <sech1> then it definitely works
14:02:41 <selsta> i meant xmrig benchmark
14:04:47 <hyc> actual crash, or just wrong result?
14:05:20 <selsta> wrong result
14:06:01 <hyc> so same binary worked once, failed once?
14:06:11 <selsta> it does pass the sdk with -isysroot https://paste.debian.net/hidden/5f2d6d5d/
14:06:43 <selsta> no, self compiled always fails, compiled on macOS 12 seems to work
14:09:23 <hyc> compiled with clang13 on macos12? then that would imply some broken header file in SDK
14:10:45 <selsta> I should be able to download an older SDK
14:12:51 <selsta> lol specifying the old SDK solves it
14:13:38 <hyc> macos12 sdk works?
14:13:44 <selsta> 11.3 was the latest here https://github.com/phracker/MacOSX-SDKs/releases/tag/11.3
14:13:49 <hyc> ah
14:13:54 <selsta> 12 works too, 13 fails
14:16:43 <hyc> so, no compiler bug, just an apple bug
14:17:32 <hyc> might try comparing nm output between the two binaries, see if all library calls are the same
14:22:20 <selsta>                  U ___clear_cache
14:22:24 <selsta> is missing on the broken binary
14:27:00 <selsta> oh wait but it does have _sys_icache_invalidate instead hmm
14:27:33 <selsta> wait, have to undo my changes to the repo
14:30:59 <selsta> nm output looks identical, apart from different addresses sometimes
14:31:37 <selsta> might be best to ignore this for now and see if it's fixed in the next beta
14:32:12 <hyc> well, if you can send feedback on the beta, might be good to draw attention to it
14:33:40 <hyc> if nm output is basically identical, can't imagine what actually broke. would have to be a #define or a template or somesuch
15:10:28 <selsta> I'll still try to find the exact SDK that first introduced the issue
15:10:45 <selsta> .merges
15:10:45 -xmr-pr- 8414 8425 8426 8435
15:10:56 <selsta> luigi1111: i think we can branch and tag
15:21:00 <luigi1112> k
15:21:09 <luigi1112> just these 4?
15:21:43 <r4v3r23[m]> LFG
16:27:17 <hyc> I wonder if the gitian cache really needs to differentiate releases
16:27:59 <hyc> it's rebuilding all dependencies now, for monero-linux-0.18 instead of using what was built for monero-linux-0.17
16:28:20 <hyc> seems unnecessary
16:28:35 <hyc> * depends cache
16:31:10 <sech1> Hmm, all merged? If I build right now from latest master, will the binaries be exactly the same as after branch and tag (assuming no more commits to the branch)?
16:31:57 <hyc> I think they should be, not sure
16:32:04 <hyc> I'm building master now anyway
16:32:34 <hyc> branch should have same commit hash so would expect to be identical
16:32:45 <sech1> Commitd IDs should be the same
16:32:48 <sech1> yeah
16:34:55 <selsta> but the version string won't be identical
16:35:05 <selsta> so the hashes also won't match
16:35:11 <hyc> oh, right
16:35:21 <hyc> master vs v0.18-release
16:36:55 <sech1> hmm, then I'll tag v0.18 in my cloned repo and build :D
16:37:15 <selsta> using the xcode 14 SDK on an older macOS version doesn't seem to cause any JIT related issues, so it's seem to be a combination of OS and SDK bug
16:37:54 <hyc> that's bizarre
16:38:50 <selsta> writing a bug report now but I'm doubtful they will look at it
16:39:12 <hyc> in randomx source, comment out the __isOSVersionAtleast() function
16:39:28 <hyc> since you're building natively, it will use the platform SDK's copy instead
16:44:36 <hyc> the __builtin_available() check got a lot more complicated on newer SDKs. which is kind of the opposite of what you'd want, but so it goes
16:45:56 <selsta> same with it commented out
16:48:20 <hyc> ok. so it's definitely them and not us ;)
17:01:57 <luigi1112> branching?
17:02:07 <selsta> yesy
17:02:31 <sech1> what was the MacOS SDK url for gitian builds?
17:02:39 <selsta> not necessary anymore
17:02:55 <sech1> nice
17:03:05 <sech1> I'm already building from my cloned repo with the tag :D
17:03:15 <sech1> not sure it will be the same binaries
17:04:55 <luigi1112> branch is up
17:05:00 <luigi1112> can tag now or soon
17:06:16 <sech1> ah, my build will have version string v0.18.0.0-master so no, not the same
17:06:22 <sech1> waiting for the real tag then
17:06:37 <selsta> when you checkout a tag it only writes the tag, not the branch
17:06:39 <selsta> so should be fine
17:06:45 <sech1> ok
17:07:49 <selsta> luigi1112: let's wait for tests to finish
17:08:27 <luigi1112> :thumbs_up:
17:20:29 <hyc> my current build on master https://paste.debian.net/1247318/
17:20:37 <hyc> I'll stop this and switch to the branch 
17:24:28 <selsta> without tag it will still be the wrong hash
17:24:39 <selsta> if you create the tag yourself it should be good
17:24:43 <hyc> good point
17:24:57 <sech1> 2022-07-15 17:24:24.996 I Monero 'Fluorine Fermi' (v0.18.0.0-release)
17:25:01 <sech1> running on my server now
17:25:06 <sech1> this is from my repo with tag
17:25:14 <sech1> still building other binaries
17:26:49 <hyc> ok restarted build with tag
18:22:00 <sech1> selsta luigi1112 tests finished
18:22:25 <selsta> ok let's tag
18:23:02 <sech1> I'm already finishing the build, will publish hashes soon. But those are preliminary, I'll start a new build with the official tag later
18:25:24 <hyc> this is what I have so far https://paste.debian.net/1247325/
18:25:32 <hyc> Mac still building. using my own tag
18:26:52 <sech1> you have wrong file names
18:27:09 <sech1> monero-aarch64-linux-gnu-b6a029f22.tar.bz2 should be monero-aarch64-linux-gnu-v0.18.0.0.tar.bz2
18:27:18 <sech1> and hashes don't match what I have so far
18:27:20 <hyc> doh
18:27:32 <hyc> ok then I'll start over
18:28:02 <sech1> I tagged in my forked repo and building with the tag from the same commit ID, so my hashes should in theory be correct
18:28:33 <sech1> my hashes so far: https://paste.debian.net/hidden/7b6c43d2/
18:35:23 <hyc> ah, I needed to create an annotated tag, but I only created a plain tag
18:37:30 <sech1> my hashes: https://paste.debian.net/hidden/2c2ada14/
18:37:36 <sech1> waiting for the official tag now
18:40:56 * al800[m]1 uploaded an image: (9KiB) < https://libera.ems.host/_matrix/media/r0/download/0wnz.at/PzXZlQXzmiJQwiUNhrBbxFHU/image.png >
19:24:23 <hyc> ok I fixed my tag and now my hashes match yours sech1
19:49:26 <selsta> are you available luigi1111 to do the tag?
19:49:43 <selsta> also why do 3 luigis exist suddenly
20:10:25 <luigi1112> what's the name of this thing
20:12:01 <sech1> v0.18.0.0 I think
20:13:39 <selsta> Fluorine Fermi
20:13:44 <selsta> wait, let my copy paste it
20:14:00 <luigi1112> I already pushed
20:14:02 <selsta> Fluorine Fermi
20:14:09 <luigi1112> feel free to correct and we can do a classic force push
20:14:20 <luigi1112> oh indded
20:14:32 <selsta> yes you have a typo
20:14:58 <luigi1112> sorry what
20:15:17 <selsta> what would we do without force push
20:16:51 <rbrunner> Typo where?
20:17:13 <sech1> I already started a build
20:41:54 <hyc> I started a new build too, but since the tag name hasn't changed, should just get the same result again
20:49:44 <hyc> yeah, my linux builds just finished, same hashes as before
20:51:12 <sech1> I just realized I deleted all build folders to make a new build so I'll need to wait until the build is finished to get my gitian.sigs :D
20:53:18 <sech1> yep, getting the same hashes too
21:57:54 <dartian[m]> when is the ring size increase to 16?
21:59:46 <selsta> in about 1 month
22:10:14 <dartian[m]> https://www.coinspeaker.com/monero-hard-fork-july/
22:10:15 <dartian[m]> <selsta> "in about 1 month" <- thank you. I was trying to find information but only found an article stating that it was planned for tomorrow 
22:10:43 <selsta> we pushed back the date
22:12:54 <dartian[m]> I understand. thank you. I was even looking in the code and see ring size is 16 in some files
22:12:54 <dartian[m]> https://github.com/monero-project/monero/blob/67e5ca9ad6f1c861ad315476a88f9d36c38a0abb/tests/functional_tests/cold_signing.py
22:12:54 <dartian[m]> https://github.com/monero-project/monero/blob/67e5ca9ad6f1c861ad315476a88f9d36c38a0abb/tests/functional_tests/transfer.py
22:12:54 <dartian[m]> https://github.com/monero-project/monero/blob/f96cf865329ac5b9847264b222aa8e48192328a0/tests/functional_tests/multisig.py
22:20:22 <sech1> build finished, hashes were the same: https://paste.debian.net/hidden/2c2ada14/
22:21:32 <sech1> https://github.com/monero-project/gitian.sigs/pull/189
23:28:55 <selsta> it seems that libboost_atomic-mt is a dependency of libboost_filesystem-mt. does that mean monero should also link against libboost_atomic-mt?