Open vchernin opened 3 years ago
There are other issues that I do not remember the name about this. Arch Linux package for Linux Studio Plugins is the one creating these launchers. I think that the Linux Studio Plugins author made some changes in the last release that allows package maintainers to disable these icons or to be able to put them in another package only for them. But for some reason Arch Linux does not seem to be making use of that.
I found in the latest upstream LSP release notes:
**=== 1.1.30 ===
* Implemented Oscilloscope plugin series: x1, x2 and x4. UX design by Boris Gotsulenko.
* Added data streaming port support to plugin framework.
* Added strobe feature to mesh primitives that allows to draw
multiple streamed meshes together.
* Implemented 4-lobe Lanczos oversampling DSP functions for i586 architecture.
* Implemented 4-lobe Lanczos oversampling DSP functions for x86_64 architecture.
* Implemented 4-lobe Lanczos oversampling DSP functions for 32-bit ARM architecture.
* Implemented 4-lobe Lanczos oversampling DSP functions for 64-bit ARM architecture.
* Minor bugfixes in the core library.
* Fixed bug with character set encoding for several systems with limited iconv.
* Fixed latency compensation issue that happened for the 'Bypass' switch/automation.
* Implemented additional 'Boosting' mode for the single-band compressor plugin series.
* Implemented additional 'Boosting' mode for the multiband-band compressor plugin series.
* Updated french translations (contributed by Olivier Humbert).
* Updated italian translations by Stefano Tronci.
* Desktop icon installation moved to a separate 'install_xdg' icon to prevent LSP
icon flooding for several systems which don't support XDG standard.**
In the last bullet point I'm not exactly sure what the XDG standard is meant to be here.
Looking at the PKGBUILD: https://github.com/archlinux/svntogit-community/blob/packages/lsp-plugins/trunk/PKGBUILD
package() {
depends+=('libsndfile.so')
cd "$pkgname-$pkgver"
make PREFIX='/usr' \
DESTDIR="$pkgdir/" \
install
make PREFIX='/usr' \
DESTDIR="$pkgdir/" \
install_xdg
}
It seems if we remove or change the last block it won't install the icons anymore. I'll try to test that momentarily. Perhaps we can see if the Arch package maintainer is willing to change the behaviour.
I managed to fix the lsp-plugins package by simply commenting out the install_xdg
part discussed in the release notes.
Side note: "upgrading" from the fixed build to the standard one results in a net upgrade size increase of 0.06 MiB.
If it makes sense I'll open an issue with the upstream lsp-plugins package. It's possible it's prefered to have those icons installed by default, so maybe a new lsp-plugins Arch package will be necessary.
I also found this tangentially related bug, which seems to apply to easyeffects still.
If it makes sense I'll open an issue with the upstream lsp-plugins package
Considering the tests you have mad I think it is better if you are the one opening an issue there. Maybe they just did not notice that there is a clean way to disable those icons.
I also found this tangentially related bug, which seems to apply to easyeffects still.
Technically it is optional. But as most users expect the equalizer to be working they may have decided it was better to force lsp installation.
Technically it is optional. But as most users expect the equalizer to be working they may have decided it was better to force lsp installation.
Yeah that makes sense to me. Lsp by default is what the Flatpak is supposed to do by default as well.
Considering the tests you have mad I think it is better if you are the one opening an issue there. Maybe they just did not notice that there is a clean way to disable those icons.
It does seem like they've specifically opted to enable the icons.
I opened a bug: https://bugs.archlinux.org/task/71749
It looks like we're not the first to report this: https://bugs.archlinux.org/task/71308 https://bugs.archlinux.org/task/64979
It seems another solution will be needed. Is it possible to maintain lsp-plugins from within the easyeffects package, or is it better to maintain a "lsp-plugins-no-icons"? Neither solution is ideal, but I don't really see another solution here.
Not having working equalizer out of the box is not ideal, and neither is having 100s of app icons.
Is it possible to maintain lsp-plugins from within the easyeffects package
I am not sure I understand. Do you mean making a distribution package containing both EasyEffects and LSP? I don't know if it is possible. Or do you mean including LSP source code in ours so they are compiled together? Although this would be possible it is something I would like to avoid considering that the only reason for doing that would be to disable these icons.
I am not sure I understand. Do you mean making a distribution package containing both EasyEffects and LSP? I don't know if it is possible.
I am not sure either. I am not an expert on how that would work.
Or do you mean including LSP source code in ours so they are compiled together? Although this would be possible it is something I would like to avoid considering that the only reason for doing that would be to disable these icons.
Yeah this wouldn't be ideal either.
I think the best course of action would be to make a new, maybe AUR lsp-plugins-no-icons
package. At least then people would have a fairly straightforward workaround.
If someone does want to do make a special AUR package:
lsp-plugins
packageAlthough now I realize if the name of the AUR package is different (eg lsp-plugins-no-icons
), easyeffects probably won't recognize it as a valid replacement for lsp-plugins
. You'd have to make an AUR lsp-plugins-no-icons
package as well as modify the easyeffects PKGBUILD.
I personally don't plan on submitting such a package as I'd rather work on the Flatpak. But if anyone wants to try this all the information you need should be here.
More upset reviews :(
Maybe I should just make an AUR lsp-plugins-no-icons
package... @wwmm could the stable EasyEffects depend on an AUR package? It doesn't really sound like it would work well to me, but I have no other good ideas...
Or maybe I could try to talk to the package maintainer directly... a PR to change the behaviour of the lsp-plugins
package might be more successful than opening bug reports that apparently don't get much attention or get marked not a bug. But I obviously don't want to spam or annoy them with requests they've made up their mind about.
@wwmm could the stable EasyEffects depend on an AUR package?
I do not maintain the Arch package. But I doubt this would work because the packages in the official repositories do not have AUR packages as dependencies. Only other packages also available in the official repository.
From where are these reviews? Flatpak users?
The reviews are visible in GNOME software (through OARS), as far as I know they must be Arch users since that's the only place I've seen this issue. I've never seen it with the Flatpak build (and I've built that a million times on my Fedora install).
The thing is the Arch package never shows up in GNOME software for me on Arch. I think that is some quirk with Arch as Fedora puts RPM apps in GNOME Software. I will try to investigate a bit more to confirm it's actually possible it could be Arch or maybe Manjaro users running into this.
EasyEffects' Arch package shows up in GNOME Software if you have gnome-software-packagekit-plugin
installed. I assume some distros like Manjaro may include that out of the box. This means Arch package users indeed could feasibly have been the ones writing those reviews (again, this makes sense since I have only noticed this with the Arch package).
Also if it wasn't clear before, these reviews are visible when viewing the Arch package or the Flatpak in GNOME Software. The different package formats should show the same reviews since AppStream recognizes them as the same app com.github.wwmm.easyeffects
even though they're packaged differently.
it is not fixed yet?
it is not fixed yet?
If there were news here, it would have been commented here (probably). I don’t use Arch so I have no idea.
it is not fixed yet?
For reasons I do not understand the Arch Linux package for Linux Studio Plugins
still installs all these launcher icons by default. There is nothing we can do our our side to avoid this. Some distributions are deciding to ignore a Linux Studio Plugins
build flag that allows the icons to not be installed.
It's not lsp only, but zam-plugins also. Not happening for calf instead.
lsp-plugins consists of standalone applications and plugins. The XDG desktop integration is for the standalone applications (not the plugins). The generated files have actually been merged upstream. The only reason they are not in the current release version, is that upstream intends to generate them in a different way from shared documentation in the future.
https://bugs.archlinux.org/task/64979
Whatever that means, I think Arch devs simply don't care about this issue. And if leaving plugin app icons would be an intended choice, it doesn't make sense they are missing for calf.
Anyway, there are two solutions:
.desktop
filesI have adapted the latest PKGBUILD for lsp-plugins in order to build a lsp-plugins-noicons package which replaces the lsp-plugins one. It provides "lsp-plugins" (and conflicts that package) to avoid breaking anything. I have uploaded it to AUR but I can not maintain it as I do not use it regularly. Maybe anyone here wants to take that task?
I have uploaded it to AUR but I can not maintain it as I do not use it regularly. Maybe anyone here wants to take that task?
Thank you for your work :-). Nowadays I do not maintain even the AUR package for EasyEffects. So someone else will have to adopt this one while the trusted Arch maintainers do not do something about the current mess it is the official package.
I am using it like this.
https://www.reddit.com/r/linux4noobs/comments/g40e3a/unwanted_lsp_plugins_showing_up/
I've been using this line in my /etc/pacman.conf
file to prevent extraction of lsp desktop entries:
NoExtract = usr/share/applications/in.lsp_plug.lsp_plugins_* usr/share/desktop-directories/lsp-plugins.directory
You could maybe also switch to easyeffects-git
(AUR) because that makes plugins optional installs.
https://github.com/sadko4u/lsp-plugins/releases/tag/1.2.5 Fixed the application menu spam in GNOME environment by reworking the XDG files
Maybe the just released LSP 1.2.5
will finally solve this.
Maybe the just released LSP
1.2.5
will finally solve this.
no it didnt
Installing the latest EasyEffects Arch package creates many likely unwanted plugin app icons. This does not occur with the experimental Flatpak build.
The rest of the pages are all the same thing, a continuation of plugin icons.
To reproduce:
sudo pacman -S easyeffects
Uninstalling by default does not fix this, you need to remove all the dependencies.
sudo pacman -Rcns easyeffects
Possible solutions:
Further info: It seems someone has already encountered this :( The only review currently for this app.
Originally I thought this was caused by the Flatpak build, but I have not once been able to reproduce it with the Flatpak. It's never occured to me on my Fedora installs (which is my primary machine). I've only seen it on Arch, which of course is the only place I will try the Arch package.
Only tested on GNOME, but most likely occurs elsewhere.