Closed ran-dall closed 2 years ago
@vifino I also think that default
(in src_prepare
) should be executed after the modifications are done to the .desktop
file. I didn't address it in this PR, but you might want to change it or I can submit another PR if we're in agreement.
Also, I didn't modify any of the other OpenRazer ebuilds.
I also made a PR to upstream, as the problem comes from upstream...however, I don't know how fast they'll be to merge it; but once it's merged, the PR won't be needed.
Hey @ran-dall , this generally looks good to me! I think it'd be nice to have the user patches apply after the category patch. I'd love to get a quick commit from you that switches the order in this PR, I can merge that in one go then. :)
@vifino Sorry for it taking me a minute to update.
Should I also update openrazer-9999.ebuild
and maybe the previous .ebuilds
as well for OpenRazer?
@vifino Sorry for it taking me a minute to update. Hey, don't worry about that at all! :)
Should I also update
openrazer-9999.ebuild
and maybe the previous.ebuilds
as well for OpenRazer?
Updating the 9999
one sounds good to me, but I don't think it's necessary to update the old ones.
Thank you!
@vifino That should do it! 😁
And so it was merged! Thanks again! :)
@vifino Hey man, if you don't mind, please take a look at my comment (https://github.com/openrazer/openrazer/pull/1781#issuecomment-1093138574). I think that perhaps we can benefit from a bit of clarification for OpenRC users that they need to move the .desktop
file into /etc/xdg/autostart
. Thoughts?
Currently, once the ebuild has emerged, the installation will put the application in 'Lost & Found' (while using KDE) due to the fact that the .desktop doesn't have a specified category. This commit fixes the .desktop file and addresses the symptom.