lsof is a problem.  It is tightly coupled to the base system, enough to
require /usr/src/sys checked out to be able to build it.  This means
that it breaks quite frequently:

  http://marc.info/?l=openbsd-ports&s=lsof

It also needs /dev/mem access and doesn't even work without sysctl
kern.allowkmem=1.  So it is currently *broken* with a default install,
and requires you to tune down security parameters.

Nobody stepped up to fix it and make it play nicer, despite the
heads-up:

  http://marc.info/?l=openbsd-ports&m=147445148420200&w=2

Only net/arm depends on it right now, and even there lsof is a problem.
If lsof can't work because of lack of /dev/mem access, arm seems to run
fine.  If you hack things up to allow lsof to work, which means:
1. setting kern.allowkmem=1
2. running arm as root or adding the setuid bit to the lsof executable
  *cough*
then arm will hang and be completely unusable.  (Thanks danj@ for
helping up with the tests.)

I therefore propose that we gently move lsof to the Attic.  ok?


Index: Makefile
===================================================================
RCS file: /d/cvs/ports/net/arm/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile    7 May 2016 12:40:58 -0000       1.5
+++ Makefile    1 Dec 2016 11:38:41 -0000
@@ -4,7 +4,7 @@ COMMENT =               terminal status monitor for T
 
 V =                    1.4.5.0
 DISTNAME =             arm-${V}
-REVISION =             2
+REVISION =             3
 
 SUBST_VARS +=          V
 
@@ -22,7 +22,6 @@ EXTRACT_SUFX =                .tar.bz2
 
 MODULES =              lang/python
 RUN_DEPENDS =          net/tor \
-                       sysutils/lsof \
                        devel/desktop-file-utils
 
 NO_TEST =              Yes

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply via email to