Bug 193431 - [MAINTAINER] lang/smlnj: update to 110.77
Summary: [MAINTAINER] lang/smlnj: update to 110.77
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kurt Jaeger
URL:
Keywords: needs-qa, patch
Depends on:
Blocks:
 
Reported: 2014-09-07 16:34 UTC by Johannes 5
Modified: 2014-10-14 17:51 UTC (History)
1 user (show)

See Also:


Attachments
update lang/smlnj to 110.77 (19.31 KB, patch)
2014-09-07 16:34 UTC, Johannes 5
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes 5 2014-09-07 16:34:01 UTC
Created attachment 147015 [details]
update lang/smlnj to 110.77

- update to 110.77.

Upstream changes include the addition of man pages, and
a fix for the tmpnam security warning (see PR 191899).
Release notes:
<http://www.smlnj.org/dist/working/110.77/110.77-README.html>
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2014-09-08 01:47:44 UTC
If possible please also include the following to promote quick 
resolution:

 * Attach successful poudriere testport, or redports.org build logs
 * portlint -AC output (after addressing any outstanding issues)
Comment 2 Johannes 5 2014-09-08 16:29:34 UTC
(In reply to Kubilay Kocak from comment #1)
> Kubilay Kocak <koobs@FreeBSD.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Keywords|                            |needs-qa, patch
>            Severity|Affects Some People         |Affects Only Me

Sorry if it was inapproriate to initialize the severity of this PR with
"Affects Some People". My intuition was that PRs like 191899 and
191504 indicate that it's not "Only Me" using the lang/smlnj port.
I also couldn't find a reference within the porter's handbook to
documentation of (the workflow used in) FreeBSD's bugzilla.

> --- Comment #1 from Kubilay Kocak <koobs@FreeBSD.org> ---
> If possible please also include the following to promote quick 
> resolution:
> 
>  * Attach successful poudriere testport, or redports.org build logs

Unfortunately I don't currently have access to a machine where I could
create ZFS file systems, which seems to be required by poudriere.

Certainly redports.org will be helpful with testing package building,
but before I'll start to explore anything new I'd like to finish
lang/smlnj, which was keeping me busy for quite a while now:-)

I also need a shell to test the functioning of the package and possibly
debug its failures. But that would not be part of a reports.org account,
right?

>  * portlint -AC output

% uname -srm
FreeBSD 10.0-STABLE i386
% grep FreeBSD: Makefile
# $FreeBSD: head/lang/smlnj/Makefile 366742 2014-08-31 10:42:04Z pi $
% portlint -AC
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
WARN: Makefile: Consider defining LICENSE.
0 fatal errors and 2 warnings found.

The porter's handbook does not seem to contain information on how to
define a port's LICENSE. The first paragraph on www.smlnj.org states
that "SML/NJ is free, open source software" and hyperlinks to the
license [1]. I can't see harm for the FreeBSD project resulting
from this license, which is also distributed as LICENSE file in
smlnj-lib.tgz. But I'm not a lawyer and if someone tells me how to
explicitly include that license into the port, I'll be glad to do that.

% uname -srm
FreeBSD 9.3-STABLE amd64
% grep FreeBSD: Makefile
# $FreeBSD: head/lang/smlnj/Makefile 366742 2014-08-31 10:42:04Z pi $
% portlint -AC
WARN: Makefile: POSITION64 appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: POSITION64 appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: RECOMPILE appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: RECOMPILE appears in PORT_OPTIONS:M, but is not listed in OPTIONS_DEFINE.
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
WARN: Makefile: Consider defining LICENSE.
0 fatal errors and 6 warnings found.
% make -V OPTIONS_DEFINE

%

I can't easily decide if those "PORT_OPTIONS:M" warnings are primarily
caused by the port, portlint, or bsd.options.mk. This port does have a
non-standard OPTIONS structure, because "higher" options imply
"lower" options (POSITION64 => RECOMPILE => EVERYTHING). Additionally
RECOMPILE (and hence POSITION64) breaks the port on amd64. So these
have to be disabled on amd64.

Unfortunately it doesn't help to put the offending part of the port's
Makefile into a conditional like .if ${ARCH} == "i386" ... .endif.
So it seems that I need advice on how to keep portlint from emitting
those warnings.

> (after addressing any outstanding issues)

I built and tested the port on 9.3-STABLE amd64 and 10.0-STABLE i386.
I could find no issues, neither with math/isabelle (make build) nor
devel/asdlgen (make test-compile; make test-demo), which is currently
dropped (but could be revived in the near future [2]).

Thanks for your feedback, advice, and patience
Johannes

[1] <http://www.smlnj.org/license.html>
[2] <ftp://offshore.free.de/pub/patch/asdlgen.patch.20140907>
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2014-09-21 07:25:13 UTC
A couple of points:

poudriere no longer requires ZFS (See NO_ZFS=yes) so go ahead and give it a go :)

