summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
diff options
context:
space:
mode:
authorsternenseemann <0rpkxez4ksa01gb3typccl0i@systemli.org>2021-03-27 00:57:34 +0100
committerVincent Laporte <vbgl@users.noreply.github.com>2021-03-27 14:33:49 +0100
commitb2eb2c8b4f422bee0f5f5a07cd705fadf1cbbc32 (patch)
tree140ad4d9765be718c9a73b6935fe1e3017bbab1b /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
parent477812e18e01cd5b9a7bc8121b2029af24a1afb4 (diff)
Revert "ocamlPackages.tcpip: 6.0.0 -> 6.1.0"
This reverts commit 988f5a5910bdba12f34b500e0dc3aa60042a75a6. 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.
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions