twosigma
Retire Debian 9 specific handling
Builds started to fail recently on all debian versions.
The closest reported issue I could find was on openwrt; related to a rustlang change, both are referenced below.
As we no longer build on debian 9 (minimum 11) - I removed the vendor rules target and special handling
https://github.com/openwrt/openwrt/issues/20189
https://github.com/rust-lang/cargo/commit/29ecb7f36a963bed4729bd6909200b4302a366a5
I think this is the correct thing to do (was missing history on why we needed to patch a single crate locally) - but appears to build cleanly on all dists.
Does this PR build successfully internally? It looks like the CI jobs are accessing crates.io over the network, which is what the debian/vendor thing was trying to avoid, and I think that will fail internally.
Or are you using the binary .debs from the public GHA builds and so that isn't a problem for you? If so I think it's fine to drop the vendoring hack entirely, but I'd probably leave a README.source in there saying that the build expects to run with internet access.
It's possible that newer versions of Debian have enough packaged Rust libraries to be able to add then to debian/control as build deps, which would allow the build to happen offline. You might want to take a look at whatever the official Debian packaging for nsncd ended up doing for debian/.
Ahh thanks Geoff, that gives a lot of background. I've been using the deb built here but will test internally. Will test this, try including the debian packages in control, take a look at salsa and update the README.source appropriately.
It's totally fine if you want to decide to stop using the internal build and just use the .debs from here! The git history is kind of confusing. I think I put this setup together before e.g. we were using the GHA builds of twosigma/openjdk.