Public bug reported: Affecting Artful:
According to the publishing history, the package Simbody for Artful was directly copied from Zesty: https://launchpad.net/ubuntu/+source/simbody/3.5.4+dfsg- 1ubuntu1/+publishinghistory The problem is that a couple of dependencies of Simbody (libblas and liblapack) changed the location of their libraries to be arch dependent (from /usr/lib to /usr/lib/$arch-triplet/) and these paths are hardcoded by Simbody in the cmake module at building time. [Impact] * Any software using Simbody cmake module won't compile because of non existant lib paths in Simbody exported libraries. - See https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/23/consoleFull#-14256201906ea37b8d-a6d4-40ae-8431-d90c018842af * Rebuilding the package (binNMU) without any modifications to the source code would make cmake to get the new paths and hardcode them in the cmake module. [Test Case] * To check that there are non-existant paths in the current cmake module: - apt-get install libsimbody-dev - if [[ -f $(sed -n 's:.*\(/usr/.*libblas.so\).*:\1:p' /usr/lib/x86_64-linux-gnu/cmake/simbody/SimbodyConfig.cmake | uniq) ]]; then echo "fixed!"; else echo "Wrong path in cmake module"; fi * If you run the oneliner in any other release different than Artful it will return a success message. [Regression Potential] * There is no change in code or in Debian metadata, there is a change in the building environment. Changing the build environment from Zesty to Artful could produce some changes in the binary interface but given that it should be its 'native enviroment' I don't expect any incompatibility introduced by the change in the compiler of build flags/libraries. * The lack of changes in code should keep the API stable. * The lack of change in debian metadata should keep the packaging stable. * To minimize the possible problems in the binary interface or any other thing related to the change I created a PPA and rebuild the current version: - https://launchpad.net/~j-rivero/+archive/ubuntu/simbody-artful * I've used Gazebo simulator (which uses Simbody) large test suite for trying to detect possible problems. All seems fine and problems are not related to this bug: - https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/25/console * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * I'm currently the maintainer of Simbody in Debian ** Affects: simbody (Ubuntu) Importance: Undecided Status: New ** Tags: artful ** Description changed: Affecting Artful: - According to the publishing history, the package Simbody was directly copied from Zesty: - https://launchpad.net/ubuntu/+source/simbody/3.5.4+dfsg-1ubuntu1/+publishinghistory + According to the publishing history, the package Simbody for Artful was + directly copied from Zesty: + https://launchpad.net/ubuntu/+source/simbody/3.5.4+dfsg- + 1ubuntu1/+publishinghistory - The problem is that a couple of dependencies of Simbody (libblas and liblapack) changed the - location of their libraries to be arch dependent (from /usr/lib to /usr/lib/$arch-triplet/) - and these paths are hardcoded by Simbody in the cmake module at building time. + The problem is that a couple of dependencies of Simbody (libblas and + liblapack) changed the location of their libraries to be arch dependent + (from /usr/lib to /usr/lib/$arch-triplet/) and these paths are hardcoded + by Simbody in the cmake module at building time. [Impact] - * Any software using Simbody cmake module won't compile because of non existant lib - paths in Simbody exported libraries. - - See https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/23/consoleFull#-14256201906ea37b8d-a6d4-40ae-8431-d90c018842af + * Any software using Simbody cmake module won't compile because of non existant lib paths in Simbody exported libraries. + - See https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/23/consoleFull#-14256201906ea37b8d-a6d4-40ae-8431-d90c018842af - * Rebuilding the package (binNMU) without any modifications to the source code would make - cmake to get the new paths and hardcode them in the cmake module. + * Rebuilding the package (binNMU) without any modifications to the + source code would make cmake to get the new paths and hardcode them in + the cmake module. [Test Case] - * To check that there are non-existant paths in the current cmake + * To check that there are non-existant paths in the current cmake module: - - apt-get install libsimbody-dev - - if [[ -f $(sed -n 's:.*\(/usr/.*libblas.so\).*:\1:p' /usr/lib/x86_64-linux-gnu/cmake/simbody/SimbodyConfig.cmake | uniq) ]]; then echo "fixed!"; else echo "Wrong path in cmake module"; fi + - apt-get install libsimbody-dev + - if [[ -f $(sed -n 's:.*\(/usr/.*libblas.so\).*:\1:p' /usr/lib/x86_64-linux-gnu/cmake/simbody/SimbodyConfig.cmake | uniq) ]]; then echo "fixed!"; else echo "Wrong path in cmake module"; fi - * If you run the oneliner in any other release different than Artful it will return a - success message. + * If you run the oneliner in any other release different than Artful it + will return a success message. [Regression Potential] - * There is no change in code or in Debian metadata, there is a change in the building - environment. Changing the build environment from Zesty to Artful could produce some - changes in the binary interface but given that it should be its 'native enviroment' I - don't expect any incompatibility introduced by the change in the compiler of build - flags/libraries. + * There is no change in code or in Debian metadata, there is a change + in the building environment. Changing the build environment from Zesty + to Artful could produce some changes in the binary interface but given + that it should be its 'native enviroment' I don't expect any + incompatibility introduced by the change in the compiler of build + flags/libraries. - * The lack of changes in code should keep the API stable. + * The lack of changes in code should keep the API stable. - * The lack of change in debian metadata should keep the packaging stable. - - * To minimize the possible problems in the binary interface or any other thing related - to the change I created a PPA and rebuild the current version: - - https://launchpad.net/~j-rivero/+archive/ubuntu/simbody-artful + * The lack of change in debian metadata should keep the packaging + stable. - * I've used Gazebo simulator (which uses Simbody) large test suite for trying to - detect possible problems. All seems fine and problems are not related to this bug: - - https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/25/console + * To minimize the possible problems in the binary interface or any other thing related to the change I created a PPA and rebuild the current version: + - https://launchpad.net/~j-rivero/+archive/ubuntu/simbody-artful - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * I've used Gazebo simulator (which uses Simbody) large test suite for trying to detect possible problems. All seems fine and problems are not related to this bug: + - https://build.osrfoundation.org/job/gazebo-ci-default-artful-amd64-gpu-none/25/console + + * This both shows the SRU team that the risks have been considered, and + provides guidance to testers in regression-testing the SRU. [Other Info] - - * I'm currently the maintainer of Simbody in Debian + + * I'm currently the maintainer of Simbody in Debian -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1770678 Title: [SRU] Simbody package ships erroneous paths for blas/lapack in the cmake module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/simbody/+bug/1770678/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
