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>
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)
(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>
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.
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 #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;-(
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
Committed, thanks for your patience!
> --- 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
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
Thanks, I forgot those 8-(. Fixed.