From: Lucas Gabriel Vuotto Subject: Re: [NEW WIP]: net/monero (help needed) To: David Uhden Collado Cc: ports@openbsd.org, byteskeptical Date: Mon, 19 Aug 2024 20:49:39 +0000 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, std::__1::allocator> 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>&, 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