08:17:15 <xorqq[m]> My issue with accidentally sending my entire XMR balance to the fund has been resolved. Thanks a lot to binaryFate, and thanks to the entire team and volunteers for developing Monero. You guys rock. 
08:18:43 <binaryFate> <3
09:32:08 <mj-xmr[m]> <xorqq[m]> "My issue with accidentally..." <- This would make a great Reddit story... :)
10:37:06 <hyc> if you have an rpi3 or rpi4 please add your /proc/cpuinfo to this ticket https://github.com/monero-project/monero/pull/7979#issuecomment-937663280
12:32:45 <merope> hyc: commented with a 3B+ and a 4B
12:38:04 <hyc> merope: thanks. I should have been more specific: rpi3 or 4 running a 64bit OS
12:38:13 <hyc> the output you provided is both on 32bit OS
12:39:36 <merope> Wait what? Where do you see that?
12:39:45 <hyc> ARMv7l
12:39:48 <hyc> architecture 7
12:40:01 <hyc> should be archtiecture 8 for 64bit mode
12:43:48 <merope> Wtf, why is the official Debian Buster Desktop download still 32bit?
12:44:09 <merope> Grrrrr
12:52:40 <minthos> mine is a 3 but yes 32 bit OS
14:10:10 <hyc> I get the feeling the majority of Pi users are still on 32bit OS. makes it even less worthwhile to support them as 64bit machines
14:19:31 <mj-xmr[m]> <merope> "Wtf, why is the official..." <- Yeah. I ask myself the same question. They really should get with the times, if they mean to keep the market. But Off Topic.
14:20:25 <mj-xmr[m]> <hyc> "I get the feeling the majority..." <- I'm OK with this.
14:20:25 <mj-xmr[m]> But does it mean, that we're OK with the `depends` change of that PR, while dropping the `gitian` changes? Or do we drop the PR completely?
14:20:33 <mj-xmr[m]> 7979
14:22:37 <hyc> I think we drop it and tell Pi users to just run the armv7 binaries
14:23:04 <hyc> I can work up a patch to do a cpuid check later. not that hard. https://www.kernel.org/doc/html/latest/arm64/cpu-feature-registers.html
15:10:29 <rbrunner> A testnet daemon that I run right now sees a peer that claims to be 2.4 years ahead, on block 2465686, but does not take the bait. How funny.
15:11:04 <rbrunner> Ah, that's current mainnet height.
15:12:01 <rbrunner> Is it really easy to run with --testnet but use the mainnet blockchain file if that's in the right directory location?
15:22:17 <moneromooo> The genesis blocks are different.
15:43:40 <sech1> moneromooo can you give me context about https://github.com/monero-project/monero/commit/f4a745d3b156e7ae44b557b031aeed38450b3c14 ?
15:44:04 <sech1> I got some reports about crashing monerod.exe built from the latest release-v0.17 and older monerod.exe doesn't crash for them (without this commit)
15:48:43 <minthos> ah, thread synchronization bugs are always such fun to figure out
15:49:57 <sech1> does "if (in_dispatch)" even trigger at all? I don't see how it could be called recursively
15:50:32 <sech1> but it could be called from multiple threads
15:56:30 <moneromooo> It just prevents early out when called reentrant, missing logs.
15:56:49 <moneromooo> er
15:57:23 <moneromooo> If you call in multiple threads, since the "I'm in" flag isn't per thread, a thread's log will be ignored if another is logging at this time.
15:57:33 <moneromooo> The flag is here to early out the reentrant calls.
15:57:49 <moneromooo> But it was weeding out too much. Making the falg per thread fixes this.
15:57:58 <sech1> I understand that, but is this function thread safe?
15:58:33 <moneromooo> I'd imagine so.
15:58:36 <sech1> I'll wait until the user with crashing monerod recompiles from release-v0.17. Maybe it's something with my gitian build that went wrong
15:59:01 <moneromooo> It's supposed to be thread safe, but there can always be bugs.
17:46:10 <mj-xmr[m]> <hyc> "I can work up a patch to do a..." <- This would be great. Rpi3 users are in a bad position to compile from source, but Rpi4 64-bit users can do it within 2 hours, even on a 2 GB system, if they use just 1 core.
19:08:57 <hyc> I thought rpi3 has only 1GB RAM. not a great time using that.
19:11:30 <mj-xmr[m]> hyc: I'm talking about Rpi4. Rpi3 users can use our distributed binaries.
19:13:12 <hyc> right
19:13:20 <hyc> just that it wouldn't be much fun running them either
19:14:06 <hyc> 512MB for 2 randomx caches
19:14:45 <hyc> doesn't leave much for everything else monerod needs to do
19:20:54 <midnightmage[m]> Hi, I’m looking to get some exp with open source and have 7+ years on c++ and python, do you guys have any tasks I could help you guys out with?
19:21:31 <moneromooo> Hi
19:22:32 <moneromooo> I guess you could trawl the github issues list for things to debug/investigate. Or just start using the software, and fix what is broken or could be improved - basically scratch your itch.
19:22:32 <midnightmage[m]> How’s it going?
19:23:52 <midnightmage[m]> Thanks, I’ll check those out
19:28:20 <hyc> I feel like at this stage in our evolution, we should be asking every potential new contributor "are you secretly working for any government agency (e.g. NSA)?"
19:29:30 <Rucknium[m]> I'm sure that question would elicit honest responses every time.
19:30:17 <hyc> documenting it as public record, could come in handy if needed in the future
19:30:41 <moneromooo> hyc: are you secretly working for any government agency ?
19:30:49 <hyc> nope
19:31:00 <moneromooo> hyc: are you secretly working for any corporation ?
19:31:08 <hyc> not secretly ;)
19:31:16 <moneromooo> sold!
19:31:28 <Rucknium[m]> We might want to think about a signaling model
19:31:28 <Rucknium[m]> https://en.wikipedia.org/wiki/Signalling_%28economics%29
19:31:55 * moneromooo hates shite that just breaks when modifying something completely unrelated...
20:37:55 <midipoet> I have asked some people that question, also the corporation question
20:42:06 <Rucknium[m]> I don't really see the benefit in that. Seems counterproductive, especially in light of
20:42:06 <Rucknium[m]> https://en.wikipedia.org/wiki/Bad-jacketing
20:53:14 <DataHoarder> I will 100% hoard the data
21:41:10 <midipoet> Rucknium[m]: that's an interesting link, thanks