00:44:59 woot, got a 5x speed on dockerfile build 00:45:14 Building from source or using binaries? 00:45:15 * CCosta[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/srgWuECoUsyCeWBkvWJjXnoJ/message.txt > 00:45:22 from source 00:45:23 let me push 00:45:26 How? 00:45:31 Caching? 00:46:47 Please share Dockerfile 🙂 00:46:48 Have my own that would be great to reduce build time on if it doesn't have any major drawbacks. 00:47:23 yep! just finishing the commit message 00:47:46 > Caching? 00:47:46 not really, added a few missing `-j` and leveraged the concurrent dag resolution that `docker build` can do now 00:48:13 we _could_ improve iteration times via experimental caching, but that requires folks to set `experimental: true` in their daemn.json 00:48:17 daemon.json* 00:50:13 https://github.com/monero-project/monero/compare/master...cirocosta:dockerfile-improvs?expand=1 00:51:07 whops, missed uncommenting `zmq` and `protobuf` - interestingly, the build of monerod succeeds anyway 🤔 00:51:27 I didn't even realize there was an "official" Dockerfile 0.o 00:51:47 it isn't really maintained 00:52:21 Wow that commit makes it a very complex Dockerfile 00:52:22 protobuf is only needed for trezor/ 00:52:46 trezor/ledger support 00:53:00 yep, and looking at the gitian setup .. it makes me nervous of having essentially builds in multiple places 00:53:32 (if we could have a very simple repro builds for both - as simple as `docker build` with args for each arch) 00:53:49 should just take the gitian images, snapshot them in docker. 00:54:26 That's a very cool approach to reduce build time but certainly adds a lot of complexity. 00:55:00 Might take a stab at adding that functionality to mine: https://github.com/sethsimmons/simple-monerod-docker/blob/main/Dockerfile 00:58:05 we don't need cppzmq any more 00:58:30 would that just require `docker` and nothing else though? 00:58:49 I feel like if we get close to "all you need is `docker build`", we could have more people contributing to gitian, as well as any other contributions 00:58:53 * I feel like if we get close to "all you need is `docker build`", we could have more people contributing to gitian, as well as any other form of contributions 00:59:44 probably a little more complicated than that, but maybe not. since currently we have that gitian-build python script driving the depends build system 00:59:45 ^ more people contributing to gitian-sigs, I mean (looking at `build.py`, it looks like there's a lot going on 🤔 00:59:52 I see 00:59:59 if they were embedded in the docker image I suppose it could be done 01:00:20 does docker inside docker work ok performance wise? 01:00:27 I've never tried it 01:01:29 It'd be really nice to have something that is indeed simple like sethsimmons pointed out, but that is also reproducible. maybe we could do it in a way that one would opt into multiple archs (for posting results to gitian-sigs), but still, leaving that as an opt-in 01:01:38 being able to reuse a base image with all the common tarballs and source repos would save a little time 01:02:02 it _should_, after all, it's just linux cgroups namespaces etc 01:02:07 build one target set, wipe the overlayfs, and start over for the next target 01:02:41 Did you know that all witdraw-buyer-seller-depoist chains are trackable in Monero? No? You should have read Breaking Monero. How many people are you endangering with your 'privacy' coin? 01:14:36 I was looking at the gitian configs here, and https://github.com/monero-project/monero/blob/f6279a633d4bdf46f81fed835656d3386fb9cade/contrib/gitian/gitian-linux.yml#L8-L15 doesn't include the version of those packages, so I imagine that's not really _reproducible_ as, e.g., `ubuntu xenial` might get CVE patches to those packages 01:14:41 am I missing something? 01:16:40 or because those are packages for build-time tooling (compiler,s etc), that shouldn't affect the final outcome? (I'd expect that GCC wouldn't promise a byte-per-byte guarantee, curious to know if it's not the case) 01:19:22 (I get that at the end, under the `gitian.sigs` repo we have the exact version of each `.deb`, I was just curious to know if it's the intention to also be able to rebuild these binaries in the future, or just verify that a particular build that we release has been built and asserted to be the same by various folks in the community) 01:24:58 I've commented on this flaw a few times before. you're right. there's no guarantee that building this stuff in the future will produce the same bits. 01:25:47 it's a tradeoff of perfect reproducibility vs getting potential CVE patches 01:26:49 it's also why we want as many people as possible to build at the time of the release 01:27:11 so we can be sure of the build at that point in time 01:28:35 was there any research into using/supporting gnunet? I tried searching around for any discussions and couldn't find much more than a few randos commenting 03:37:20 i wonder how large the network is 03:58:08 same 04:00:29 admittedly, i hear that gnunet sucks to work with, but i had to ask 10:02:14 RE: Reproducible builds, I think that if you build through a VM, it could reduce the build times, if you install VBox Guest Additions and enable full virtualization. 10:03:10 Settings -> System -> Processor -> Tick Enable Nested VT-x/AMD-v 12:26:46 Of course you need to switch on virtualization in your BIOS before. 13:16:20 GUI v0.17.2.1 bins are on the website 13:16:35 Sweet! 13:36:04 sethsimmons: heads up - https://sethsimmons.me/guides/run-a-monero-node-advanced/run-a-monero-node.md is 404'ing 13:36:11 sethsimmons: linked from https://sethsimmons.me/guides/run-a-monero-node-advanced/ 13:41:32 Do you think that you are too intelligent to be in a cult? Then I would encourage you to look into how any other cult works. They aren't populated by stupid people. Aum Shinrikyo was almost exclusively university professors and graduates. For Pete's sake - they had the know-how and means to make WMDs. 13:41:32 As to Monero, I would encourage you to look at Jonestown mass-suicide. You know why Jones killed them all? Because he was afraid he is loosing control over them. People like that will burn everything around them rather than give up control. Being smart doesn't make you immune to being in a cult. This is the most valuable lesson Monero taught me. 13:59:34 binaryFate, https://www.getmonero.org/blog/tags/releases.html still shows v0.17.2.0 14:05:45 yea the blog post didn't get merged 14:07:26 Fixed, thanks for the note :) 14:08:04 tobtoht, just a heads up, featherwallet.org is on the fritz. 14:08:28 "An error occurred during a connection to featherwallet.org. PR_END_OF_FILE_ERROR" 14:08:52 ferretinjapan: thanks, I'm aware. Our hosting provider is performing a network upgrade. 14:10:03 ah, no probs then 14:15:16 might be worth having a status page (status.featherwallet.org) 14:15:34 probably overkill for a small static site 14:15:40 fair 14:22:29 Haven't gotten around to setting up a fallback host yet, but I'll get that sorted soon. 16:34:17 Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? https://twitter.com/hyc_symas/status/1203709575226183683 17:05:09

binaryFate, https://www.getmonero.org/blog/tags/releases.html still shows v0.17.2.0 <-- fixed 17:05:24 Cool 21:13:50 * CCosta[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/ZoTbqCDUXRxqfiUfNDfTropJ/message.txt > 21:17:03 Not enough large pages AFAICT. 21:17:28 Allocate more, free memory. monerod also hashes when verifying new blocks. 21:19:57 Allocation is in /proc/sys/vm IIRC. 21:19:58 iinteresting, makes sense - indeed, looking at `/proc/meminfo`, there's nothing left once I start xmrig 👍️ thnaks moneromooo 21:27:02 doubled `vm.nr_hugepages` - worked like a charm 👍️