[ANN] opam-check-all: Are your packages broken for the upcoming OCaml releases?

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.

1 Like

Something that would be nice is to be able to filter the list per package maintainer

I very much second that.

@bluddy I just added this feature. There is now a filter to only show the latest version of each packages.

1 Like

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.

@Chris00 @perry @rixed Filter over maintainers is now available. For example:

http://51.145.134.72/?compilers=4.05.0%3A4.06.1%3A4.07.0%2Bbeta2&show-available=4.05.0%3A4.06.1%3A4.07.0%2Bbeta2&maintainers=kate

5 Likes

Nice job, @kit-ty-kate! This tool is so awesome!

Would it be even remotely possible to implement a sort by rev-dep count? That would indicate the highest priority items for the community to update.

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.

1 Like

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.

1 Like

Thanks very much !

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.

In this case it’s not an infrastructure problem, it’s the checksum being wrong but the error message is not really helping (see https://github.com/ocaml/opam/issues/3393)

Are you sure ? I just tried locally and it installed without problem (and git log -- packages/ocaml-manual tells me it has not been altered since published).

mmh weird, I can install it locally but the archive checksums are all over the place:

  • Checksum required: 1649c91a84fd35444192d6a55f932939
  • Checksum from the upstream-archive: 724ac6f96f019999cb83d95adafdda8e
  • Checksum from the opam-archive-mirror: f872fc1411f8190ebc59343c84d464b4

Thanks for your work @kit-ty-kate! I’m trying to figure out why benchmark 1.3.1 (for example) is red on OCaml 4.06.1 despite the constraint available: [ ocaml-version < "4.06.0" ]. Any help will be appreciated.

I confirm this. There seem to be a serious opam issue here I opened https://github.com/ocaml/opam/issues/3401 better not fix the checksum for now so that opam devs can investigate.

That’s great thanks!!

Would be nice to have a different color/status for solver errors (like in http://51.145.134.72/4.05.0/bad/datakit-ci.0.9.0)

@kit-ty-kate In fact it’s not a bug. It’s consistent with what is in your local cache or the online opam v2 cache (which is new to me). See this comment on the issue.

Are you pulling your packages differently ?

As an illustration of this issue, filter for different build status and you’ll notice that lambda-term.1.13 is missing despite the fact that it doesn’t build in 4.05 and 4.06.

The service now has a proper domain name: http://check.ocamllabs.io/

1 Like

@kit-ty-kate At which rate are the results regenerated ? Also indicating the state of the opam-repository (e.g. git hash) you used to make the results would be nice.