Status of the rustc part of the MIR:

There's a package available at https://launchpad.net/~schopin/+archive/ubuntu/rustc-mir/+packages (still building...). I'm aware that there are issues with the armhf build and am still investigating them. Barring that, I feel the package is ready for security review.

I'll walk through the items from cpaelzer review.

I'll leave #1 for a later date (and MIR :D), but I do have the issue in mind.

#2 has been resolved by reverting the bundling of LLVM. We expect to be more proactive in the Foundations team regarding rustc and LLVM, and the latter needs regular upgrades for other components of our releases as well (kernel and mesa)

#3: I've shipped Cargo.lock in /usr/share/doc/rustc/Cargo.lock, the exact location can be revisited. I've checked, it is indeed generated at build time and so is up to date. Note that src:rustc does *not* use dh-cargo so the related points aren't applicable.

#4: Still no action on MIRing dh-cargo at this time.

#5: I've added a self-build autopkgtest to rustc. It actually already caught a small regression in their linkchecker tool that impacts us because we de-bundle the JS and fonts from the doc.

#6: The testsuite is run on s390x, it "just" has a higher failure tolerance than other architectures, with 40 failures allowed (8 for amd64)

#7, #8: I still don't know how to do the exclude definition :-/. As stated earlier, I think the scope of the MIR should be for the rustc and libstd-rust-* packages, with the -doc and all ancillary tooling remaining in universe as they're not essential to the packaging of Rust applications.

#9: LTO has been explicitly disabled in d/rules, with a comment to actually revisit this decision to see if it's still needed.

#10: We'll go with separate LLVM, I'll update the bug description.

#11: Tests have been re-enabled using Debian's "not too many errors" rules as a first step, and I plan on cataloging failures to narrow the policy, but it won't be possible in the near future.

#12: foundations-bugs is now subscribed to both src:rustc and src:cargo

#13: I worked on 1.58.1 directly, as I needed to do some repacking anyway to remove some vendored dependencies that didn't need to be in there (e.g. the curl and openssl crates)



Regarding the MANY warnings during the build, those warnings are basically linting for constructs that used to be necessary but aren't anymore as the compiler gets smarter, and, at least when compiling with the "right" rustc version (meaning the N-1 version), are all explicitly allowed. However, since we need to be able to compile with the *current* version, we've had to lift the blanket deny instruction for all *other* warnings, as new warnings introduced by the version compiled won't be in this allowed list, as we've experienced when working on 1.57. Going forward, an axis of improvement would be to see if it would be possible to actually suppress all the benign warnings to make the new ones stand out.



Regarding armhf:

When mentioning on IRC that the armhf build had some issue, a question was raised of whether we should enable rustc on this architecture at all, especially since rustc tends towards heavy memory consumption.

The armhf platform is currently considered upstream as "Tier 2 with host tools", which means that we should be able to build *and* use rustc and cargo on the platform.

Also, while I understand the sentiment, not having a native rustc on armhf means we'd need to have rock-solid cross-build support for quite a few packages in the archive. I'm not familiar with this particular part of the packaging experience, but I'd wager it's not trivial to set up?