While run-time / functional testing is great, ports/package QA is of the utmost importance. poudriere and redports provide cleanroom build environments, which pick up issues that local testing tends not to.

Additionally, and perhaps most importantly for you and other contributors, complete and thorough QA gets you:

- To the "patch ready queue" quicker and ahead of other issues
- A reputation for high-quality issue reports
- A higher priority (if not now, then very shortly in the future to reflect the quality of an issue report)

As far as the portlint warnings go, the non-standard options structure does raise red flags, but ultimately portlint is a tool, and doesn't need to be blindly followed.

If the warnings can be fixed, then go ahead. If they cant (for reasons you can put up a strong case for), then not a problem. Good judgment matters and ideally both portlint and the quality of our ports gets better over time.
Comment 4 Kurt Jaeger freebsd_committer 2014-10-11 20:06:39 UTC
I tested the build on 9.1-amd64 and 8.4-i386.

This popped up in the pkg-install and pkg-deinstall phase in poudriere:

------------------
[...]
export MULTIEXEC_WRAPPER_VERBOSE=yes &&  cd /usr/ports/lang/smlnj && make  ARCH=i386 OPSYS=FreeBSD OSREL=8.4 OSVERSION=804000 SYSTEMVERSION= deinstall
===>  Deinstalling for smlnj
===>   Deinstalling smlnj-110.77
Updating database digests format... done
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        smlnj-110.77

The operation will free 34 MB.
multiexec-wrapper: multiexec-wrapper was not (or is no longer) installed as /usr/local/bin/multiexec-wrapper.
multiexec-wrapper: reading /usr/local/etc/multiexec-wrapper.conf failed.
pkg-static: DEINSTALL script failed
[84i-default] [1/1] Deleting smlnj-110.77... done
-----------------------

From what I understand, it's coming from files/pkg-install.in, which
references multiexec-wrapper, which is not installed. According to poudriere,
it's not fatal ?

Any ideas this can be silenced ? Otherwise it looks fine.
I'll build on 10.0-amd64, when that poudriere jail is finished with the other stuff...
Comment 5 Johannes 5 2014-10-13 19:05:13 UTC
> --- Comment #4 from Kurt Jaeger <pi@FreeBSD.org> ---
> I tested the build on 9.1-amd64 and 8.4-i386.
> 
> This popped up in the pkg-install and pkg-deinstall phase in
> poudriere:
> [...]
> multiexec-wrapper: multiexec-wrapper was not (or is no longer) installed as
> /usr/local/bin/multiexec-wrapper.
> multiexec-wrapper: reading /usr/local/etc/multiexec-wrapper.conf failed.
> pkg-static: DEINSTALL script failed
> [...]
> 
> From what I understand, it's coming from files/pkg-install.in, which
> references multiexec-wrapper, which is not installed.

pkg-install failed to install multiexec-wrapper(.conf) because
PREFIX/bin (and PREFIX/etc) did not exist at installation time.
It seems that this failure was introduced by disembodying the
install-mtree target in Mk/bsd.port.mk [1].

> According to poudriere, it's not fatal ?

Maybe it's not considered fatal by poudriere because the pkg-install
failure happens outside the scope of pkg-plist (*). But for the user of
the port the missing multiexec-wrapper is fatal, unless he or she
manually takes care of the missing symlinks in PREFIX/bin.

> Any ideas this can be silenced ?

[2] includes a modification of pkg-install.in, which takes care of
creating (and removing) PREFIX/bin and PREFIX/etc during
(de-)installation if necessary. [2] should also cure warnings regarding
the missing license, run.x86-freebsd.so not being stripped, and the
deprecation of @dirrm[try]. (I hope that I got the LICENSE* variables
right by looking at Mk/bsd.licenses*.mk.)

> Otherwise it looks fine.
> I'll build on 10.0-amd64, when that poudriere jail is finished with
> the other stuff...

Some poudriere logs (10-STABLE on i386 and amd64) are available [3].
These were generated with [2] applied to the current state of the
lang/smlnj port (110.76_1, r366742). 
On i386 options set were none and POSITION64,
on amd64 options set were none and EVERYTHING.

As far as I can see, the only remaining issues are the portlint warnings
concerning missing options in OPTIONS_DEFINE. To me it looks like a
cosmetic problem, and has no operational consequences. Unfortunately
I'm not in the position to track this down in bsd.options.mk and/or
portlint.

If there's anything else I can do to help [2] being committed, please
let me now.

Thanks!
Johannes

ps Thanks to koobs@ for pointing me to poudriere's NO_ZFS=yes in
  comment #3.

[1] <https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?r1=368570&r2=368803>
[2] <ftp://offshore.free.de/pub/patch/smlnj.patch.20141013>
    MD5 (smlnj.patch.20141013) = cef15594b642c9e56deaa9bbcc16062a
[3] <ftp://offshore.free.de/pub/poudriere/>

