You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It can happen, that there are problematic packages installed on the target system when building the bridge from source. See #88 and #329 as an example. In fact we have proprietary msg packages on one of our robots that we cannot change that seem to export non-existing library targets. Though this is clearly an issue from the upstream package as mentioned in #88 (comment) we needed a workaround for this.
Implementation considerations
I've created a workaround in 744bb9c that allows providing a package blacklist. That works for us right now, but probably is not in a state that should be merged, if desired at all. I just wanted to leave this here as a comment / possible extension.
The text was updated successfully, but these errors were encountered:
Feature request
Feature description
It can happen, that there are problematic packages installed on the target system when building the bridge from source. See #88 and #329 as an example. In fact we have proprietary msg packages on one of our robots that we cannot change that seem to export non-existing library targets. Though this is clearly an issue from the upstream package as mentioned in #88 (comment) we needed a workaround for this.
Implementation considerations
I've created a workaround in 744bb9c that allows providing a package blacklist. That works for us right now, but probably is not in a state that should be merged, if desired at all. I just wanted to leave this here as a comment / possible extension.
The text was updated successfully, but these errors were encountered: