sternenseemann b2eb2c8b4f Revert "ocamlPackages.tcpip: 6.0.0 -> 6.1.0" ... This reverts commit 988f5a5910. The release process for many OCaml packages and in extension mirage related packages usually entails creating a release in the respective own repository so a release tarball becomes available and then opening a PR against ocaml/opam-repository to finalize the release. During this new issues can be discovered which push the release back. This happened for mirage-tcpip 6.1.0 several times: https://github.com/ocaml/opam-repository/pull/18357 Prompting in total 3 different 6.1.0 releases with different hashes respectively (the hash for ocamlPackages.tcpip.src shouldn't be reproducible anymore, but we probably have cached the tarball already). Ultimately the PR to opam-repository was closed to investigate some failures on opam-repository's CI and the release postponed: https://github.com/ocaml/opam-repository/pull/18357#issuecomment-808434285 I jumped the gun with the release and updated tcpip in nixpkgs before tcpip was “properly” released in opam. I usually watch the github repository of package I maintain for releases and can react pretty quickly to a release as a result. Most of the time I also check opam-repository's PRs nowadays for extra context or information, but when everything seems fine and tests succeed I deem the update alright to PR to nixpkgs. Being faster than opam was achievable in these cases and actually seems kind of tantalizing. In the light of this experience however, we should wait for the opam PR getting merged at least for some packages that exhibit this behavior of rereleasing the same version number multiple times to get the release just right (afaik the 6.1.0 tag pointed to three different revisions for tcpip). To me this is questionable upstream behavior we just have to deal with in some way.		2021-03-27 14:33:49 +01:00
..
default.nix	Revert "ocamlPackages.tcpip: 6.0.0 -> 6.1.0"	2021-03-27 14:33:49 +01:00