What is the recommended way to contact the Ocaml maintainers?
There is a systematic packaging bug which introduces unusable i686 packages into the x86_64 compose, and despite repeated messages to ocaml-devel, I did not receive a response:
https://lists.fedoraproject.org/pipermail/ocaml-devel/2014-July/002265.html
On Fri, 22 Aug 2014 21:11:50 +0200 Florian Weimer fw@deneb.enyo.de wrote:
What is the recommended way to contact the Ocaml maintainers?
There is a systematic packaging bug which introduces unusable i686 packages into the x86_64 compose, and despite repeated messages to ocaml-devel, I did not receive a response:
https://lists.fedoraproject.org/pipermail/ocaml-devel/2014-July/002265.html
hm, Richard (rwmjones) is usually very responsive ...
I think the solution for the i686 ocaml devel files is to update the multilib policy in mash to exclude ocaml-* completely
Dan
On Fri, Aug 22, 2014 at 09:17:16PM +0200, Dan Horák wrote:
On Fri, 22 Aug 2014 21:11:50 +0200 Florian Weimer fw@deneb.enyo.de wrote:
What is the recommended way to contact the Ocaml maintainers?
There is a systematic packaging bug which introduces unusable i686 packages into the x86_64 compose, and despite repeated messages to ocaml-devel, I did not receive a response:
https://lists.fedoraproject.org/pipermail/ocaml-devel/2014-July/002265.html
This list is dead AFAIK. I certainly haven't read it in many years, and we've been trying to delete it (without success, it seems).
hm, Richard (rwmjones) is usually very responsive ...
I think the solution for the i686 ocaml devel files is to update the multilib policy in mash to exclude ocaml-* completely
As Dan says, multilib is inappropriate for OCaml. There's never any reason why you would want to use 32 bit OCaml packages if you have a 64 bit machine. So simply blocking i686 on x86-64 is the way to go.
There is even a bug about it, but I cannot find it in BZ right now.
Rich.
On Fri, 22 Aug 2014 21:01:16 +0100 "Richard W.M. Jones" rjones@redhat.com wrote:
On Fri, Aug 22, 2014 at 09:17:16PM +0200, Dan Horák wrote:
On Fri, 22 Aug 2014 21:11:50 +0200 Florian Weimer fw@deneb.enyo.de wrote:
What is the recommended way to contact the Ocaml maintainers?
There is a systematic packaging bug which introduces unusable i686 packages into the x86_64 compose, and despite repeated messages to ocaml-devel, I did not receive a response:
https://lists.fedoraproject.org/pipermail/ocaml-devel/2014-July/002265.html
This list is dead AFAIK. I certainly haven't read it in many years, and we've been trying to delete it (without success, it seems).
hm, Richard (rwmjones) is usually very responsive ...
I think the solution for the i686 ocaml devel files is to update the multilib policy in mash to exclude ocaml-* completely
As Dan says, multilib is inappropriate for OCaml. There's never any reason why you would want to use 32 bit OCaml packages if you have a 64 bit machine. So simply blocking i686 on x86-64 is the way to go.
There is even a bug about it, but I cannot find it in BZ right now.
patch for mash sent as https://lists.fedoraproject.org/pipermail/buildsys/2014-August/004357.html
Dan
On Fri, Aug 22, 2014 at 10:12:52PM +0200, Dan Horák wrote:
On Fri, 22 Aug 2014 21:01:16 +0100 "Richard W.M. Jones" rjones@redhat.com wrote:
On Fri, Aug 22, 2014 at 09:17:16PM +0200, Dan Horák wrote:
On Fri, 22 Aug 2014 21:11:50 +0200 Florian Weimer fw@deneb.enyo.de wrote:
What is the recommended way to contact the Ocaml maintainers?
There is a systematic packaging bug which introduces unusable i686 packages into the x86_64 compose, and despite repeated messages to ocaml-devel, I did not receive a response:
https://lists.fedoraproject.org/pipermail/ocaml-devel/2014-July/002265.html
This list is dead AFAIK. I certainly haven't read it in many years, and we've been trying to delete it (without success, it seems).
hm, Richard (rwmjones) is usually very responsive ...
I think the solution for the i686 ocaml devel files is to update the multilib policy in mash to exclude ocaml-* completely
As Dan says, multilib is inappropriate for OCaml. There's never any reason why you would want to use 32 bit OCaml packages if you have a 64 bit machine. So simply blocking i686 on x86-64 is the way to go.
There is even a bug about it, but I cannot find it in BZ right now.
patch for mash sent as https://lists.fedoraproject.org/pipermail/buildsys/2014-August/004357.html
Thanks. Although obviously I'm not able to test that particular patch, it does look like the right fix.
Rich.
And would this be a good place to say that the OCaml 4.02.0+rc1 rebuild is now under way?
Well, it is. I'm expecting that all packages should rebuild without any problems.
It may take a couple of days to rebuild them all. This rebuild only affects Rawhide.
Rich.
On Fri, Aug 22, 2014 at 09:18:31PM +0100, Richard W.M. Jones wrote:
And would this be a good place to say that the OCaml 4.02.0+rc1 rebuild is now under way?
Well, it is. I'm expecting that all packages should rebuild without any problems.
It may take a couple of days to rebuild them all. This rebuild only affects Rawhide.
This is complete now. There were four or five packages which didn't rebuild which I'll look at after the UK public holiday.
Rich.
On Sun, Aug 24, 2014 at 9:28 AM, Richard W.M. Jones rjones@redhat.com wrote:
This is complete now. There were four or five packages which didn't rebuild which I'll look at after the UK public holiday.
Your rebuild script did coq, flocq, and why3, but not gappalib-coq, frama-c, or why. There are ordering dependencies here, too. Could you modify it so that it builds those packages in this order?
coq flocq gappalib-coq why3 frama-c why
I'll get them rebuilt this time, but it would be nice if that was done automatically for future rebuilds.
Also, the ocaml-tplib build is failing because this invocation:
ocamlbuild -cflag -g -lflag -g -ocamlc ocp-ocamlc.opt -ocamlopt ocp-ocamlopt.opt -classic-display -no-links -build-dir _build -use-ocamlfind src/tplib.mllib src/numeric.cmi src/semiring.cmi src/vector.cmi src/halfspace.cmi src/hypergraph.cmi src/tplib_core.cmi src/tplib_abstract.cmi src/numeric_plugins/zarith_plugin.cmxs src/bindings/tplib_double_callback.obj.o src/bindings/tplib_rational_callback.obj.o src/compute_ext_rays.native src/compute_ext_rays_polar.native src/compute_halfspaces.native src/compute_tangent_hypergraph.native src/compute_minimal_external_representations.native src/compute_tropical_complex.native
prompts ocamlbuild to issue this command:
ocamlfind ocp-ocamlopt.opt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
but ocamlfind doesn't know anything about an ocp-ocamlopt.opt command:
Usage: ocamlfind query [-help | other options] <package_name> ... or: ocamlfind ocamlc [-help | other options] <file> ... or: ocamlfind ocamlcp [-help | other options] <file> ... or: ocamlfind ocamlmklib [-help | other options] <file> ... or: ocamlfind ocamlmktop [-help | other options] <file> ... or: ocamlfind ocamlopt [-help | other options] <file> ... or: ocamlfind ocamloptp [-help | other options] <file> ... or: ocamlfind ocamldep [-help | other options] <file> ... or: ocamlfind ocamlbrowser [-help | other options] or: ocamlfind ocamldoc [-help | other options] <file> ... or: ocamlfind install [-help | other options] <package_name> <file> ... or: ocamlfind remove [-help | other options] <package_name> or: ocamlfind printconf [-help] [variable] or: ocamlfind list or: ocamlfind pkg/cmd arg ... Select toolchain with: ocamlfind -toolchain <t> <command> Abbreviations: e.g. ocamlfind opt instead of ocamlfind ocamlopt Command exited with code 2.
If I build for Fedora 21 instead, that same ocambuild invocation results in this command being issued:
ocamlfind ocamlopt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
which works. Apparently the meaning of the -ocamlopt option to ocamlbuild has changed. Do you have any suggestions on how to deal with the situation?
Thanks,
On Mon, Aug 25, 2014 at 01:22:04PM -0600, Jerry James wrote:
On Sun, Aug 24, 2014 at 9:28 AM, Richard W.M. Jones rjones@redhat.com wrote:
This is complete now. There were four or five packages which didn't rebuild which I'll look at after the UK public holiday.
Your rebuild script did coq, flocq, and why3, but not gappalib-coq, frama-c, or why. There are ordering dependencies here, too.
I don't have any control over the build ordering.
The script should build them in BuildRequires order automatically. However in this case I have blocked frama-c and gappalib-coq because they didn't build in the previous round, see:
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c7082...
The script also blocks any dependencies recursively.
If they build now, I can unblock them and their dependencies and rerun the script.
Also, the ocaml-tplib build is failing because this invocation:
ocamlbuild -cflag -g -lflag -g -ocamlc ocp-ocamlc.opt -ocamlopt ocp-ocamlopt.opt -classic-display -no-links -build-dir _build -use-ocamlfind src/tplib.mllib src/numeric.cmi src/semiring.cmi src/vector.cmi src/halfspace.cmi src/hypergraph.cmi src/tplib_core.cmi src/tplib_abstract.cmi src/numeric_plugins/zarith_plugin.cmxs src/bindings/tplib_double_callback.obj.o src/bindings/tplib_rational_callback.obj.o src/compute_ext_rays.native src/compute_ext_rays_polar.native src/compute_halfspaces.native src/compute_tangent_hypergraph.native src/compute_minimal_external_representations.native src/compute_tropical_complex.native
prompts ocamlbuild to issue this command:
ocamlfind ocp-ocamlopt.opt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
but ocamlfind doesn't know anything about an ocp-ocamlopt.opt command:
Usage: ocamlfind query [-help | other options] <package_name> ... or: ocamlfind ocamlc [-help | other options] <file> ... or: ocamlfind ocamlcp [-help | other options] <file> ... or: ocamlfind ocamlmklib [-help | other options] <file> ... or: ocamlfind ocamlmktop [-help | other options] <file> ... or: ocamlfind ocamlopt [-help | other options] <file> ... or: ocamlfind ocamloptp [-help | other options] <file> ... or: ocamlfind ocamldep [-help | other options] <file> ... or: ocamlfind ocamlbrowser [-help | other options] or: ocamlfind ocamldoc [-help | other options] <file> ... or: ocamlfind install [-help | other options] <package_name> <file> ... or: ocamlfind remove [-help | other options] <package_name> or: ocamlfind printconf [-help] [variable] or: ocamlfind list or: ocamlfind pkg/cmd arg ... Select toolchain with: ocamlfind -toolchain <t> <command> Abbreviations: e.g. ocamlfind opt instead of ocamlfind ocamlopt Command exited with code 2.
If I build for Fedora 21 instead, that same ocambuild invocation results in this command being issued:
ocamlfind ocamlopt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa -g -linkpkg myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
which works. Apparently the meaning of the -ocamlopt option to ocamlbuild has changed. Do you have any suggestions on how to deal with the situation?
I'm not very familiar with ocamlbuild. In fact I didn't and still don't agree with it on principle. Guess we need to ask upstream to fix this.
Rich.
On Tue, Aug 26, 2014 at 2:02 AM, Richard W.M. Jones rjones@redhat.com wrote:
The script should build them in BuildRequires order automatically. However in this case I have blocked frama-c and gappalib-coq because they didn't build in the previous round, see:
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c7082...
The script also blocks any dependencies recursively.
If they build now, I can unblock them and their dependencies and rerun the script.
I've already rebuilt them, so no need to rerun the script. And, yes, they built successfully this time around.
I'm not very familiar with ocamlbuild. In fact I didn't and still don't agree with it on principle. Guess we need to ask upstream to fix this.
Just for clarification: "we == you" or "we == me"? :-) Thanks,
On Tue, Aug 26, 2014 at 09:12:34AM -0600, Jerry James wrote:
On Tue, Aug 26, 2014 at 2:02 AM, Richard W.M. Jones rjones@redhat.com wrote:
The script should build them in BuildRequires order automatically. However in this case I have blocked frama-c and gappalib-coq because they didn't build in the previous round, see:
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=c7082...
The script also blocks any dependencies recursively.
If they build now, I can unblock them and their dependencies and rerun the script.
I've already rebuilt them, so no need to rerun the script. And, yes, they built successfully this time around.
I'm not very familiar with ocamlbuild. In fact I didn't and still don't agree with it on principle. Guess we need to ask upstream to fix this.
Just for clarification: "we == you" or "we == me"? :-) Thanks,
Go for it if you have time. If not then I'll ask in a few days.
Rich.
On Tue, Aug 26, 2014 at 3:08 PM, Richard W.M. Jones rjones@redhat.com wrote:
Go for it if you have time. If not then I'll ask in a few days.
Asked here: https://groups.google.com/forum/#!topic/fa.caml/C6_VauENVgo
On Thu, Aug 28, 2014 at 01:41:55PM -0600, Jerry James wrote:
On Tue, Aug 26, 2014 at 3:08 PM, Richard W.M. Jones rjones@redhat.com wrote:
Go for it if you have time. If not then I'll ask in a few days.
Asked here: https://groups.google.com/forum/#!topic/fa.caml/C6_VauENVgo
Thanks.
On an unrelated topic, there is now an upstream fix for the ocaml-camlimages problem (or at least one of them). See:
http://caml.inria.fr/mantis/view.php?id=6517
I'll add this patch to the compiler header files in the next iteration, ie. 4.02.0-rc2.
Rich.
On Fri, Aug 29, 2014 at 3:37 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Aug 28, 2014 at 01:41:55PM -0600, Jerry James wrote:
Asked here: https://groups.google.com/forum/#!topic/fa.caml/C6_VauENVgo
Thanks.
This was apparently already reported as PR#6300: http://caml.inria.fr/mantis/view.php?id=6300.
On an unrelated topic, there is now an upstream fix for the ocaml-camlimages problem (or at least one of them). See:
http://caml.inria.fr/mantis/view.php?id=6517
I'll add this patch to the compiler header files in the next iteration, ie. 4.02.0-rc2.
It looks like the ocaml team has elected to go straight for the final 4.02.0 release. Since PR#6300 is on the list of fixed bugs, hopefully that means that ocaml-tplib will build successfully on the next try. Regards,
On Fri, Aug 29, 2014 at 12:26:35PM -0600, Jerry James wrote:
On Fri, Aug 29, 2014 at 3:37 AM, Richard W.M. Jones rjones@redhat.com wrote:
I'll add this patch to the compiler header files in the next iteration, ie. 4.02.0-rc2.
It looks like the ocaml team has elected to go straight for the final 4.02.0 release. Since PR#6300 is on the list of fixed bugs, hopefully that means that ocaml-tplib will build successfully on the next try.
Just saw that. I'll hopefully be able to do a 4.02.0 final release this weekend.
Rich.
devel@lists.stg.fedoraproject.org
-
Dan Horák -
Florian Weimer -
Jerry James -
Richard W.M. Jones