[opam-devel] OPAM 1.2.1 / 1.3.0 status update
anil at recoil.org
Mon Mar 16 08:28:54 GMT 2015
> On 16 Mar 2015, at 00:54, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
>> Green light from me! To be clear, does the 1.2 branch now reflect the final RC version? I can build 1.2.1 RPM/Debs from that.
> Yes, I updated it as I pushed the RC2, and your PPAs (2015-03-04) are up-to-date.
>> I think we should make a concerted effort to get 1.2.1 upstream into Ubuntu so that it hits the next LTS cycle. Hopefully it isn't too late for the Debian release cycle too...
> Debian: we can see with our friends in the team, but as Jessie is in complete freeze at the moment and 1.2.1 doesn't fix any critical bugs, I wouldn't count on it (https://release.debian.org/jessie/freeze_policy.html)
> Ubuntu: Indeed -- (sigh) hopefully we'll get more response than on https://bugs.launchpad.net/ubuntu/+source/opam/+bug/1401346
I hope they take something not from Debian... can we get something into Debian unstable that won't make it into Testing at this stage?
>> There's just one thing that would be useful, but may not be practical. I'd really like to run the Travis tests with OPAMSTRICT set so that warnings turn into hard failures. However, we currently hit this:
>> [WARNING] Directory /Users/travis/.opam/system/lib/camlp4 is not empty, not
> May be counter-intuitive, but there is no warnings-as-errors flags, `--strict` only relates to errors in files (failing on first error rather than ignoring the file -- if possible). That may, in this case, be more convenient though !
>> message all the time, and it's hard to fix I think. Any thoughts on whether there's a workaround in opam-repository to make this message go away, or whether OPAM 1.2.1 should show it at all?
> I can remove it altogether; what hold me back is that it usually doesn't appear in normal usage, and can provide meaningful information that I don't see how to make available otherwise. Hopefully 1.3.1 will have file tracking, removing the need for this.
That all actually sounds ok without needing any change in the RC then -- how about pushing an OPAMSTRICT=1 to the (allowed-to-fail) 1.2.1 matrix in the current opam-repository?
More information about the opam-devel