> On 16 Mar 2015, at 00:54, Louis Gesbert <[email protected]> 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 >> removing >> > > 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? -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
