There was already a thread titled "NEW net/monero", https://marc.info/?t=173064446700004&r=1&w=2 . Direct any follow up to that thread instead. There is no point in having more than one.
On Sun, Dec 15, 2024 at 09:26:43AM +0000, Stepan Zolotuev wrote: > Hi all, > > There's been quite a bit of progress on the Monero port since I've last > sent in to ports@: Given that there is already a fairly complete proposal around, it would have been better if you shared a well-done diff instead. (The current one isn't usable, because there are chunks relocations and whitespaces changes, making it quite difficult to compare the changes.) > - Incorporated most advice that was on this mailing list. > > - Added pkg/README. This is mostly fine. (I'm a bit against /etc/monerod.conf--more on that below). > - Added DEBUG_PACKAGES. I have mixed feelings about it. I don't think it's that useful once the port is complete, and it isn't a super expensive port to build. > - Added more SITES entries. I'm not aware of any clearnet monero > mirrors, so I added the official Tor mirror and an unofficial I2P one. > (Are we fine with non-clearnet mirrors?) Nothing in base can fetch this. This is a no-go. > - Moved monerod from bin to sbin, since it is a server daemon. No strong opinion in here, other than this relies on the post-install: target that your proposal adds. Given this isn't a hard requirement, I do feel like that adding a post-install for it is free maintainance burden. Did you discuss that with your comaintainer? > - Figured out all dependencies the port really needs. This are the TDEPs. You also removed net/miniupnp/miniupnpc from BDEPs. Why? > - libwallet.a and the includes were kept for some time in the future, > when other wallets may be ported. https://marc.info/?l=openbsd-ports&m=173073392030161&w=2 . In principle, I stand with Stuart. But there is the reality that the includes are installed nevertheless. So I'm fine with either installing both the headers and the lib, or none, but not the current situation. > - The daemon no longer thrashes the entire system during sync. This was > caused by the --prep-blocks-threads option, which is set to 4 by > default. In the rc script it is set to 1, but can be overridden to > increase performance. It is mentioned in pkg/README. I'm quite certain that prep-block-threads didn't do anything for me on some experiments I ran in the past. The only thing that did help a lot was Niklas suggestion of using db-sync-mode=fast:async:10000. My system does still see stalls, but they aren't as bad as without it. > - Most upstream tests now pass, except for four. The test log is > attached. I'll be checking this thru the week. > I still haven't figured out what to do with the ~300GB space > requirement. On my machine I partitioned /var to be 700GB, so > "/var/monero" is fine with me. But in default install of OpenBSD it is > below 5GB, so I'm asking the knowledgeable-- what would be the most > sensible place for 300GB of binary data in the default installation of > OpenBSD? The only such space is /home, which is at most 300GB, asuming that the disk is big enough. People already have to plan in advance for storage in order to use Monero; they will also need to work their partition tables. Missed in your list and aren't minor: Added security to CATEGORIES. In my opinion, this doesn't belong there. net makes sense because it's a peer-to-peer application. databases could be added, but none of the other cryptocurrencies use it. Why did you add DPB_PROPERTIES=parallel? I'd leave that in the hands of bulk builders. Why disable USE_CCACHE? : .if ${MACHINE_ARCH} != "amd64" : CONFIGURE_ARGS += -DNO_AES=ON : .endif Why is this chunk included? You dropped the patch dropping -Ofast. We stick with our compiler flags in general. There was a rework of the rc file. I'm against defining daemon_flags, as that interferes with the mechanism of rc and 'rcctl start monerod' works without a previous enable. It doesn't starts automatically, at least. Also, in my opinion, those parameters work best in the README; they're suggestions. Added yourself as a MAINTAINER. Given that the proposed port already had maintainer, it's a good idea to ask the current maintainer if they feel alright with it. Also, I guess you, as a new maintainer, are already taking a look at how to patch it for boost-1.87.0, aren't you? ^^
