Description of the issue (screenshots if relevant):
1.Fagus Launcher
Won’t start without lib64ayatana-appindicator3-gir0.1.
Cannot remove game prefixes without canberra-gtk3.
Solution: sudo dnf in lib64ayatana-appindicator3-gir0.1 canberra-gtk3
2.Gear Lever
It doesn’t start and the problem couldn’t be solved
Traceback (most recent call last): File "/usr/bin/gearlever", line 43, in <module> from gearlever import main File "/usr/share/gearlever/gearlever/main.py", line 28, in <module> from .providers.providers_list import appimage_provider File "/usr/share/gearlever/gearlever/providers/providers_list.py", line 2, in <module> from .AppImageProvider import AppImageProvider File "/usr/share/gearlever/gearlever/providers/AppImageProvider.py", line 9, in <module> from desktop_entry_lib import DesktopEntry as JdDesktopEntry ModuleNotFoundError: No module named 'desktop_entry_lib'
3.KDE – Information Center → Graphics (EDID)
Shows message:
di-edid-decode tool required to display this page, but it cannot be found.
Solution: sudo dnf in libdisplay-info
4.Klassy and Oxygen-Qt5
Installation fails with dependency errors:
(Oxygen-Qt5 the same error)
Failed to resolve transaction: Problem: Package klassy-6.4.breeze6.4.0-1.x86_64 from rolling-x86_64 requires libKF5Style.so.5()(64bit), but no vendor provides it. - Package lib64KF5Style5-5.116.0-3.x86_64 from rolling-x86_64 requires frameworkintegration=5.116.0-3, but no vendor provides it. - Conflicting requests - Nothing provides libAppStreamQt5.so.3()(64bit) needed by frameworkintegration-5.116.0-3.x86_64 from rolling-x86_64. You can try adding to the command line:
Skip-broken to skip packages that can be uninstalled.
I also suggest removing oxygen-gtk3 and oxygen-gtk because they are broken theme , removing ocean-sounds because it is for kde plasma 5 and sound-theme-ocean for kde plasma6 version
Do you not know how to fix it for everyone, or do you just not want to? Either response is fine, but you will have to open issues in Github if you want us to use any of your advice. Even then, we may investigate that what you are calling “errors” are for a specific use case and our option may be to debloat packaging and let people install the components they need.
This forum is so everyone can help each other fix things. We encourage you to participate in that. Otherwise it doesn’t really make any sense to post here, at all. I’m going to move this to a more appropriate topic in Development > Packages and features requests .
You need to remove all the contents of the README. Not only do we not use them for our packages, it is misleading. This is your first post here, and you did not even answer if you would be contributing. There are no errors or plans affecting things in OpenMandriva related to your package. Your contribution doesn’t “fix" anything. The package was never added to our build system. Thus, it was never built.
When you fork a project to submit a PR, you should just create a new branch instead of renaming the repo. Like so:
git checkout -b update-faugus-launcher-spec
What follows -b is the label you are giving the branch. It is common to describe what the branch will offer to the project. Branching maintains the repo name but allows you to reference what changes you are making. You also don’t end up renaming something in the repo itself when you use this practice. It’s that branch you will attempt to submit as a PR to the upstream’s repo. This way, you don’t lose track of master between your fork and the upstream. You typically push that branch to your repo and GitHub will ask you if you want to submit a PR to the upstream repo.
There are some other problems with the spec that were not something you did, or would have known was an issue. They will need to be fixed along with your changes. There are a couple different ways we could work together to solve the issue. We can communicate here or in our Cooker chat on Matrix.org. Whichever you would prefer is fine with me. In the meantime, I would suggest you close the PR and delete your fork from GitHub. It will be good practice to learn how to do it properly, and you won’t lose your local changes if you cloned it to your computer. I have already written the fixed and refactored spec file and would be willing to go over it with you so you know what was wrong and why.
Thanks for the tips! I’ll close the PR and remove the fork from GitHub. I’d be happy to discuss the revised and refactored spec file with you to better understand what was wrong and how to correct it in the future. We can continue this conversation on Matrix.org.
