Closed traversaro closed 6 months ago
Diff working/non working:
--- <unnamed>
+++ <unnamed>
@@ -58,7 +58,7 @@
font-ttf-dejavu-sans-mono 2.37 hab24e00_0 conda-forge
font-ttf-inconsolata 3.000 h77eed37_0 conda-forge
font-ttf-source-code-pro 2.038 h77eed37_0 conda-forge
- font-ttf-ubuntu 0.83 h77eed37_1 conda-forge
+ font-ttf-ubuntu 0.83 h77eed37_2 conda-forge
fontconfig 2.14.2 h14ed4e7_0 conda-forge
fonts-conda-ecosystem 1 0 conda-forge
fonts-conda-forge 1 0 conda-forge
@@ -123,7 +123,7 @@
libcblas 3.9.0 22_linux64_openblas conda-forge
libccd-double 2.1 h59595ed_3 conda-forge
libclang-cpp15 15.0.7 default_h127d8a8_5 conda-forge
- libclang13 18.1.3 default_h5d6823c_0 conda-forge
+ libclang13 18.1.4 default_h5d6823c_0 conda-forge
libcrc32c 1.1.2 h9c3ff4c_0 conda-forge
libcups 2.3.3 h4637d8d_4 conda-forge
libcurl 8.7.1 hca28451_0 conda-forge
@@ -204,7 +204,7 @@
libre2-11 2023.09.01 h5a48ba9_2 conda-forge
librttopo 1.1.0 h8917695_15 conda-forge
libsanitizer 12.3.0 h2af2641_6 conda-forge
- libsdformat14 14.0.0 h2d4a2c5_2 conda-forge
+ libsdformat14 14.2.0 h2d4a2c5_0 conda-forge
libselinux-cos6-x86_64 2.0.94 h9b0a68f_1105 conda-forge
libsepol-cos6-x86_64 2.0.41 h9b0a68f_1105 conda-forge
libsndfile 1.2.2 hc60ed4a_1 conda-forge
@@ -264,7 +264,7 @@
openexr 3.2.2 haf962dd_1 conda-forge
openh264 2.4.1 h59595ed_0 conda-forge
openjpeg 2.5.2 h488ebb8_0 conda-forge
- openssl 3.2.1 hd590300_1 conda-forge
+ openssl 3.3.0 hd590300_0 conda-forge
p11-kit 0.24.1 hc5aa10d_0 conda-forge
pcre2 10.43 hcad00b1_0 conda-forge
pip 24.0 pyhd8ed1ab_0 conda-forge
@@ -345,7 +345,7 @@
yarp 3.9.0 ha770c72_2 conda-forge
yarp-python 3.9.0 py312hebe80a8_2 conda-forge
ycm-cmake-modules 0.16.2 h59595ed_0 conda-forge
- zeromq 4.3.5 h59595ed_1 conda-forge
+ zeromq 4.3.5 h59595ed_2 conda-forge
zlib 1.2.13 hd590300_5 conda-forge
zstd 1.5.5 hfc55251_0 conda-forge
zziplib 0.13.69 h27826a3_1 conda-forge
Could this be a sdformat 14.2.0 regression?
Thanks @traversaro for pointing this out! Yes it could be, I've checked that libsdformat14
14.2.0 has been released on conda on April 30th:
I will try to perform additional tests, to verify this is the cause that is making the tests fail. If this is the case, we could pin the dependency to the 14.0.0.
I tried to reproduce the errors of the CI on a local conda environment with the same dependencies (among them libsdformat14
v14.2.0) but I wasn't able to reproduce them.
The error message appearing in all failing tests [Err] [Server.cc:198] Error Code 40: Msg: Error parsing XML in file [/home/runner/micromamba/envs/gzyarppluginsdev/share/
comes from the parser.cc
file of the sdformat library: https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L844-L851
The error message [Err] [Server.cc:198] Error Code 1: Msg: File [] doesn't exist.
is from https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L837-L842
it seems there's something wrong about the filename
argument in the readFileInternal
method: https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L819C1-L821C2
The error message appearing in all failing tests
[Err] [Server.cc:198] Error Code 40: Msg: Error parsing XML in file [/home/runner/micromamba/envs/gzyarppluginsdev/share/
comes from theparser.cc
file of the sdformat library: https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L844-L851The error message
[Err] [Server.cc:198] Error Code 1: Msg: File [] doesn't exist.
is from https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L837-L842it seems there's something wrong about the
filename
argument in thereadFileInternal
method: https://github.com/gazebosim/sdformat/blob/6f1c36502f1085836ab9876e26afac3238f26820/src/parser.cc#L819C1-L821C2
My guess is that something changed in how the relative path are interpreted. However, I do not think there is any promise that that works in the public API, so probably we can just try to pass absolute path instead of relative paths in the tests (that anyhow it may be less confusing) and see if the problem is solved.
My guess is that something changed in how the relative path are interpreted. However, I do not think there is any promise that that works in the public API, so probably we can just try to pass absolute path instead of relative paths in the tests (that anyhow it may be less confusing) and see if the problem is solved.
Do you mean to define absolute paths via some definitions created through target_compile_definitions
?
My guess is that something changed in how the relative path are interpreted. However, I do not think there is any promise that that works in the public API, so probably we can just try to pass absolute path instead of relative paths in the tests (that anyhow it may be less confusing) and see if the problem is solved.
Do you mean to define absolute paths via some definitions created through
target_compile_definitions
?
Exactly!
Last successful job: https://github.com/robotology/gz-sim-yarp-plugins/actions/runs/8888246557 First failing job: https://github.com/robotology/gz-sim-yarp-plugins/actions/runs/8904385505