Closed he32 closed 1 month ago
Duplicate of https://github.com/rust-lang/rust/issues/130099.
tl;dr: While building the new source tarball as part of the build process, we try to vendor all dependencies even if they have already been vendored. Previously the resulting error when offline would be accidentally ignored, but due to a refactoring of the build system it no longer gets ignored, instead aborting the entire build.
As solution try backporting https://github.com/rust-lang/rust/pull/130110 and set dist.vendor = false
in config.toml
. (I think --set dist.vendor=false
would work if you use ./configure
instead of manually creating config.toml
.)
duplicate thus
Duplicate of https://github.com/rust-lang/rust/issues/130099.
tl;dr: While building the new source tarball as part of the build process, we try to vendor all dependencies even if they have already been vendored. Previously the resulting error when offline would be accidentally ignored, but due to a refactoring of the build system it no longer gets ignored, instead aborting the entire build.
I find that a little strange. I would instead have expected that the tarball was entirely self-contained, and required no further verification or updating, especially not during the build phase.
As solution try backporting https://github.com/rust-lang/rust/pull/130110 and set
dist.vendor = false
inconfig.toml
. (I think--set dist.vendor=false
would work if you use./configure
instead of manually creatingconfig.toml
.)
Thanks, did that, and it works, and I can disable the workaround in the package again.
I tried to package rust 1.81.0 for pkgsrc-wip, and while trying to do a native build on NetBSD/amd64, I get:
I expected to see this happen: no download / network access during the build phase, please.
Instead, this happened: I got the above.
The pkgsrc packaging system insists on checksumming all the build components, all to be downloaded in the "fetch" phase and verified against already-recorded checksums, and therefore sets up an un-resolvable proxy to trap exactly this "anti-packaging" behavior. Doing network access of any type during the build phase is at best considered to be "bad form", as the components which go into the build could then vary depending on external unverifiable factors, possibly causing the build to produce inconsistent results between different builds. At worst this could be a security issue.
This means that the 1.81.0 tarball isn't completely "frozen"...
Hints for working around this gratefully accepted.