-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update dream #795
Update dream #795
Conversation
220bc1a
to
505b5bd
Compare
Thanks a lot. When I interpret the CI correctly, we need a mirage release to be able to use mirage-crypto-rng 0.11.0. |
The |
And |
The deployability CI failure:
Would it help to (a) restrict mirage-runtime as well to dune < 3.7 or (b) should we remove the dune bound on mirage 4.3.4 (and leave it open for chamelon users to get failures?)? Any idea what is the path forward (to me it looks like tarides/opam-monorepo#378 tarides/opam-monorepo#342 tarides/opam-monorepo#331 -- all reported and no solution in sight). |
We thought (for Mirage CI and chamelon-based unikernels) this to be a great idea, but unfortunately our mirage-www website unikernel fails (due to opam-monorepo deciding to use dune 3.7.0 and then selecting mirage 4.3.3). The whole story is mirage/mirage-www#795 (comment) combined with mirage/mirage#1401 (comment) For the medium term, we already have another solution in mind.
Merging, thanks a lot. The CI failures, as mentioned by @samoht: fmt addressed in #800 ; dream-httpaf requiring a bound on ke TheLortex/dream#4 |
I have enabled ocaml-ci on my dream fork and opened a PR with the sufficient changes to make the CI happy: TheLortex/dream#3
This PR changes the dream commit to point to the updated version.