(*) Necessarily multiexec-wrapper and it's .conf are not part of the
port's pkg-plist, because otherwise the port would conflict with
any other port using multiexec-wrapper. Until recently both lang/sml-nj
and lang/sml-nj-devel could be installed simultaneously. The first of
them that was installed by the user also installed multiexec-wrapper
(.conf), the last one to be deinstalled also deinstalled
multiexec-wrapper(.conf). As both ports should be (de-)installable
independently of each other, putting multiexec-wrapper(.conf) into the
pkg-plist of one of them is not an option. Turning multiexec-wrapper
into a port of its own (like java/javavmwrapper) might be a good
idea, but starting a new port is currently not an option for me;-(
Comment 6 commit-hook freebsd_committer 2014-10-13 19:34:58 UTC
A commit references this bug:

Author: pi
Date: Mon Oct 13 19:33:56 UTC 2014
New revision: 370816
URL: https://svnweb.freebsd.org/changeset/ports/370816

Log:
  lang/smlnj: 110.76 -> 110.77

  Changelog: http://www.smlnj.org/dist/working/110.77/110.77-README.html
  - defined LICENSE

  PR:		193431
  Submitted by:	joemann@beefree.free.de (maintainer)

Changes:
  head/lang/smlnj/Makefile
  head/lang/smlnj/distinfo
  head/lang/smlnj/files/do-patch-base_runtime_c-libs_posix-os_tmpname.c
  head/lang/smlnj/files/extra-patch-base_runtime_include_ml-unixdep.h
  head/lang/smlnj/files/patch-config___arch-n-opsys
  head/lang/smlnj/files/patch-config___heap2exec
  head/lang/smlnj/files/patch-config_install.sh
  head/lang/smlnj/files/pkg-install.in
  head/lang/smlnj/pkg-plist
Comment 7 Kurt Jaeger freebsd_committer 2014-10-13 19:35:56 UTC
Committed, thanks for your patience!
Comment 8 Johannes 5 2014-10-14 16:25:53 UTC
> --- Comment #6 from commit-hook@freebsd.org ---
> [...]
> URL: https://svnweb.freebsd.org/changeset/ports/370816
> [...]
> Changes:
>   head/lang/smlnj/Makefile
>   head/lang/smlnj/distinfo
>   head/lang/smlnj/files/do-patch-base_runtime_c-libs_posix-os_tmpname.c
>   head/lang/smlnj/files/extra-patch-base_runtime_include_ml-unixdep.h
>   head/lang/smlnj/files/patch-config___arch-n-opsys
>   head/lang/smlnj/files/patch-config___heap2exec
>   head/lang/smlnj/files/patch-config_install.sh
>   head/lang/smlnj/files/pkg-install.in
>   head/lang/smlnj/pkg-plist

Unfortunately the following two (new) files were not committed:

files/do-patch-base_runtime_include_ml-unixdep.h
files/do-patch-base_system_smlnj_installer_generic-install.sml

For your convenience I've put them into a patch [1] against the current
state of the port. (They were also present in yesterdays patch [2]).

The first patch file (ml-unixdep.h) is required to activate upstream's
tmpnam->mkstemp fix on FreeBSD. Without it there's a revival of:
/usr/local/smlnj/bin/.run/run.x86-freebsd (USES POSSIBLY INSECURE FUNCTIONS: tmpnam)

The second one (generic-install.sml) is required when recompiling the
SML/NJ compiler (which currently only works on i386). Without it:
[bad plugin name: anchor $mllex-tool.cm not defined]
uncaught exception BadAnchor
[...]
====>> Error: Build failed in phase: check-plist

Both problems should be handled by upstream some day, but at the
moment I recommend that you apply [1] to lang/smlnj.

Thanks!
Johannes

[1] <ftp://offshore.free.de/pub/patch/smlnj.patch.20141014>
    MD5 (smlnj.patch.20141014) = 02cd6a8f6a19e453ec9aae355af5fdc0
[2] <ftp://offshore.free.de/pub/patch/smlnj.patch.20141013>
    MD5 (smlnj.patch.20141013) = cef15594b642c9e56deaa9bbcc16062a
Comment 9 commit-hook freebsd_committer 2014-10-14 17:50:45 UTC
A commit references this bug:

Author: pi
Date: Tue Oct 14 17:50:27 UTC 2014
New revision: 370875
URL: https://svnweb.freebsd.org/changeset/ports/370875

Log:
  lang/smlnj: add missing two patches

  PR:             193431
  Pointy hat to:  myself

Changes:
  head/lang/smlnj/files/do-patch-base_runtime_include_ml-unixdep.h
  head/lang/smlnj/files/do-patch-base_system_smlnj_installer_generic-install.sml
Comment 10 Kurt Jaeger freebsd_committer 2014-10-14 17:51:26 UTC
Thanks, I forgot those 8-(. Fixed.