Add lbr_fri_ros2_stack

[kenichi-maeda]

This PR keeps IDL fixed to 1.x (FRI 1.11, 1.14, 1.15, 1.16, and 1.17)

[Tobias-Fischer]

I don't think we need any of the lbr-fri-client-sdk pinnings, that should be taken care of in the lbr-fri-client-sdk feedstocks by properly defining the run_exports

[kenichi-maeda]

Thank you for pointing it out. I updated the yaml file.

[Tobias-Fischer]

With the mapping of fri_client_sdk to lbr-fri-client-sdk, we should be able to remove all the additional add_host and add_run, can't we?

[kenichi-maeda]

With the mapping of fri_client_sdk to lbr-fri-client-sdk, we should be able to remove all the additional add_host and add_run, can't we?

You're right. Those were redundant.

[kenichi-maeda]

Would it be possible to get some insight into why the build succeeds locally but fails on CI, specifically on Linux-64?

[traversaro]

Would it be possible to get some insight into why the build succeeds locally but fails on CI, specifically on Linux-64?

The generated recipes are the same? Probably locally you already have a ros-humble-lbr-fri-idl package in the cache, so you do not get:

│ candidates were found for ros-humble-lbr-fri-idl *.

Can you try with a clean cache?

[kenichi-maeda]

Would it be possible to get some insight into why the build succeeds locally but fails on CI, specifically on Linux-64?

The generated recipes are the same? Probably locally you already have a ros-humble-lbr-fri-idl package in the cache, so you do not get:

│ candidates were found for ros-humble-lbr-fri-idl *.

Can you try with a clean cache?

Would it be possible to get some insight into why the build succeeds locally but fails on CI, specifically on Linux-64?

The generated recipes are the same? Probably locally you already have a ros-humble-lbr-fri-idl package in the cache, so you do not get:

│ candidates were found for ros-humble-lbr-fri-idl *.

Can you try with a clean cache?

I removed all previous artifacts (folders like output, .pixi, recipes) as well as the .cache, then tested on two Linux-64 macines. One build completed successfully, while the other failed with the same error seen in CI.

By the way, pixi run build succeeded on the failing machine after adding "https://conda.anaconda.org/conda-forge" to the channels section of pixit.toml, although I would have expected "https://repo.prefix.dev/conda-forge" alone to be sufficient.

If this is a build-order issue, what would be a potential fix?

@traversaro I haven't figured out how to resolve it yet. If you could share your thoughts when you have a chance, I'd appreciate it!

[traversaro]

Sorry for the late response, I will try locally.

[kenichi-maeda]

Sorry for the late response, I will try locally.

Thank you! If anything comes up, let me know and I will check on my end too.