It's possible that EXTRACT_CMD won't be predefined in the near future
in order to support distfiles in multiple formats. We know the
extraction tool needs to be tar, so let's specify it directly.
The eclipse ports have pending PRs to update the version, although I
don't know if they include staging. Each Eclipse is a huge port so
staging is out scope of this extraction tool work.
Approved by: portmgr (implicit)
to print a generated PostScript file. When lpd(8) is used, lpr(1) from base
must be used. Also, status command for lpc(8) requires a printer name. If
no argument is specified, i.e., "/usr/sbin/lpc status", then it displays the
command usage, i.e., "usage: status {all | printer ...}". Unfortunately,
"usage" is interpreted as a printer name because ":" is included. Add "all"
and adjust an expression for grep(1).
used to print a generated PostScript file. When lpd(8) is used, lpr(1) from
base must be used. Also, status command for lpc(8) requires a printer name.
If no argument is specified, i.e., "/usr/sbin/lpc status", then it displays
the command usage, i.e., "usage: status {all | printer ...}".
Unfortunately, "usage" is interpreted as a printer name because ":" is
included. Add "all" and adjust an expression for grep(1). [1]
- Use /proc/curproc/file to find its executable path if available. It fixes
java/icedtea-web, for example. [2]
PR: ports/178856 [1]
PR: java/189905 [2]
to print a generated PostScript file. When lpd(8) is used, lpr(1) from base
must be used. Also, status command for lpc(8) requires a printer name. If
no argument is specified, i.e., "/usr/sbin/lpc status", then it displays the
command usage, i.e., "usage: status {all | printer ...}". Unfortunately,
"usage" is interpreted as a printer name because ":" is included. Add "all"
and adjust an expression for grep(1).
PR: ports/178856
(2) USES=libtool instead of USE_AUTOTOOLS=libtool
(3) Bump required Java version to 1.7 for java/java-subversion.
(4) Build java/kava-subversion with system clang, not "any" gcc
on 10 and CURRENT (checked with OpenJDK7 and OpenJDK8).
able to find libjli.so from RPATH because argv[0] points to the symlink.
Note it seems Linux does not have the problem when /proc/self/exe exists.
If it does not exist, it also fails to find libjli.so. Clean up patches
while I am here.
