-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building version 2.0.1 in CentOS 8 Stream #21
Comments
For CentOS 8 Stream I changed in
and that fixed all the provides. Building the same in CentOS 7.9 however gives
Per https://rpm.org/user_doc/boolean_dependencies.html
but in CentOS 7.9 for Meanwhile in CentOS 8 in the
failing with output
Also in CentOS 8
fails with
even though it built the rpm fine and the library files are present in Even when changing
then in CentOS 8
fails with
even though the library files are present in I hope this investigation might help someone who has better insights to add something to a fix that I have missed. |
As a workaround, have installed 2.0.1 in CentOS 8 Stream without RPM. Here are complete instructions. First some generic development tooling
Then some specific installs
Then
But, no luck with
Hence
Now it runs. It functions at least somewhat, but I am not ready to say the idle functionality works. The idle functionality possibly or probably doesn't work right in TimeIT 2.0.1 in CentOS 8 Stream, both in Wayland and X11; but that is another topic, for other issues, for upcoming versions. |
I have built latest on "master" and tested running it under xfce4 on CentOS 8 stream. Idle detection worked, and workspace auto tracking was partially working. Following issues were detected:
I will continue to investigate to see if it is Centos 8 problems or if it is regressions that I have caused by refactoring. We have two tickets covering:
I will update #22 narrowing the error picture. Closing. |
Where should I change source code to work around a library version mismatch?
Ultimately when doing
get
Here a descriptions how it got there, on a machine that generally already was set up for development:
Note that building in Release directory doesn't work, as a some paths are wrong one level that way. Hence, building it the old way directly in project directory.
On this system, there is a libgktmm:
gives
and
gives
and
give
Should I add new version numbers somewhere in source code, so they also will be accepted?
Where in source code I would put such new version numbers?
Or instead, should I symlink library files just on my machine?
I am asking due to lack of familiarity with this build process, dependencies, version matching mechanisms. If told where to look, I don't mind forking, taking care of all mismatches, and once it works submitting a PR.
The text was updated successfully, but these errors were encountered: