Review for Package: dh-cargo

[Summary]
it was to be expected for the kind of package that this is, but even
checking in detail did not show any problems on this.

MIR team ACK

This does not need a security review

List of specific binary packages to be promoted to main: dh-cargo
Specific binary packages built, but NOT to be promoted to main: n/a

Notes:
- Just curious, is there a build generating a .lock file somewhere?
  I didn't see one referenced from the bug. I'm Interested to see it
  and maybe convert mdevctl to use it for its embedded source.

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a rust package, no extra constraints to consider in that regard
  (this is perl and shell, not rust itself)

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source (only builds which are untrusted, but
  in a save env).
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems: None

[Common blockers]
OK:
- does not FTBFS currently
- No special HW needed for build/test
- A non-trivial test on this level does not make much sense (for the build
  helper itself alone) but the overall things it helps building are put to
  many tests.

Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest
=> I'd consider both facts ok for the special situation this package is in.
   It is more to facilitate builds and tests of other code than itself.
   The code itself is complex, but not too big yet.
   While it would be nice to have some self-tests on expected behavior
   I consider it ok to have no exhausting tests right now.
   Thanks for adding tests that cover our delta!

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- symbols tracking not applicable for this kind of code.
- d/watch is present not present (ok = native)
- Upstream update history is N/A
- Debian/Ubuntu update history is ok (not many changes recently though)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean (couldn't be less)
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (no languages providing that)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (user visible)?

Problems: None