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
