On Wed 21/10/2026 17:46, Lydia Sobot wrote: > On Wed Oct 21, 2026 at 16:56 CEST, Bjorn Ketelaars wrote: > > ipset crate was already needed for getting 2.5.1 to build: > > > > -MODCARGO_CRATES += ipset 0.9.0 # MIT > > > > This is because ipset is part of Cargo.lock, see the relevant Cargo.lock > > entry: > > https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2130-2140 > > > > The reason for vendoring it now is that the current version requires a > > specific branch of the crate which isn't available through crates.io. > > > > The same applies to the jrsonnet* crates, for example these Cargo.lock > > entries: > > https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2530-2547 > > > > So unless I'm overlooking something, I think the fact that ipset itself > > targets Linux is separate from why we need to vendor it here. > Yes, I understand that part, I'm just pointing out that in theory that > is the less important crate between itself and jsonnet lol, what I am > more curious about is from a ports infrastructure viewpoint: why do we > need to have a separate mirror of this stuff when it can presumably be > fetched at download time like all the normal crates, perhaps with some > DIST_TUPLE-like construct? Is it due to the branch switch? > > > > BTW, sysutils/reaction currently has no MAINTAINER. Would you be > > interested in taking it? If not, I’d be happy to pick it up. > I had already expressed interest in taking maintainer for this, yes, > especially considering I am in contact with upstream (Cced). However, I > must defer to your packaging expertise here, so if you don't mind me > bothering you in case something with this vendoring (or something > similar) comes up in later releases, I'll be happy to take maintainer :) Great! I'll leave it up to you to revise the diff, and include MAINTAINER. Feel free to ask questions. Initially I did try to use DIST_TUPLE similar to what was done once for security/vaultwarden [0]. I did not succeed because jrsonnet is split up it multiple crates, and I do not know how to move forward on this. In the end vendoring was easier. [0] https://github.com/openbsd/ports/commit/f3e46e6c2019aede525888f3c00de8b55ed82093
Wednesday, October 21, 2026
Re: UPDATE sysutils/reaction-2.6.0
On Wed Oct 21, 2026 at 16:56 CEST, Bjorn Ketelaars wrote: > ipset crate was already needed for getting 2.5.1 to build: > > -MODCARGO_CRATES += ipset 0.9.0 # MIT > > This is because ipset is part of Cargo.lock, see the relevant Cargo.lock > entry: > https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2130-2140 > > The reason for vendoring it now is that the current version requires a > specific branch of the crate which isn't available through crates.io. > > The same applies to the jrsonnet* crates, for example these Cargo.lock > entries: > https://framagit.org/ppom/reaction/-/blob/main/Cargo.lock?ref_type=heads&blame=0#L2530-2547 > > So unless I'm overlooking something, I think the fact that ipset itself > targets Linux is separate from why we need to vendor it here. Yes, I understand that part, I'm just pointing out that in theory that is the less important crate between itself and jsonnet lol, what I am more curious about is from a ports infrastructure viewpoint: why do we need to have a separate mirror of this stuff when it can presumably be fetched at download time like all the normal crates, perhaps with some DIST_TUPLE-like construct? Is it due to the branch switch? > > BTW, sysutils/reaction currently has no MAINTAINER. Would you be > interested in taking it? If not, I’d be happy to pick it up. I had already expressed interest in taking maintainer for this, yes, especially considering I am in contact with upstream (Cced). However, I must defer to your packaging expertise here, so if you don't mind me bothering you in case something with this vendoring (or something similar) comes up in later releases, I'll be happy to take maintainer :)