OCaml 4.07.0 is not far from being released, and, as usual, some opam packages need some adjustments or a new compatible release.
To be able to track which packages need fixes I’m please to offer the following webpage which tries to summaries this:
This webpage is for the moment very bleak and needs lots of improvements but is being actively developed.
For the moment the checks are not updated automatically but it’s definitely the next feature I’m planning to add.
The source code is available here:
The purpose of this tool is very close to obi announced here and other similar tools like opamcheck, opam-builder and ows. My apologies if I’m making yet another checker here. opam-check-all started as a small shell script but I recently decided to rewrite it fully as a small OCaml program and use it to check the next OCaml release. I plan to keep it small and easy to use as much as possible.
But anyway, if one day you happen to be bored and you want to fix opam packages, this webpage will be here to help you.
Enjoy.
I think it would be a good idea to only show the last 1 or 2 versions of each package. There are far too many versions shown, giving a much worse impression than is necessary.
Also, what’s the difference between red (fail) and grey. Is grey just not attempted? Or constraints not matching?
The goal is to do a sanity check for every packages and if possible add the necessary constraints where possible. I can add a mode to just show the last version but I think the default one should still show every versions.
Grey means: not available for this switch (either a dependency or the package itself).
OK I see – so the goal is to have no reds anywhere, and no grays on the latest version. Maybe we can summarize that so there isn’t as much noise ie. only show an old version if it’s red, and always show the latest version.
so the goal is to have no reds anywhere, and no grays on the latest version.
I think the main goal is just no reds anywhere. Greys are unavoidable, when an old package version breaks with a new compiler all you can do as add a constraint on it. Ideally packages where the latest version is grey on 4.07 would also do a new green release – but that can happen after the release of 4.07.
I’ve added some new features. For example it is now possible to filter the table in such a way to see only packages that fail on 4.07.0+beta2 but not 4.06.1.
Feel free to take a look at the (much shorter) list and fix it if it’s not related to any compiler bugs:
yes, it has been updated less than a week ago but it’s displaying every packages not just the latest ones.
To see everything just go to the main page or select the filters accordingly.
FYI the “only show packages that have different build status between each compilers” feature doesn’t seem to apply for packages that were green but are now gray, thus missing much of the info.
Thanks @kit-ty-kate, after all these systems eventually one that has exactly the right set of filters a maintainer needs.
One last thing however, the notion of failure is wrong not precise enough e.g. on this page, vg is not to blame, it’s its js-of-ocaml dependency, this should be distinguished somehow.
Fixed and deployed. I’ve introduced a partial failure state and they are displayed as orange instead of red.
I’ll maybe add some other filters to filter out partial failures at some point but I’m not sure that’s needed.
As far as I’m concerned I don’t think it’s needed. I’m interested in knowing one of my package is still failing, but I just wanted to know it was not my fault.
Btw. I’m not sure also whether you can distinguish this. But for example this error http://51.145.134.72/4.05.0/bad/ocaml-manual.4.05.0 seems to be an infrastructure problem not a problem with the package itself.