Skip to content

Conversation

@morisja
Copy link
Collaborator

@morisja morisja commented Oct 12, 2025

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

openwrt/openwrt#20189

rust-lang/cargo@29ecb7f

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

openwrt/openwrt#20189

rust-lang/cargo@29ecb7f
@morisja morisja force-pushed the retire_debian_9_packaging branch from d5aa04d to a39adfb Compare October 12, 2025 17:40
@morisja morisja changed the title Retire Debian 9 specfic handling Retire Debian 9 specific handling Oct 12, 2025
@morisja morisja requested review from geofft and leifwalsh October 12, 2025 17:41
@morisja
Copy link
Collaborator Author

morisja commented Oct 12, 2025

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.

@geofft
Copy link
Collaborator

geofft commented Oct 13, 2025

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/.

@morisja
Copy link
Collaborator Author

morisja commented Oct 15, 2025

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.

@geofft
Copy link
Collaborator

geofft commented Oct 15, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants