> 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.
> 

Honestly, I don't understand why people create ports for OpenBSD without 
trying to get them added to the official ports tree. In your case, I 
imagine it might be to test it more thoroughly, but it's still 
beneficial to share it to receive feedback from others.

>> 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.
> 

It's all part of the Monero CLI wallet, as the Monero developers 
intended. I think that separating the binaries could be 
counterproductive. On the other hand, my interest, along with that of 
many others porting this software to OpenBSD, is primarily to host a 
node. Personally, I currently host a public Monero node on a Raspberry 
Pi 5 running Debian. However, once OpenBSD is compatible with this 
hardware, I plan to install it and attempt to run this and other 
services there.

>> 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 have realized this the hard way.

> 
>> 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.

I am glad this is not a problem.

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

I agree.

> - you don't need the do-install target, cmake manages it fine

The modules used in OpenBSD ports handle so many tasks for you that, at 
first, you might not realize you don't need to add instructions for 
certain tasks because the module already takes care of them. The package 
building infrastructure in OpenBSD is highly refined.

> - you don't need gmake

According to the original project documentation, you do need it.

> - I ran into a compilation error because hidapi was installed

Thanks, I didn't realize that. It might be because I built the software 
using the "no-dev" CMake option.

> 
> 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.

I think it would be beneficial to test this feature to ensure the port 
provides 100% of the software's functionality.

> - 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.

I think it would be great if you could provide updates on how it 
performs once the blockchain is fully synchronized.

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

How did you detect all these problems? What recommendations can you give 
me to properly debug a port? I imagine it’s because you're a programmer, 
while I’m merely a system administrator.

>    /usr/include/c++/v1/libunwind.h and libc++abi.so isn't enough:

Does anyone know why libunwind is not available on OpenBSD? I am 
referring to the portable version, not the one included in Clang.

https://github.com/libunwind/libunwind

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

Thank you for your help! Hopefully this software can be added to the 
OpenBSD ports tree before the next stable release.

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