nano is missing from ARM prebuilt package repository, but nano-devel is available. The version of nano-devel available is fairly old and missing functionality at this point. I pulled down ports on my Raspberry Pi, built, installed and ran the nano package without any modification, so I'm unsure as to why it would be missing from the ARM package repository.
There is more than on arm repository. I checked arm64 for build errors and did not see any. However on armv6 the build fails with: checking whether printf survives out-of-memory conditions... =>> Killing runaway build after 21600 seconds with no output http://beefy8.nyi.freebsd.org/data/head-armv6-default/p477468_s337991/logs/errors/nano-2.9.8.log I do not know of any fix.
(In reply to Mark Linimon from comment #1) See https://svnweb.freebsd.org/ports/head/devel/libunistring/Makefile?revision=457665&view=markup There is a possible workaround
(In reply to Nathan from comment #2) If someone doesn't beat me to it, I will try this workaround; currently jail is in process of installing several pkgs, so it may be tomorrow before I can do so
I'm not sure what went wrong with your build. I'm building it natively on a armv6 board itself (Raspberry Pi Zero) instead of using a cross-compiler on my main workstation. I'm also building it in the main OS environment instead of inside of a jail. One note however, I'm using the newly released nano 3.0 source code instead of the nano 2.9.8 source. This was only added to the ports on the 11th (2 days ago). I'm not sure if either of these would effect the printf issue in question. I'm also on a newer build of FreeBSD 12 too. Luckily, I hadnt closed the console window after building, so I have the history: https://gist.github.com/darkain/0deba58c96f1493161992ba0df54d42e uname -a FreeBSD rpi-b 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #0 r338518: Fri Sep 7 03:45:50 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv6/sys/RPI-B arm
(In reply to Vincent Milum from comment #4) It's quite possible, may not need to apply to arm itself, but if building inside poudriere; that work around was, in it's case, for qemu IIRC. Though leads to a question; do we have poudriere servers that builds pkgs natively or do they use qemu to build them?
(In reply to Nathan from comment #5) We build natively on aarch64. We use qemu-user-static for armv6, armv7 and mips.
(In reply to Mark Linimon from comment #1) It's a qemu bug (rlimit problem). I'm not able to fix it. There is a workaround in place in some ports for this problem (sysutils/coreutils, databases/recutils, devel/bison, devel/m4...) .ifdef QEMU_EMULATING # XXX bug 224740: configure hangs CONFIGURE_ENV+= gl_cv_func_printf_enomem=no .endif
Just wanted to note that with 12.0-RELEASE, this package is still missing, and the nano-devel package is still ages out of date.
A commit references this bug: Author: koobs Date: Tue Dec 18 11:19:54 UTC 2018 New revision: 487744 URL: https://svnweb.freebsd.org/changeset/ports/487744 Log: editors/nano: Fix build (configure) on ARM The arm package builder when building this port, fails with the following error during configure: checking whether printf survives out-of-memory conditions... =>> Killing runaway build after 21600 seconds with no output The root cause is described in bug 224740, which has not been resolved yet: low RLIMIT_VMEM hangs qemu due to GSlice allocation failure In the meantime, this change applies a known workaround which has already been applied in several ports, which disables the specific (hanging) configure check, if the build is run with qemu emulation. PR: 231346, 224740 Reported by: many Approved by: portmgr (blanket: build fix, jfi) MFH: 2018Q4 Changes: head/editors/nano/Makefile
Leaving this issue open until its dependent (bug 224740) is closed, merged and the workaround removed. I'll merge ports r487744 to 2018Q4 (quarterly) as well
Hello Vincent, it seems nano 3.2 is there now. May you confirm and close the PR, please?
Nano 3.2 installed from pkg on my Raspberry Pi Zero is working as intended now. Thanks for helping make this available for everyone. Status is still "open" while the qemu compilation issue still exists in 224740
Hello. Is it still an issue?
It's in quarterly according to freshports.org so we can close this PR. Ref: https://www.freshports.org/editors/nano/
Please close this one as it's available