help needed with portmidi
Hi, Portmidi gives rpmlint errors that include rpath warnings. I have read the documentation [1] on this test, but the only option I see is to disable this test or do something with chrpath. These seem like last resort solutions. Maybe someone who understands the code better can find a better solution to solve this? It can also use a more able maintainer than me. I've only kept it alive because of musescore, but lately it has seen some big updates again. Thanks, Cor [1] https://en.opensuse.org/openSUSE:Packaging_checks
Hi, I've made a quick patch by adding set(CMAKE_SKIP_BUILD_RPATH ON) in the CMakeLists.txt Build is passed: https://build.opensuse.org/package/show/home:kill_it:daw/portmidi do we need additional tests for working? On 2022-08-10 19:20, Cor Blom wrote:
Hi,
Portmidi gives rpmlint errors that include rpath warnings. I have read the documentation [1] on this test, but the only option I see is to disable this test or do something with chrpath. These seem like last resort solutions.
Maybe someone who understands the code better can find a better solution to solve this?
It can also use a more able maintainer than me. I've only kept it alive because of musescore, but lately it has seen some big updates again.
Thanks,
Cor
On Wednesday 2022-08-10 11:20, Cor Blom wrote:
Hi,
Portmidi gives rpmlint errors that include rpath warnings. I have read the documentation [1] on this test, but the only option I see is to disable this test or do something with chrpath. These seem like last resort solutions.
cmake and its questionable defaults :-/ -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON
Yes, but it doesn't work, for some of my packages at least. CMAKE_SKIP_BUILD_RPATH - does On 2022-08-10 19:45, Jan Engelhardt wrote:
On Wednesday 2022-08-10 11:20, Cor Blom wrote:
Hi,
Portmidi gives rpmlint errors that include rpath warnings. I have read the documentation [1] on this test, but the only option I see is to disable this test or do something with chrpath. These seem like last resort solutions.
cmake and its questionable defaults :-/
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON
On Wednesday 2022-08-10 11:47, Konstantin Voinov wrote:
Yes, but it doesn't work, for some of my packages at least. CMAKE_SKIP_BUILD_RPATH - does
cmake's questionable naming scheme :-/
cmake and its questionable defaults :-/
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON
Speaking of it, can't we just slap all of this into %cmake? I can't see the legitimacy of rpaths in FHS-conforming packages (and for instances where it's needed, it could just be enabled on a case-by-case basis)
On Mittwoch, 10. August 2022 11:56:46 CEST Jan Engelhardt wrote:
On Wednesday 2022-08-10 11:47, Konstantin Voinov wrote:
Yes, but it doesn't work, for some of my packages at least. CMAKE_SKIP_BUILD_RPATH - does
cmake's questionable naming scheme :-/
More pointless bashing ... BUILD_RPATH is set/used before installing. It is required so unit tests can be run in the build tree.
cmake and its questionable defaults :-/
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON
Speaking of it, can't we just slap all of this into %cmake?
It is there, but it is an inconsistent mess, being different in TW, Leap 15.3 and 15.4.
I can't see the legitimacy of rpaths in FHS-conforming packages (and for instances where it's needed, it could just be enabled on a case-by-case basis)
Citing from FHS 3.0:
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
So using RUNPATHs for the subdirectories is legitimate and required. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 8/10/22 19:26, Jan Engelhardt wrote:
On Wednesday 2022-08-10 11:47, Konstantin Voinov wrote:
Yes, but it doesn't work, for some of my packages at least. CMAKE_SKIP_BUILD_RPATH - does
cmake's questionable naming scheme :-/
cmake and its questionable defaults :-/
-DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON
Speaking of it, can't we just slap all of this into %cmake? I can't see the legitimacy of rpaths in FHS-conforming packages (and for instances where it's needed, it could just be enabled on a case-by-case basis)
It used to be and there was multiple requests for it to be changed and so it was. Some packages break with it some without, there are several bugreports that should be listed in the .changes file if past me was good. Personally in an ideal world I suspect that the macro should have -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON but not -DCMAKE_SKIP_RPATH:BOOL=ON as there are test suites and other parts of some package builds that use rpath's as part of the build and verification process. From memory darktable uses the install version for some of its plugins as well and there are probably some others. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 8/10/2022 3:20, Cor Blom wrote:
It can also use a more able maintainer than me. I've only kept it alive because of musescore, but lately it has seen some big updates again.
I'll give it a go if you want (jacraig). I don't know this specific code base but I do use musescore so I would be interested in keeping it going. -- Jason Craig
participants (6)
-
Cor Blom -
Jan Engelhardt -
Jason Craig -
Konstantin Voinov -
Simon Lees -
Stefan Brüns