Control: clone 1069212 -1 Control: reassign -1 dh-cargo Control: affects -1 + src:rust-lalrpop src:rust-sequoia-openpgp debcargo Control: retitle -1 "cargo prepare-debian" should not be invoked by default with --link-from-system
Over on #debian-rust, we did a bit of archaeology to determine why
1069212 is happening.
It looks like tools that use lalrpop by default will descend into the
current working directory and act on any *.lalrpop there.
The reason that they stumble upon unwritable files is that "cargo
prepare-debian" is being invoked with --link-from-system, instead of
just pointing to /usr/share/cargo/registry directly.
cargo prepare-debian is getting --link-from-system by default due to
choices in dh-cargo.
The revision history of *why* this is on by default is unclear, sadly.
We were able to identify two cases where --link-from-system might be
necessary:
0) a case where a crate has no dependencies at all. in that case, on
the buildd, it's possible that /usr/share/cargo/registry doesn't
exist at all (no librust-*-dev packages installed) and so
--link-from-system avoids pointing to a non-existant repo (instead it
points to an empty repo).
1) a case where some crate wants to "vendor" a third-party crate that
isn't packaged for debian directly.
case (1) seems likely to be pretty unusual. Case (0) also seems unusual
(how many dependency-free packages are there?) but also seems like kind
of a distinct bug. if there are no crate dependencies, then there's no
need to ask cargo to look at a repository of crates anyway.
So it seems simpler and more robust to avoid using --link-from-system by
default, and let the crates that really need to use it override it
directly.
If there's a marginally common case for using --link-from-system, maybe
debcargo should grow an configuration choice that those crates that do
need it can just set directly.
--dkg
On Wed 2024-04-17 22:33:54 -0400, Daniel Kahn Gillmor wrote:
> Source: librust-sequoia-openpgp-dev
> Severity: normal
> X-Debbugs-Cc: Daniel Kahn Gillmor <d...@fifthhorseman.net>
>
> Hi all--
>
> If i try building rust-sequoia-openpgp (e.g. using debuild -uc -us) as a
> non-privileged user on a system that has some unnecessary dependencies
> installed, i will sometimes get a failure during build.rs that looks
> something like the following (this example is from building on a system
> that has the previous version of librust-sequoia-openpgp-dev installed):
>
>
> -----
> Running
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
> [sequoia-openpgp 1.20.0] Selected cryptographic backend: Nettle
> [sequoia-openpgp 1.20.0] processing file
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
> [sequoia-openpgp 1.20.0] thread 'main' panicked at 'called `Result::unwrap()`
> on an `Err` value: Os { code: 13, kind: PermissionDenied, message:
> "Permission denied" }', build.rs:10:29
> [sequoia-openpgp 1.20.0] stack backtrace:
> [sequoia-openpgp 1.20.0] 0: rust_begin_unwind
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
> [sequoia-openpgp 1.20.0] 1: core::panicking::panic_fmt
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
> [sequoia-openpgp 1.20.0] 2: core::result::unwrap_failed
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
> [sequoia-openpgp 1.20.0] 3: core::result::Result<T,E>::unwrap
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
> [sequoia-openpgp 1.20.0] 4: build_script_build::main
> [sequoia-openpgp 1.20.0] at ./build.rs:10:5
> [sequoia-openpgp 1.20.0] 5: core::ops::function::FnOnce::call_once
> [sequoia-openpgp 1.20.0] at
> /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
> [sequoia-openpgp 1.20.0] note: Some details are omitted, run with
> `RUST_BACKTRACE=full` for a verbose backtrace.
> error: failed to run custom build command for `sequoia-openpgp v1.20.0
> (/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0)`
>
> Caused by:
> process didn't exit successfully:
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
> (exit status: 101)
> --- stdout
> processing file
> `/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
>
> --- stderr
> Selected cryptographic backend: Nettle
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os
> { code: 13, kind: PermissionDenied, message: "Permission denied" }',
> build.rs:10:29
> stack backtrace:
> 0: rust_begin_unwind
> at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
> 1: core::panicking::panic_fmt
> at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
> 2: core::result::unwrap_failed
> at /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
> 3: core::result::Result<T,E>::unwrap
> at /usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
> 4: build_script_build::main
> at ./build.rs:10:5
> 5: core::ops::function::FnOnce::call_once
> at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
> verbose backtrace.
> dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101
> make: *** [debian/rules:3: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
> 2
> debuild: fatal error at line 1184:
> dpkg-buildpackage -us -uc -ui failed
> -----
>
> The key part of this failure appears to be during build.rs, when lalrpop
> traversing into the custom "cargo_registry" that is built as a symlink
> farm in debian/cargo_registry, where each symlink points to the matching
> crate in the system-installed /usr/share/cargo/registry/
>
> The relevant line in build.rs is line 10, where lalrpop::process_root()
> is invoked:
>
> 7 fn main() {
> 8 crypto_backends_sanity_check();
> 9 include_openssl_conf();
> 10 lalrpop::process_root().unwrap();
> 11 include_test_data().unwrap();
> 12 }
>
> I think this yields a "Permission denied" error when run over a
> directory that the user can't write to, but i haven't investigated
> further.
>
> It's possible that this report should be applied to one of the lalrpop
> crates or something, instead, if the issue isn't something that should
> be fixed in build.rs in the sequoia-openpgp crate. Feel free to
> reassign with a clear explanation.
>
> --dkg
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers testing-debug
> APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'),
> (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1,
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
signature.asc
Description: PGP signature
