Remove cargo-deny exception for intel-mkl-src

[Tastaturtaste]

As conversed about in PR #369, this PR removes the cargo-deny exclusion for intel-mkl-src introduced due to EmbarkStudios/krates#60.

This PR should be merged as soon as EmbarkStudios/krates#61 lands in cargo-deny-action.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.48%. Comparing base (be2444e) to head (711798a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #386      +/-   ##
==========================================
- Coverage   91.49%   91.48%   -0.01%     
==========================================
  Files         178      177       -1     
  Lines       23623    23624       +1     
==========================================
- Hits        21613    21612       -1     
- Misses       2010     2012       +2     

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

[jedbrown]

It seems this is all complete. Should this be merged now?

[Tastaturtaste]

It seems this is all complete. Should this be merged now?

The CI build should be rerun to confirm. If that is green it should be good to merge.

[stefan-k]

Would you mind rebasing this PR or allowing me to push to it? Thanks! :)

[Tastaturtaste]

I can rebase in the next few days. Also, permission for maintainer to edit this PR should already be given.

[Tastaturtaste]

Seems like cargo-deny picks up intel-mkl-src through the "examples" crates, even though those crates have "publish = false" set in their manifest and "deny.toml" has "licenses.private.ignore = true" set. If the "examples" folder is just removed from the workspace manifest members there are no license errors. I think this might not be the intended behavior for the "licenses.private.ignore" option of cargo deny. Maybe this is another bug in their implementation? I don't have the time to look closer into this right now. Maybe in the next few days, but no promises.

[stefan-k]

Thanks for the quick rebase, and thanks for digging into this. I've also had a look, and I suspect the path based dependencies are treated differently. I tried to replace them by workspace dependencies but to no avail. If you do look into this, please do not waste too much time on this annoying problem.

Also, permission for maintainer to edit this PR should already be given.

Interestingly I still cannot push to this branch.