Address current rust architecture.mk file

[didrocks]

The file has been moved from the rustc subdirectory to a per version.
The generic rustc subdirectory location does not exist anymore since24.10.
24.04 already has both locations for 1.85.
Move it to point to the location compatible with 24.04+, but we need to have a better agnostic-way in the long term.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.60%. Comparing base (f20db8d) to head (9489fb0).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1157      +/-   ##
==========================================
- Coverage   87.67%   87.60%   -0.07%     
==========================================
  Files          90       90              
  Lines        6222     6222              
  Branches      111      111              
==========================================
- Hits         5455     5451       -4     
- Misses        711      715       +4     
  Partials       56       56              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[adombeck]

The generic rustc subdirectory location does not exist anymore since24.10.

I can confirm that at least on 25.10, dpkg-dev provides /usr/share/dpkg/architecture.mk and /usr/share/rustc/architecture.mk is not provided by any packages. The latter still exists on my system, I assume that's because I upgraded it from 24.04.

I'm trying to understand why that didn't cause any build failures before. How did you discover the issue? Did you see it cause a build failure?

Also trying to understand why on this branch all Debian package builds fail with:

2025-12-10T07:13:35.5640672Z # Build the NSS library
2025-12-10T07:13:35.5647541Z /usr/share/cargo/bin/cargo build --release
2025-12-10T07:13:35.5874320Z debian cargo wrapper: options, profiles, parallel, lto: ['parallel=4'] ['noudeb'] ['-j4'] 0
2025-12-10T07:13:35.5876180Z debian cargo wrapper: rust_type, gnu_type: , x86_64-linux-gnu
2025-12-10T07:13:35.5877251Z debian cargo wrapper: unsetting RUSTFLAGS and assuming it will be (or already was) added to $CARGO_HOME/config.toml
2025-12-10T07:13:35.5878717Z debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', '/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', '-j4', '--target', '', '--release'],) {}
2025-12-10T07:13:35.6064370Z error: target was empty
2025-12-10T07:13:35.6117071Z make[1]: Leaving directory '/home/runner/work/authd/authd/tmp.Q2B2Va0FwS/source'
2025-12-10T07:13:35.6117819Z make[1]: *** [debian/rules:102: override_dh_auto_build] Error 101
2025-12-10T07:13:35.6143221Z make: *** [debian/rules:61: binary] Error 2
2025-12-10T07:13:35.6146581Z dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

[adombeck]

I'm trying to understand why that didn't cause any build failures before. How did you discover the issue? Did you see it cause a build failure?

I now see this message from you on mattermost which I think already answers my question:

I guess the issue is only when building the source package, as the file already does not exist on 24.10 when during the binary build

[adombeck]

I guess the issue is only when building the source package

Maybe we should add a CI job which builds the source package to catch issues like that?

[adombeck]

We do already build the source package in CI: https://github.com/ubuntu/authd/actions/runs/20063065362/job/57544586787#step:3:2752

Why didn't the build fail there? This is getting more and more confusing 😵‍💫