@hannes in the past I had calls
Mirage_crypto_rng_unix.initialize ();
which don’t compile no more due to an interface change. Now I think I need to set_default_generator but have no idea how and where to get one.
Do you have an example how to bootstrap at hand?
Background: I need it e.g. at seppo/shell.ml at 766cb511500c5e21d499872fc1da313089bd2be0 - seppo - Codeberg.org
ah, I found you use
Mirage_crypto_rng_lwt.initialize (module Mirage_crypto_rng.Fortuna)
at update to mirage-crypto 0.11, split tls-lwt away · mirleft/ocaml-tls@cec1903 · GitHub
so this may well be sorted.
Dear @mro,
thanks for bringing this up. Indeed mirage-crypto-rng 0.11.0 has a breaking change (from CHANGES:
BREAKING unify RNG initialization. This means:
Mirage_crypto_rng_lwt.initialize () should now be Mirage_crypto_rng_lwt.initialize (module Mirage_crypto_rng.Fortuna)
Mirage_crypto_rng_unix.initialize () should now be Mirage_crypto_rng_unix.initialize (module Mirage_crypto_rng.Fortuna)
The reasoning is uniformity across mirage-crypto-rng-* initialize functions (unix, lwt, async, eio, mirage) – the inconsistency was spotted by @talex5 in https://github.com/mirage/mirage-crypto/pull/155, then preserved in RNG initialization inconsistencies · Issue #160 · mirage/mirage-crypto · GitHub as issue, and fixed in [API change] rng: unify API for initialize, as reported in #160 by hannesm · Pull Request #162 · mirage/mirage-crypto · GitHub.
that plus slightly changed opam install dependencies. I had to reflect crypto package / api change. · 121fbc1f32 - seppo - Codeberg.org
(figured that out not before making myself and idiot with a somewhat erratic report and bothering @dbuenzli at Ptime_clock unavailable on 32bit raspbian? · Issue #33 · dbuenzli/ptime · GitHub, lol)
That’s not making yourself an idiot, that the result of the poor library dependency model we have now ((implicit_transitive_deps true)) hopefully RFC 31 is a first step towards more sanity.
2 posts were split to a new topic: Generating a bills of material for a build