[darc/maestro++] LibGit2Sharp uses native binaries that don't have BuildID about arcade-services HOT 11 OPEN

Best approach IMO is adding a way to baseline this file, since it's not built by Microsoft. Maybe there's a way to automatically hook it up based on existing classification as external (?) but a simple baseline is MVP.

Simply ignoring the failure isn't good, because we could silently be ignoring something that makes our Microsoft-built Linux binaries/symbols unindexable.

from arcade-services.

I agree with @dagood that we shouldn't just ignore it. I don't know the tool enough to recommend an actual fix, but probably we have the tool do something similar as signing where we white list 3rd party known libraries so the tool know these are special.

from arcade-services.

If the project built .symbols.nupkg that doesn't include the native files we wouldn't run into this issue. The symbol publishing logic uses the symbols package the project produces and falls back to using the main package, if the symbols package is not found. The default fallback here does not work since it contains the native libraries.

from arcade-services.

I agree that creating a .symbols.nupkg without this 3rd party module would be the best way to handle this instead of a white list or ignoring this error (I especially don't want to ignore this kind of error).

from arcade-services.

Would make sense to patch arcade-services build to remove these files from the symbol packages? @mmitche @riarenas

from arcade-services.

Fine by me.

from arcade-services.

Symbol completeness checks should complain about it until there's a baseline/exception/classification, but if it works short-term it sounds fine.

from arcade-services.

Symbol completeness checks should complain about it until there's a baseline/exception/classification, but if it works short-term it sounds fine.

I'm not proposing to change symbol completeness check. My proposal is to "fix" the package by removing the file from the symbols package. I got the impression from @tmat comment that this file isn't even needed on the symbols package.

from arcade-services.

Yes, the proposal makes sense. I'm just pointing out that if symbol completeness checks work correctly, they will start to fail when this file is removed from the symbol package. The check will see that libgit2[...].so is in the package but the symbol package doesn't have a .so.dbg for it, and fail. The solution to that is exclusion based on classifying the file as external.

from arcade-services.

they will start to fail when this file is removed from the symbol package.

...On second thought, they should already be failing, because the .so.dbg doesn't exist. But it'll fail even more because the .so file doesn't exist either.

from arcade-services.

Doesn't feel like a priority for .NET 5. @JohnTortugo Feel free to tell me how I'm wrong.

from arcade-services.