Bug 231346 - editors/nano: missing from ARM package repository
Summary: editors/nano: missing from ARM package repository
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Many People
Assignee: Danilo Egea Gondolfo
Depends on: 224740
  Show dependency treegraph
Reported: 2018-09-13 17:29 UTC by Vincent Milum Jr
Modified: 2019-11-25 22:44 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (danilo)


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Milum Jr 2018-09-13 17:29:28 UTC
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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2018-09-14 01:00:49 UTC
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


I do not know of any fix.
Comment 2 Nathan 2018-09-14 01:30:03 UTC
(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
Comment 3 Nathan 2018-09-14 01:42:14 UTC
(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
Comment 4 Vincent Milum Jr 2018-09-14 02:50:53 UTC
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:

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
Comment 5 Nathan 2018-09-14 03:19:08 UTC
(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?
Comment 6 Mikael Urankar freebsd_committer 2018-09-14 08:05:55 UTC
(In reply to Nathan from comment #5)
We build natively on aarch64. We use qemu-user-static for armv6, armv7 and mips.
Comment 7 Mikael Urankar freebsd_committer 2018-09-14 08:13:53 UTC
(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...)

# XXX bug 224740: configure hangs
CONFIGURE_ENV+= gl_cv_func_printf_enomem=no
Comment 8 Vincent Milum Jr 2018-12-16 08:59:56 UTC
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.
Comment 9 commit-hook freebsd_committer 2018-12-18 11:20:39 UTC
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

  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

Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2018-12-18 11:23:21 UTC
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
Comment 11 Danilo Egea Gondolfo freebsd_committer 2019-01-11 23:18:27 UTC
Hello Vincent, it seems nano 3.2 is there now. May you confirm and close the PR, please?
Comment 12 Vincent Milum Jr 2019-01-23 19:48:28 UTC
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
Comment 13 Danilo Egea Gondolfo freebsd_committer 2019-11-25 22:44:46 UTC
Hello. Is it still an issue?