Runtime Error

[salehjg]

I have installed Melodic on my archlinux with yay. looks like gazebo, roscore and ... run seamlessly, but whenever I try to import cv_bridge in python (v3.7) I get this:
RuntimeError: FATAL: module compiled as little endian, but detected different endianness at runtime

I have not investigated the issue but a simple google search did not help.

[jwhendy]

I can confirm. That said, a simple google search did help immensely and I found not only the same sorts of issues, but a PR which cited why it was happening, and the fix required. That is now as a PR on cv_bridge.

If you'd like to fix this sooner, just edit cv_bridge/src/module.hpp and add the return statement.

@bionade24 how do you want to handle issues involving upstream, as well as waiting for the fix to get to us? For example:

• we could close this as it's going to be resolved
• we could leave this open, as we'll be affected until cv_bridge releases a version with this fix
• we could implement our own patch while we wait for cv_bridge to release, closing this
• we could create a -git version which gets the fix as soon as they merge vs. waiting for a release

[acxz]

So something similar happened during the QTLibs fiasco. What we did was ensure that upstream knew about the relevant issue and created one if they didn't. We then did a patch on our end, so that Arch users can still use the package. Once the fix gets incorporated into the latest release, we remove the patch.

[acxz]

Let's keep this issue open until our patch gets released into the AUR and upstream knows about the issue.

[salehjg]

@jwhendy No excuses :)
Adding the return statement and building again fixed the problem.
Thank you for your quick response, I appreciate it.

[jwhendy]

@acxz want to validate #2? Upstream already knows via my PR. I think we leave this open until upstream is released. That way this is a reminder that we can remove our patch once upstream releases the fix.

Otherwise there is no way I'll remember to keep checking!

[acxz]

Sure, I'll check later today.
Whenever we upgrade a package version on our end, we should check to see if the patch is needed anymore anyway. Therefore I don't think it is necessary to keep this issue open, because we should check for the issue anyway.

I'm not particularly opposed to doing so, but then I feel like we should keep an issue open for every package that is patched.

[jwhendy]

That works for me, though it assumes someone will manually do this. I used a script and would not necessarily be thinking about patches. That said, handling the order of sources in the PKGBUILD (like url vs. local file) was too complex for me, so those required manual intervention anyway.

That said, if we ever migrated to something more automated for updating based on upstream, we could miss this. Patching an already fixed file won't necessarily fail.

$ patch -uN src/module.hpp ../../../endian-fix.patch 
patching file src/module.hpp
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file src/module.hpp.rej

[acxz]

Just checked the patch works on my end.

I see, hmm okay then.

[bionade24]

Hi I'm back again. We always closed the issues after patching, and I created some -git packages because I haven't wanted this patching. I think the best way for the future is to label patched things and leave them open until a new upstream release with the patch included is available.