How do you install OCaml with Jane Street's Core using OPAM? - opam

The simple directions found all over the internet for installing Core using OPAM no longer work. What is the new way to install and use Core?
I think I tracked the problem down to a message on the ocaml-core mailing list about renaming several dependencies https://groups.google.com/forum/#!topic/ocaml-core/Te6LTiNBO08.
Paired down, the widely published installation instructions amount to two steps after installing opam itself:
$ opam install core
$ cat >> ~/.ocamlinit <<EOF
#use "topfind";;
#thread;;
#camlp4o;;
#require "core.top";;
#require "core.syntax";;
EOF
Following these directions result in an error about the "sexprlib.syntax" package missing when using ocaml (or corebuild, utop, etc).
Failing directions can be found in this widely referenced ebook
https://github.com/realworldocaml/book/wiki/Installation-Instructions#setting-up-and-using-utop
and are reflected in directions here on Stackoverflow in questions such as:
Ocaml utop library paths, Core module
What is the new way to set up Core?
opam install core no longer seems to be sufficient since it does not pull in the new syntax packages. I am not sure if this is a dependency bug or not.
The recommended ocamlinit settings also seem wrong.

I found that the core 113.24.00 is defective and all the installation instructions on the net as of this writing are out of date.
Users must make the following corrective steps:
Remove all #require references to packages ending in .syntax from ~/.ocamlinit.
Make your own corebuild script without any references to syntax packages
as found at https://github.com/janestreet/core/blob/master/corebuild.
You may also remove the #camlp4o;; line from your .ocamlinit as this library is no longer required by Core.

Related

Is an opam pin project needed when one wants to install an opam project with opam reinstall or 'make'?

I am trying to understand when one needs to pin an opam package.
I am seeing some code that pins a package, e.g., with
command = (['opam', 'pin', '-y']
+ root_option()
+ ['--switch', switch]
+ [coq_package_name, coq_package_pin_path])
And then it tries to reinstall it with:
command: list = ['opam',
'reinstall',
root_option(),
'--yes',
'--switch',
switch,
'--keep-build-dir',
coq_package_name]
Is the pin really needed for the opam reinstallation to work? What might be the rationale to do such a pin before the opam reinstallation?
In addition I am also installing some packages with make and am wondering if that is needed:
command: list = ['make', '-C', coq_proj_path]
My guess based on the related OCaml forum thread (URL below)
The OCaml forum thread says:
As the documentation states, opam pin “allows local customisation of the packages in a given switch” (or “divert any package definition”, in the part you quoted). So, if you do not need to replace an official package definition with your own customization, just use opam install.
In my case, I am downloading the Coq project source and then installing it myself from it -- either with opam install or make. With make I can just pass the direct path. With opam install, the pin command actually "maps" the name to the exact path of the project. So my guess is that in my application (due to using the Coq projects myself) I do need the opam pin.
Related:
(OCaml forum thread) What is the difference between opam pin and opam install, when to use one vs the other?
related, gitissue that inspired this: https://github.com/IBM/pycoq/issues/6
My understanding is that there are multiple ways to install an ocaml package.
opam install uses the ocaml_pkg.opam file. Usually the build command is there and the build is done with opam and made aware to opam. Specific versions can be made according to the official opam repo on the internet too!
opam pin usually installs pkgs that require specific local or online version (e.g. through git commits). Opam will be made the install.
I assume reinstall works similarly to opam install.
Building through source by say cloning pkg/proj and running the build command directly (e.g. if it has a opam file running that or running make in the home of the or some variant of it of make proj/pkg )

Getting Undefined subroutine utf8::SWASHNEW called at Bugzilla/Util.pm line 109

I am trying to install Bugzilla. For that Strawberry perl, Microsoft IIS, MySQL are installed with latest versions. Followed guidelines given on Bugzilla installation page for windows.
Whenever I run checksetup.pl, all necessary perl modules related to Bugzilla are installed correctly. Only three optional modules were not installed (perl-ldap, mod_perl and Apache-SizeLimit). And then it is showing an error:
Undefined subroutine utf8::SWASHNEW called at Bugzilla/Util.pm line 109.
Move back to Strawberry Perl 5.28.2.1 from 5.30.0.1
I had same problem. This fixed.
I managed to fix this by applying the first of the following patch
(use
locate Safe.pm
to find the offending file)
DISCLAIMER - AT YOUR OWN RISK
Perl on github, patch for bug 17291

How to apply puppet manifests and modules WITHOUT installing Puppet RPM?

I would like to create an RPM package that applies a Puppet manifest on a server which does not contain Puppet, Facter and Hiera.
Also, and more importantly, I should be able to apply it WITHOUT being obliged to install neither of these tools (Puppet, Facter, Hiera) on the production server.
So basically, the package should run the following command without installing any of the required packages:
puppet apply install.pp --modulepath=./modules --hiera_config=./conf/hiera.yaml
How can I proceed to make such a package ? Is it a good idea to extract the 'binary' files the Puppet/Hiera/Facter RPMs to include them in another one ?
Thanks!
Installing the relevant packages and then removing them would be by far the fastest and safest way to do what you wish. Maybe you can convince your customer that the cost in time for any other solution is not worth the money.
Anyway, if packages are not an option, let's be innovative:
You do not have to install from packages, you can install puppet via ruby gems
In the same way, you can use source tarballs
Those two options might work, but are not innovative enough.
What about installing puppet 'locally' on a disk via the gems or the tarballs, and then mounting this disk via nfs?
While we are here, why not do the same but then mount using sshfs?
still with the idea of a having first a remote install, you could indeed repackage it via fpm (amazing tool, very strongly recommended). You still end up with a package, but a local one which will not require adding a repository, this might alleviate some of your client concerns.
building on this, if the issue is with repositories, not packages, you could download all required packages and install them manually
I guess that the summary of this answer is that the value of doing so is negative compared to using what you distribution provides.

How do I compile/build against Ocamlodbc

I've installed Ocamlodbc using opam install odbc, but I can't work out how to build an app that uses it with ocamlbuild. The examples that come with the source don't build either.
If I put
#require "odbc";;
into my .ocamlinit, I can open Odbc_unixodbc;; in utop, but any reference to functions in that module result in a "Reference to undefined global 'Odbc_unixodbc'" error.
The following snippet also fails with an error about no implementation for "Odbc_unixodbc"
open Odbc_unixodbc
let () = ignore (Odbc_unixodbc.connect "DSN" "UID" "PWD")
Trying
open Odbc
fails with "Unbound module Odbc"
I'm building the code with
ocamlbuild -pkg odbc test.native
The generated documentation for the package seem to suggest I should be opening the "Ocamlodbc" module, but that also results in an "Unbound module" error.
TL;DR
ocamlbuild -use-ocamlfind -pkg odbc test.native
Description
-use-ocamlfind tells ocamlbuild to use ocamlfind system to find libraries on your system. Otherwise, without this flag, you need to provide flags with concrete locations and also take care of the package dependencies. So, it is a good idea to always use ocamlfind.
If this command still doesn't work for you, then make sure, that you chose the right package name. You can use ocamlfind list to look at the set of all packages available on your system.
Further reading
While the above is ok for small programs, I would suggest to use OASIS system to handle all the flags for you.
You can start from this example, adapting dependency list to your neeeds.

"Your GStreamer installation is missing a plug-in." (GstURIDecodeBin)

I have: gstreamer-sdk, gstreamer-ffmpeg, gstreamer-plugins-good, bad, and ugly. I googled everywhere for this error and have found nothing relevant. I'm going a little nuts trying to figure out this error:
Error received from element decodebin20: Your GStreamer installation is missing a plug-in.
Debugging information: gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20:
no suitable plugins found
It throws when I run my gstreamer program. Any ideas on why?
You may not be missing any plugins at all.
This error can be a result of just an unlinked pipeline.
Playbin2(decodebin2) got some changes that made it unable to automatically link up some pipelines that formally worked, for example transcoding a decoder to an encoder. In my case, explicitly adding the ffdec_h264 that it used to add automatically fixed it.
Relying on the Playbin2 can be very frustrating when it does not work. Using the setup below, you can create a .png diagram of the pipeline in various phases of construction. It's very helpful in finding why it isn't linking up.
export GST_DEBUG_DUMP_DOT_DIR=~/gstdump
for f in $GST_DEBUG_DUMP_DOT_DIR/*.dot ; do dot -T png $f >$f.png; done
This tool also lets you learn from it how to link up pipelines, and replace them with explicit ones that are easier to debug and less likely to break.
In Fedora, I resolved this issue removing gstreamer1-vaapi.x86_64:
sudo yum remove gstreamer1-vaapi.x86_64
uridecodebin is part of the "base" plugin set, so make sure you have gstreamer-plugins-base.
Another thing to look into is your LD_LIBRARY_PATH and GST_PLUGIN_PATH. If they point to a different GStreamer installation, it could cause problems like this. Also, if you didn't install GStreamer with a package manager, you may need to set your LD_LIBRARY_PATH to point to it (or better yet, install it with a package manager).
Pleas try to use gst-inspect command to find out if environment is correctly setup.
use gst-launch -v playbin2 uri = "your_uri_here" to find more information to trace this issue.

Resources