Comment 5 for bug 1993819

Revision history for this message
Zixing Liu (liushuyu-011) wrote : Re: MIR: cargo, dh-cargo

Hi there,

I will take over this MIR in place of Simon and continue what we left off.

> * Do you mind explaining if the state on the testing strategy since 1.58 is better in Ubuntu now? IIRC, you mentioned previously that we were making the build failing only if too many tests are failing. However, with the comitment to main from the foundation team, the goal was to have a better story here and fix/remove flaky tests (as they are useless anyway: are they flaky because of the tests themselves, or is it due to a flaky behaviour, so in the production code itself? Before investigating, there is no way to know about it).

This is because Rust upstream has platform tiering. Some tests are not guaranteed to pass on certain operating systems + CPU combinations. For instance, upstream tests may include float-point arithmitics behavior validations that might not pass on architectures where float-point calculation does not conform fully to IEEE 754 (e.g. MIPS).
Rust upstream only gates the release depending on whether all the Tier 1 platforms pass the tests (see https://doc.rust-lang.org/rustc/platform-support.html for the Tiering, Tier 1 is considered to be both Tier 1 with Host Tools and Tier 1 without Host Tools).

> * I still find there are a lot of warnings during package build (I would say ~300 of valid ones, once you remove the deprecation tests), which is weird for one of the official Rust tooling. Do you know anything we can help to make this better? (the reasoning being: if you got one warning, and another warning, then the next one is just an additional one on the list, which can be a valid issue and go unnotice).

This is because Rust upstream adds new warnings to the compiler nearly every release. Cargo in the Debian tarball is usually pinned to a release branch and does not receive the fixes unless the fix is critical (and in Debian's case, some dependencies are probably not vendored correctly, thus producing warnings, but this will be changed in Ubuntu hopefully very soon).

> * Finally, at the time of the previous MIR, we got a provisional ACK from the security team, do we need more official approvals there?

I am not very sure about the process, I will ask security team about that.