Hey,

I've been working on and off in a port for Monero for quite some time.
Thanks to your's and byteskeptical interest, I got back to it and now I
have a working port attached here.

On Thu, Aug 15, 2024 at 02:47:23PM GMT, David Uhden Collado wrote:
> Dear all,
> 
> I am currently working on creating a port of the Monero CLI wallet for
> OpenBSD, the work I have done so far is attached in this email. This project
> is of personal interest to me, as well as to others who view privacy as an
> essential component of cybersecurity.

First of all, it wasn't super clear to me if you only ported (or
intended to port) monero-wallet-cli. The attached port is for all the
binaries you build from upstream, and in particular monerod.

> I am in the process of learning how to create ports for OpenBSD, which is
> why I have chosen to start with software that seems relatively
> straightforward to port.

Hell no. ^^

> I think this port is complete. However, it is still a work in progress and I
> am hesitant to propose it for inclusion in the ports tree due to the
> following issue:
> 
> When building this software as a non-root user, the following error occurs:
> 
> LLVM ERROR: out of memory
> c++: error: unable to execute command: Abort trap (core dumped)
> 
> This issue is documented in the original project, and the solution is to
> increase the ulimit size to 2 GB:
> 
> ulimit -d 2000000
> 
> I would like to know if it is possible to resolve this issue within the port
> itself, or if it would be acceptable to add this port to the tree despite
> the problem, perhaps by including a note in the README file.

Didn't deal with this. I run with PORTS_PRIVSEP=Yes and _pbuild runs
with 8GB base in amd64.

> Additionally, while working on this port and reading the documentation, I
> encountered several questions that I had to deduce based on how other
> OpenBSD ports handle them:
> 
> a. The directories pointed to by certain macros in bsd.port.mk, such as
> PREFIX and LOCALSTATEDIR.

SUBST_VARS in bsd.port.mk(5) explains a bit, item 16 of [1] explains how
each directory is used, "make show=VAR" shows the value of VAR.

Having given that piece of information, I don't see a specific question
in your comment.

> b. How to configure a port to create a new user when needed, for instance,
> to run a daemon, as is the case with this port.

Take a look at pkg_create(1) @newuser. That needs to be added to
pkg/PLIST, like done in the attached port.

> These have been the most challenging parts for me, and I find the
> documentation unclear on these points.

It's quite spread over several manpages, so it's a bit confusing /
difficult at times.

> This port has been tested on an amd64 platform. Unfortunately, I do not have
> access to compatible machines with other architectures to conduct further
> testing. If anyone is able to test the port on different platforms, I would
> greatly appreciate it. I am currently using a virtual machine, as the only
> computer I own with sufficient resources to compile this software in a
> reasonable time frame is not compatible with OpenBSD.
> 
> Initially, I considered naming the port net/monero-cli since there is an
> official GUI wallet. However, I decided to leave it as net/monero, as I
> don't think the GUI wallet will be ported in the future due to the
> dependencies that would also need to be ported. If I ever attempt to port a
> GUI wallet, I would try with Feather Wallet, as it seems the most feasible
> option given that it uses QT.

So, properly about David port, it's mostly fine, but

- it's uncommon to have things listed both in RDEPs and BDEPs, and in
  this particular case all of the are actually LDEPs
- you don't need the do-install target, cmake manages it fine
- you don't need gmake
- I ran into a compilation error because hidapi was installed

About byteskeptical port:

- small detail, but REVISION isn't needed for an import
- ONLY_FOR_ARCHS is for things that actually don't build in the other
  arches, not for things not tested in different arches
- upstream tarballs are preferred over GitHub-generated tarballs
- also the RDEPs and BDEPs that should be LDEPs and the do-install
  target
- I run into some compilation error with this one too, but I don't want
  to recompile it yet again. I believe it was a different one than the
  David, but the issue is also present in here: if hidapi is detected
  at configure-time, then the port fails compilation
- the patches for replacing {sprintf,strcat} with {snprintf,strncat} are
  better suited for upstream, which benefits all the users

My tarball does the following:

- adds hidapi and miniupnp deps, as they are automatically picked up and
  there isn't a sensible way to disable them, which means issue for
  bulks (hidapi requires patching a source file)
  - I do have a hardware wallet to try it out, but I haven't managed to
    do so yet and is low in my priority list. I don't see much point in
    having neither this nor the individual binaries as FLAVORs: OpenBSD
    packages tend to be bulky and prefers something that works mostly
    as expected for 80% of the users over saving space.
- uses devel/readline instead of base's, as the latter results in broken
  display (requires patching cmake files)
- disables liblzma, which is autodetected while looking for libunwind
  (requires patching cmake files)
- disables the docs: I think they're only dev docs and nothing for
  user-facing programs, and saves a dep on doxygen which tends to break
  things
- dropped pkg/monerod.login. I'm currently at 38% of a full sync,
  haven't run into issues with the defaults yet.
- don't install the example monerod.conf: it's 3 lines and the defaults
  work
- OpenBSD tends to prefer /var/prog to /var/lib/prog, so the home for
  _monerod is /var/monero (also means that the default location of the
  blockchain is /var/monero/.bitmonero)
- I picked up UID 627 for _monerod. zarafa was replaced by kopano in
  2017, so I think it should be safe to reuse it now.
- couldn't make libunwind work and pointing it to
  /usr/include/c++/v1/libunwind.h and libc++abi.so isn't enough:

ld: warning: easylogging++.cc(easylogging++.cc.o:(el::base::utils::File::buildStrippedFilename(char const*, char*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, unsigned long)) in archive external/easylogging++/libeasylogging.a): warning: strcat() is almost always misused, please use strlcat()
ld: error: undefined symbol: el::base::debug::StackTrace::generateNew()
>>> referenced by stack_trace.cpp
>>>               stack_trace.cpp.o:(tools::log_stack_trace(char const*)) in archive src/common/libcommon.a

ld: error: undefined symbol: el::base::debug::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, el::base::debug::StackTrace const&)
>>> referenced by stack_trace.cpp
>>>               stack_trace.cpp.o:(tools::log_stack_trace(char const*)) in archive src/common/libcommon.a

  but StackTrace::generateNew is behind a complex ifdef and I don't
  feel we're missing out on much without it.

That's more than enough for a mail. Port attached. Bye.

	Lucas


diff refs/heads/master 9676c6688a222bd27c6b3fee2f9b2bee4297eea1
commit - 3e15eae7e00ea78227ed46a1a7153ce4d102ead1
commit + 9676c6688a222bd27c6b3fee2f9b2bee4297eea1
blob - 5104415dc091f405d9c26b9c73d49c1d2e7be77e
blob + 7ba9d8a70c4595b0489e10b1b6ccadcf749d2846
--- infrastructure/db/user.list
+++ infrastructure/db/user.list
@@ -135,7 +135,7 @@ id  user		group		port
 624 _noip		_noip		net/no-ip
 625 _varnish		_varnish	www/varnish
 626 _pound		_pound		www/pound
-#627 _zarafa		_zarafa		mail/zarafa/zarafa
+627 _monerod		_monerod	net/monero
 628 _kamailio		_kamailio	telephony/kamailio
 629 _avahi		_avahi		net/avahi
 630 _victorialogs	_victorialogs	sysutils/victorialogs

• monero.tgz (3K)