swendel/nixpkgs
1
0
Fork 0
mirror of https://github.com/SebastianWendel/nixpkgs.git synced 2024-10-18 03:33:18 +02:00
Code Issues Packages Projects Releases Wiki Activity
nixpkgs/pkgs/development/ocaml-modules/tcpip/default.nix

71 lines
1.5 KiB
Nix
Raw Normal View History

ocamlPackages.tcpip: init at 6.0.0
2020-12-29 23:45:06 +01:00
{ lib, buildDunePackage, fetchurl
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.
2021-03-27 00:57:34 +01:00
, bisect_ppx, ppx_cstruct
ocamlPackages.tcpip: init at 6.0.0
2020-12-29 23:45:06 +01:00
, rresult, cstruct, cstruct-lwt, mirage-net, mirage-clock
, mirage-random, mirage-stack, mirage-protocols, mirage-time
, ipaddr, macaddr, macaddr-cstruct, mirage-profile, fmt
, lwt, lwt-dllist, logs, duration, randomconv, ethernet
, alcotest, mirage-flow, mirage-vnetif, pcap-format
, mirage-clock-unix, arp, ipaddr-cstruct, mirage-random-test
, lru
}:
buildDunePackage rec {
pname = "tcpip";
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.
2021-03-27 00:57:34 +01:00
version = "6.0.0";
ocamlPackages.tcpip: init at 6.0.0
2020-12-29 23:45:06 +01:00
useDune2 = true;
src = fetchurl {
url = "https://github.com/mirage/mirage-${pname}/releases/download/v${version}/${pname}-v${version}.tbz";
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.
2021-03-27 00:57:34 +01:00
sha256 = "0wbrs8jz1vw3zdrqmqcwawxh4yhc2gy30rw7gz4w116cblkvnb8s";
ocamlPackages.tcpip: init at 6.0.0
2020-12-29 23:45:06 +01:00
};
nativeBuildInputs = [
bisect_ppx
ppx_cstruct
];
propagatedBuildInputs = [
rresult
cstruct
cstruct-lwt
mirage-net
mirage-clock
mirage-random
mirage-random-test
mirage-stack
mirage-protocols
mirage-time
ipaddr
macaddr
macaddr-cstruct
mirage-profile
fmt
lwt
lwt-dllist
logs
duration
randomconv
ethernet
lru
];
doCheck = true;
checkInputs = [
alcotest
mirage-flow
mirage-vnetif
pcap-format
mirage-clock-unix
arp
ipaddr-cstruct
];
meta = with lib; {
description = "OCaml TCP/IP networking stack, used in MirageOS";
homepage = "https://github.com/mirage/mirage-tcpip";
maintainers = [ maintainers.sternenseemann ];
license = licenses.isc;
};
}
Reference in a new issue Copy permalink