Latest upstream release: 4.11.0 Current version/release in rawhide: 4.11.0-0.4.dev2.fc33 URL: https://ocaml.org Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2518/
The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you. Please use URLs in your Source declarations if possible. - ocaml-4.11.0.tar.gz
Created attachment 1712131 [details] List of all ocaml* packages in Koji This is my starting list of all OCaml packages, taken from: https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=ocaml* Some of these will be dead packages, I'll remove those later.
This is my side tag (just FYI, please do not build anything in here): $ fedpkg request-side-tag --base-tag f34-build Side tag 'f34-build-side-28234' (id 28234) created. Use 'fedpkg build --target=f34-build-side-28234' to use it. Use 'koji wait-repo f34-build-side-28234' to wait for the build repo to be generated.
This is the branch of OCaml that we're going to be building: https://pagure.io/fedora-ocaml/commits/fedora-34-4.11.0 Points to note: - RISC-V backend was added upstream to the 4.11 branch. - LTO fix is upstream, but different from the fix I sent and not included in 4.11 so I have cherry-picked their fix.
(In reply to Richard W.M. Jones from comment #2) > Created attachment 1712131 [details] > List of all ocaml* packages in Koji The dead packages are: ocaml-bisect ocaml-bitmatch ocaml-bitstring ocaml-camlp4 ocaml-cmigrep ocaml-config-file ocaml-deriving ocamldsort ocaml-json-static ocaml-json-wheel ocaml-mikmatch ocaml-openin ocaml-p3l ocaml-pa-do ocaml-pa-monad ocaml-pgocaml ocaml-preludeml ocaml-pxp ocaml-reins ocaml-type-conv ocaml-ulex The remaining packages + the non-"ocaml-*" packages have been assembled in this list: http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=blob;f=Goalfile;hb=HEAD
$ ../goals/run goals -k Builds can be followed here: https://koji.fedoraproject.org/koji/builds?order=-completion_time&userID=rjones Because of the -k option goals will try to continue building after a failure (as long as there are no dependencies on failed builds). If a build fails it must be fixed and rebuilt manually. This version of the script does not attempt to automatically retry failures - earlier versions did but it just caused problems.
I think this was mentioned before, but several builds failed because of the conditional BR: BuildRequires: (ocaml-sexplib0-devel >= 0.14 and ocaml-sexplib0-devel < 0.15) I wonder if there's a reason for this or if we could just use BuildRequires: ocaml-sexplib0-devel and remove it entirely when sexplib0 0.15 is released?
Ugh. I was worried those would cause problems. Dan asked me to add them because they more fully reflect the dependencies in the upstream opam files. Then Fabio pointed out that "and" is the wrong connective; "with" should be used instead. I have not gotten around to changing all of them yet, so some have "and" and some have "with". If they're causing problems, then let's remove them. We the packagers will have to make sure we keep the right versions matched up.
Yes TBH they just cause problems with my script - it's missing many dependencies because it cannot parse these. In fact it's not even a problem in my script, it's a problem that rpmspec -q --buildrequires *.spec cannot parse them - possibly they are impossible to parse because it requires knowledge of other packages which rpmspec doesn't have. Do you want me to fix them? I have everything checked out now so it's pretty convenient for me to do that.
Yes, please. Sorry for the hassle.
OK that should all be done now, thanks.
FYI there seems to be a problem in dune. Filed upstream bug: https://github.com/ocaml/dune/issues/3736 This problem as so far affected only ocaml-cairo and ocaml-ssl, but it is reproducible for me locally.
When you say it is reproducible for you locally, do you mean with the new ocaml 4.11.0 release? Because I just did a successful Rawhide mock build of ocaml-ssl with ocaml-4.11.0-0.8.dev2.fc33 and ocaml-dune-2.7.0-1.fc34. That suggests that something changed in 4.11.0 final to cause this.
I'm able to reproduce it locally with: ocaml-4.11.0-1.fc34.x86_64 ocaml-dune-2.7.0-2.fc34.x86_64 You can get those packages by downloading them directly from koji (using koji download-build <NVR> --arch=x86_64). It might be something to do with the updated OCaml package. However it looked to me like a simple bug in dune which was caused by something that changed in the Map module (eg. random ordering of elements or something like that).
I'm not sure that OCaml's Map is involved. This error is coming from module Map defined in otherlibs/configurator/src/import.ml in the dune release. It is trying to build a Map from a List, and is finding duplicate keys in the List. The of_list_exn function is called from otherlibs/configurator/src/v1.ml, line 535, in the extract_values function. The extract_values function is called just below that, on line 564, in the import function. The import function is called from src/config/discover.ml from ocaml-ssl, line 54. Apparently openssl/ssl.h is being scanned to see if SSL_set_tlsext_host_name or SSL_EXT_TLS1_3_ONLY are defined. I'm curious to know what the duplicate key is, as I see 0 definitions of SSL_set_tlsext_host_name and 1 definition of SSL_EXT_TLS1_3_ONLY.
The other change between the development package and the current package would be LTO.
Packages which failed: ocaml-ssl ocaml-cairo Both because of https://github.com/ocaml/dune/issues/3736 ocaml-lablgtk3 Because of ocaml-cairo failure coq frama-c why3 Because of ocaml-lablgtk3 failure Other failures which seem unrelated to above: ocaml-ppx-custom-printf https://koji.fedoraproject.org/koji/buildinfo?buildID=1598187 Many dep problems possibly related to ocaml-ppx-sexp-conv alt-ergo https://koji.fedoraproject.org/koji/buildinfo?buildID=1598177 Unclear dep problem with ocaml-psmt2-frontend ocaml-ppx-deriving https://koji.fedoraproject.org/koji/buildinfo?buildID=1598159 Unclear dep problems with ocaml-ppx-tools ocaml-mlmpfr [no most recent build link] Actual compile failure, looks like LTO ocaml-jst-config https://koji.fedoraproject.org/koji/buildinfo?buildID=1597783 Lots of missing deps, possibly because of above build failures.
> ocaml-ppx-custom-printf https://koji.fedoraproject.org/koji/buildinfo?buildID=1598187 > Many dep problems possibly related to ocaml-ppx-sexp-conv > > alt-ergo https://koji.fedoraproject.org/koji/buildinfo?buildID=1598177 > Unclear dep problem with ocaml-psmt2-frontend > > ocaml-ppx-deriving https://koji.fedoraproject.org/koji/buildinfo?buildID=1598159 > Unclear dep problems with ocaml-ppx-tools I believe these ones are now all fixed. > ocaml-mlmpfr [no most recent build link] > Actual compile failure, looks like LTO I tried disabling LTO but it didn't fix the problem.
jst-config: New build failure https://koji.fedoraproject.org/koji/buildinfo?buildID=1597783 It's the dune bug again.
zenon and flocq also failed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1598314 https://koji.fedoraproject.org/koji/buildinfo?buildID=1598313 but these are straightforward to understand because they depend on cairo -> lablgtk3 -> coq.
> ocaml-mlmpfr Now built successfully. I believe everything else now is a consequence of the dune bug.
ssl, cairo, lablgtk3 are now all built. I'm now going into the "coq pit", wish me luck.
The update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-22a662d696
Latest upstream release: 4.11.1 Current version/release in rawhide: 4.11.0-1.fc34 URL: https://ocaml.org Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2518/
Created attachment 1713306 [details] [patch] Update to 4.11.1 (#1870368)
https://discuss.ocaml.org/t/ocaml-4-11-1-early-bugfix-release/6337 "A serious bug has been discovered last week in OCaml 4.11.0: explicit polymorphic annotations are checked too permissively. Some incorrect programs (possibly segfaulting) are accepted by the compiler in 4.11.0. Programs accepted by OCaml 4.10 are unchanged. We are thus releasing OCaml 4.11.1 as an early bugfix version. You are advised to upgrade to this new version if you were using OCaml 4.11.0."
Here is the update to 4.11.1: https://bodhi.fedoraproject.org/updates/FEDORA-2020-93b21a2a63
FEDORA-2020-3f6760cc65 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
FEDORA-2020-3f6760cc65 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3f6760cc65` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-3f6760cc65 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
For some reason, the Fedora Update System never closed this bug.