woot, got a 5x speed on dockerfile build

Building from source or using binaries?

from source

let me push

How?

Caching?

Please share Dockerfile 🙂

Have my own that would be great to reduce build time on if it doesn't have any major drawbacks.

yep! just finishing the commit message

> Caching?

not really, added a few missing `-j` and leveraged the concurrent dag resolution that `docker build` can do now

we _could_ improve iteration times via experimental caching, but that requires folks to set `experimental: true` in their daemn.json

daemon.json*

whops, missed uncommenting `zmq` and `protobuf` - interestingly, the build of monerod succeeds anyway 🤔

I didn't even realize there was an "official" Dockerfile 0.o

it isn't really maintained

Wow that commit makes it a very complex Dockerfile

protobuf is only needed for trezor/

trezor/ledger support

<sethsimmons "Wow that commit makes it a *very"> yep, and looking at the gitian setup .. it makes me nervous of having essentially builds in multiple places

(if we could have a very simple repro builds for both - as simple as `docker build` with args for each arch)

should just take the gitian images, snapshot them in docker.

That's a very cool approach to reduce build time but certainly adds a lot of complexity.

Might take a stab at adding that functionality to mine: github.com/sethsimmons/simple-monerod-docker/blob/main/Dockerfile

we don't need cppzmq any more

<hyc "should just take the gitian imag"> would that just require `docker` and nothing else though?

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

* 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

probably a little more complicated than that, but maybe not. since currently we have that gitian-build python script driving the depends build system

^ more people contributing to gitian-sigs, I mean (looking at `build.py`, it looks like there's a lot going on 🤔

I see

if they were embedded in the docker image I suppose it could be done

does docker inside docker work ok performance wise?

I've never tried it

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

being able to reuse a base image with all the common tarballs and source repos would save a little time

<selsta "does docker inside docker work o"> it _should_, after all, it's just linux cgroups namespaces etc

build one target set, wipe the overlayfs, and start over for the next target

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?

I was looking at the gitian configs here, and github.com/monero-project/monero/bl…trib/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

am I missing something?

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)

(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)

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.

it's a tradeoff of perfect reproducibility vs getting potential CVE patches

it's also why we want as many people as possible to build at the time of the release

so we can be sure of the build at that point in time

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

i wonder how large the network is

same

admittedly, i hear that gnunet sucks to work with, but i had to ask

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.

Settings -> System -> Processor -> Tick Enable Nested VT-x/AMD-v

Of course you need to switch on virtualization in your BIOS before.

GUI v0.17.2.1 bins are on the website

Sweet!

sethsimmons: heads up - sethsimmons.me/guides/run-a-monero-node-advanced/run-a-monero-node.md is 404'ing

sethsimmons: linked from sethsimmons.me/guides/run-a-monero-node-advanced

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.

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.

binaryFate, getmonero.org/blog/tags/releases.html still shows v0.17.2.0

yea the blog post didn't get merged

<CCosta[m] "sethsimmons: heads up - https://"> Fixed, thanks for the note :)

tobtoht, just a heads up, featherwallet.org is on the fritz.

"An error occurred during a connection to featherwallet.org. PR_END_OF_FILE_ERROR"

ferretinjapan: thanks, I'm aware. Our hosting provider is performing a network upgrade.

ah, no probs then

<tobtoht "ferretinjapan: thanks, I'm aware"> might be worth having a status page (status.featherwallet.org)

probably overkill for a small static site

fair

Haven't gotten around to setting up a fallback host yet, but I'll get that sorted soon.

Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? twitter.com/hyc_symas/status/1203709575226183683

<mj-xmr_> binaryFate, getmonero.org/blog/tags/releases.html still shows v0.17.2.0 <-- fixed

Cool

Not enough large pages AFAICT.

Allocate more, free memory. monerod also hashes when verifying new blocks.

Allocation is in /proc/sys/vm IIRC.

iinteresting, makes sense - indeed, looking at `/proc/meminfo`, there's nothing left once I start xmrig 👍️ thnaks moneromooo

doubled `vm.nr_hugepages` - worked like a charm 👍️