I am working on a port for OCaml 4.02.1. The port itself is ready, but I still need to work on labltk, which is now distributed separately. I think it is best to submit patches for the new OCaml and LablTK ports simultaneously, to favour a smooth upgrade path. If someone cannot wait, he can find my work here: https://github.com/michipili/ports-bsd/tree/ocaml-4.02.1 (This branch is susceptible to be rebased to follow the ports tree.)
Created attachment 150262 [details] Update for ocaml-4.02.1 This is is the update to OCaml 4.02.1. Note that labltk is not part of the main distribution anymore, see Bug 195737 for a port.
Labltk and Camlp4 ports are ready, see - Bug 195737 - Bug 195773
Created attachment 150313 [details] OCaml findlib patch OCaml 4.02.1 contains a Bytes modules which used to be built with findlib. Our findlib port will not build this Bytes module when OCaml 4.02.1 is detected, so that the pkg-plist must be updated.
Building it under 8.4i386 has installed files missing in the pkg-plist. http://people.freebsd.org/~pi/logs/lang__ocaml-84i-1427821885.txt It builds on 10.1a and 9.3a.
Created attachment 155351 [details] Update for ocaml-4.02.1 I have a new patch adding the missed files (profiled libs) to the pkg-plist. This was generated with `git diff -u` so that it can be applied with `patch -p1`.
Now it builds with 8.4i, but fails with 9.3a, 10.1a ? http://people.freebsd.org/~pi/logs/lang__ocaml*
Created attachment 155407 [details] Update for ocaml-4.02.1 Let's see if this one works! For some reason, profiling with GPROF is not supported upstream on amd64. I guess this is a bug in the configure script and will be fixed in the soon-to-come next release. Where can I find a description of the setup you use to test ports? I see this is poudriere, but how exactly is it configured? Is RedPorts functional again?
redports is not functional indefinitely. https://www.freebsd.org/doc/en/books/porters-handbook/testing-poudriere.html
Thank you John, it is great to know that we have this new – at least for my eyes – chapter in the Porters Handbook!
Tested the build using poudriere on 10.1a, 9.3a and 8.4i: 8.4i was OK, the other two had missing files. See http://people.freebsd.org/~pi/logs/lang__ocaml*1429036276*
Created attachment 155690 [details] Update for ocaml-4.02.1 This is new attempt. I tested it with poudriere in FreeBSD 9-STABLE and 10-STABLE for both i386 and amd64. Logs were clean. Unfortunately, poudriere gave up the ghost while trying to setup a 8-STABLE environment, so I could not verify the port for that version of FreeBSD.
Any progress on this one?
You wiped out the dragonfly patches without replacing them. As far as I can tell, they are still needed.
A commit references this bug: Author: marino Date: Wed Apr 29 20:45:25 UTC 2015 New revision: 385012 URL: https://svnweb.freebsd.org/changeset/ports/385012 Log: lang/ocaml: Upgrade version 4.01 => 4.02 PR: 195736 Submitted by: Michael Gruenewald (maintainer) Add'l fixes: marino Besides typical port cleanup, the dragonfly patches which had been removed for the update were added back to the configure patch. Changes: head/lang/ocaml/Makefile head/lang/ocaml/distinfo head/lang/ocaml/files/edit_pkg-plist.sed head/lang/ocaml/files/patch-Makefile head/lang/ocaml/files/patch-asmcomp__arm__arch.ml head/lang/ocaml/files/patch-asmrun-Makefile head/lang/ocaml/files/patch-asmrun__arm.S head/lang/ocaml/files/patch-byterun-Makefile.common head/lang/ocaml/files/patch-camlp4-man_Makefile head/lang/ocaml/files/patch-config-auto-aux-async_io.c head/lang/ocaml/files/patch-configure head/lang/ocaml/files/patch-ocamlbuild head/lang/ocaml/files/patch-ocamldoc_Makefile head/lang/ocaml/files/patch-otherlibs-Makefile.shared head/lang/ocaml/files/patch-otherlibs-dynlink-Makefile head/lang/ocaml/files/patch-otherlibs-labltk-lib-Makefile head/lang/ocaml/files/patch-otherlibs-labltk-support-Makefile head/lang/ocaml/files/patch-otherlibs-systhreads-Makefile head/lang/ocaml/files/patch-otherlibs-threads-Makefile head/lang/ocaml/files/patch-stdlib-Makefile head/lang/ocaml/pkg-plist
I made numerous editorial changes, and obviously I added the DragonFly changes back to the configure patch (they never should have been removed) I also modified MASTER_SITES because: 1) docs are not on GENTOO 2) GENTOO was changed to magic word 3) distfiles are not supposed to use +=, one is supposed to redefine distfiles as a unit, not additional the check target seemed really messed up. I changed it from "check test: install" to "check-test: do-install". I don't know what the two word target was supposed to do. The makefile patch didn't apply but I repaired it from the rejected hunks. It passed on FreeBSD 8.4 poudriere (10 also) and also on DragonFly poudriere, all with stage checks enabled.
A commit references this bug: Author: marino Date: Wed Apr 29 20:57:31 UTC 2015 New revision: 385013 URL: https://svnweb.freebsd.org/changeset/ports/385013 Log: math/facile: Bump because ocaml version ungraded The ocaml makefile says to bump this port after ocaml is changed. I don't know how necessary this really is though. PR: 195736 Changes: head/math/facile/Makefile
Great! Thank you for your help and your detailed feedback. I will try to be more careful about DragonFly specific changes next time and am not sure why I did not identify them as such. For the `check test' case, I think the space was intended, it defines two targets `test' and `check'!
by the way, I ran portlint on this and it threw up a ton of problems, most caused by that comment at the top. That's why I moved the comment, to make portlint happy. I don't think portlint was run on this before it was submitted. (it should have been if it wasn't)
> For the `check test' case, I think the space was intended, it defines two targets `test' and `check'! aliases? In any case, "install" requirement was wrong, it's "do-install"
Well, that's strange, Id did run portlint and as I remember it was only reluctant for the curious handling of DISTFILES that we have, and issued a warning for that. So, it seems like I need to double check that next time. À propos math/facile, we inherited the note from a previous maintainer and I *guess* that this is because each version of the compiler introduces an incompatible object format, and each OCaml programs and libraries need to be recompiled. If the guess is correct, the note is probably not relevant any more. The maintainer of the port is kde@FreeBSD.org, what is the best way to call them in the discussion?
Following the commit of ocaml 4.02.1, the port fails during configure on 10-STABLE. I noticed this during upgrades on one machine, so tried it with default options on another machine that hadn't previously had the port. They fail identically. /usr/ports/lang/ocaml # make ===> License QPL10 LGPL20 accepted by the user ===> Found saved configuration for ocaml-4.02.1 ===> ocaml-4.02.1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by ocaml-4.02.1 for building ===> Extracting for ocaml-4.02.1 => SHA256 Checksum OK for ocaml-4.02.1.tar.xz. ===> Patching for ocaml-4.02.1 ===> Applying FreeBSD patches for ocaml-4.02.1 ===> ocaml-4.02.1 depends on executable: gmake - found ===> ocaml-4.02.1 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> Configuring for ocaml-4.02.1 [ERROR!]Arguments to this script look like '-prefix /foo/bar', not '-prefix=/foo/bar' (note the '='). ===> Script "configure" failed unexpectedly. Please report the problem to michipili@gmail.com [maintainer] and attach the "/usr/obj/usr/ports/lang/ocaml/work/ocaml-4.02.1/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[1]: stopped in /usr/ports/lang/ocaml *** Error code 1 Stop. make: stopped in /usr/ports/lang/ocaml
Also, config.log is not created when it fails this early. # less /usr/obj/usr/ports/lang/ocaml/work/ocaml-4.02.1/config.log /usr/obj/usr/ports/lang/ocaml/work/ocaml-4.02.1/config.log: No such file or directory # ls /usr/obj/usr/ports/lang/ocaml/work/ocaml-4.02.1/ .depend .travis-ci.sh LICENSE README.win32 boot config driver ocamlbuild stdlib typing .gitignore .travis.yml Makefile VERSION bytecomp configure emacs ocamldoc testsuite utils .ignore Changes Makefile.nt asmcomp byterun configure.orig lex otherlibs tools yacc .ocp-indent INSTALL README asmrun compilerlibs debugger man parsing toplevel
Is this the same problem as #199884? Does this match the following upstream bug: http://caml.inria.fr/mantis/view.php?id=6628 If so, maybe you can ask for the bug to be reopened? Can you provide more information on your setup (architecture and compilation options). If your bug matches #199884 we should continue disccussion there, otherwise could you file another bug? Thanks!
I built it in on freebsd 10 in poudriere before I committed it, so this is a "can't reproduce" situation. I do not care about live system building. If it's not reproducible in poudriere, it didn't happen. There is also ambiguity here. I have to assume "amd64" but this could have easily been text from i386, something I did not personally test. Michael said he did though.
Michael, thanks for pointing out the other bug. It is the same issue and the resolution is the upstream patch. I shall continue there. I had first raised the topic here since it was a new problem after the commit and many patches were removed. Marino, your position is total bullshit. A port that only builds in poudriere is broken by definiton. In this case you could have seen it break in poudriere had you tried a real-world configuration, like setting CPUTYPE which is a system supported parameter. I'm forced to consider all your commits as untested and potentially harmful to real systems if you only ever test in an unrealistic sandbox. Ports shouldn't be commited to the real world until they've been tested under realistic conditions.
(In reply to matthew from comment #26) setting CPUTYPE is "AT YOUR OWN RISK" and not recommended. You invalidate your warranty. Your opinion on how ports should be tested is not shared by anyone with a commit bit and thus worthless. No poudriere log, no issue. That's it. Take it or leave it.
Marino: CPUTYPE is well documented in /usr/share/examples/etc/make.conf and nowhere does it say it "void warranty" (note that the license explicitly disclaims any all warranties, so bad choice of words there). If the option is unsupported then it must be documented as such. Currently CPUTYPE is a documented option supported by the pase system. If ports do not support it, they do not support the system they are alledged to be for. Again, it is not a matter of not using poudriere, you would have the same problem there, so the log from the poop-drier is inconsequential. FreeBSD has long been a source-based system. If you don't like that, don't spoil it, go find some other project to infect with your incomptence instead.
Please stop making stuff up and show where it is documented that PORTS must be tested with all CPUTYPES or even that CPUTYPE is supported. The lack of documentation against support isn't proof it is supported. You can refuse to use poudriere all you want, but it's the pass/fail of ports building. You aren't going to convince anyone, no matter how many insults you though out. Interesting that you are incapable of talking without stooping to using names and insults though.
Kurt, Sorry for catching you in the cross fire. I am really sick or irresponsible people blaming problems on innocent bystanders. Marino, Just because you touch more ports does NOT mean you are doing valuable work. Committing port that are not fully functuional is NOT helpful, it is harmful and wastes evreyone's time. I know that accidents happen. In this case the maintainer wasn't aware an upstream patch was necessary. The problem is when you say "it works in my sandbox, not broken, la la la". Don't say you've tested something when you clearly haven't tested it any useful fashion. I'm tired of having my portmaster run's interrupted by something YOU have committed without due diligence. After all, it is you who kept saying that maintainers can't be trusted, ports committers have to do all the work, blah blah blah. You had nothing to add to solving the bug with ANy of the comments you've made today. You should have kept your trap shut.
Hello, with this upgrade I'm unable to compile some things that depend on camlp4. I have installed ocaml-camlp4. Here is an example error I get: #=== ERROR while installing type_conv.112.01.01 ===============================# # opam-version 1.2.1 # os freebsd # command gmake # path /home/mmatalka/.opam/system/build/type_conv.112.01.01 # compiler system (4.02.1) # exit-code 2 # env-file /home/mmatalka/.opam/system/build/type_conv.112.01.01/type_conv-47599-57f057.env # stdout-file /home/mmatalka/.opam/system/build/type_conv.112.01.01/type_conv-47599-57f057.out # stderr-file /home/mmatalka/.opam/system/build/type_conv.112.01.01/type_conv-47599-57f057.err ### stdout ### # ocamlopt.opt -o setup.exe setup.ml || ocamlopt -o setup.exe setup.ml || ocamlc -o setup.exe setup.ml # rm -f setup.cmx setup.cmi setup.o setup.obj setup.cmo # ./setup.exe -configure # Makefile:51: recipe for target 'setup.data' failed ### stderr ### # ocamlfind: Package `camlp4.quotations' not found # W: Field 'pkg_camlp4_quotations' is not set: Command ''/home/mmatalka/.opam/system/bin/ocamlfind' query -format %d camlp4.quotations > '/tmp/oasis-e393c6.txt'' terminated with error code 2 # ocamlfind: Package `camlp4.extend' not found # W: Field 'pkg_camlp4_extend' is not set: Command ''/home/mmatalka/.opam/system/bin/ocamlfind' query -format %d camlp4.extend > '/tmp/oasis-1357e8.txt'' terminated with error code 2 # E: Cannot find findlib package camlp4.extend # E: Cannot find findlib package camlp4.quotations # E: Failure("2 configuration errors") # gmake: *** [setup.data] Error 1
(In reply to mmatalka from comment #31) Moving my comment over to the camlp4 port issue.
Michael, There has been significant fallout from updating from ocaml 4.01 to 4.02. Many ports no longer build (incidentally I consider this a black mark against ocaml in general). In the future, I think it should be mandatory to perform an EXP-RUN on updates to figure out what ports are going to fail and if possible get a fix in place that must be committed at the same time as the ocaml upgrade. Intuitively I would not have imagined such fallout from a 0.01 change in version but apparently this is possible. The update to 4.02 has not been smooth at all.
You are right John, I will keep this in mind and organise for the next upgrade. I had not foreseen such a wreckage either!
Hello, I am trying to install utop with this version of ocaml installed via pkg however the expunge command is not being set as executable which utop depends on running. # /usr/local/lib/ocaml/expunge: Permission denied $ ls -l /usr/local/lib/ocaml/expunge -rw-r--r-- 1 root wheel 1630516 Aug 6 03:30 /usr/local/lib/ocaml/expunge How would you like me to procede with this bug?
How does this relate to the update of OCaml? This really should be another entry! You can deal with it by adding the permission manually (see chmod(1)) or by using opam.
A commit references this bug: Author: pi Date: Sun Aug 16 17:58:14 UTC 2015 New revision: 394415 URL: https://svnweb.freebsd.org/changeset/ports/394415 Log: lang/ocaml: give execute permissions via pkg-plist to two files PR: 195736 Submitted by: mmatalka@gmail.com Approved by: Michael Gruenewald <michipili@gmail.com> (maintainer) Changes: head/lang/ocaml/pkg-plist
A commit references this bug: Author: pi Date: Sun Aug 23 10:12:20 UTC 2015 New revision: 395081 URL: https://svnweb.freebsd.org/changeset/ports/395081 Log: lang/ocaml: pet portlint, change pkg-plist as suggested by ohauer PR: 195736 Submitted by: ohauer Changes: head/lang/ocaml/Makefile head/lang/ocaml/pkg-plist