Discover doesn't work
Please confirm there isn't an open report for this issue
- [x] I have searched through bug reports
Summary
Discover doesn't launch when I click on it.
Steps to reproduce
Click on Discover icon
Expected result
Discover window open and ready to update, install and remove app.
Actual result
Nothing, and on the terminal:
plasma-discover
Warning: Setting a new default format with a different version or profile after the global shared context is created may cause issues with context sharing.
Environment
- [x] Is system up to date?
Repo
Polaris (stable)
Desktop Environment
Budgie
System details
OS: Solus 4.7 Endurance x86_64 Host: HVY-WXX9 (M1010) Kernel: Linux 6.16.12-323.current Uptime: 20 mins Packages: 1255 (eopkg), 17 (flatpak) Shell: bash 5.3.3 Display (BOE0878): 1920x1080 in 16",z DE: Budgie 10.9.4 WM: Mutter(Budgie) (X11) Terminal: GNOME Terminal 3.58.0 Terminal Font: Hack (9pt) CPU: AMD Ryzen 5 4600H (12) @ 3.00 Gz GPU: AMD Radeon Vega Series / Radeon] Memory: 3.90 GiB / 14.99 GiB (26%) Swap: 0 B / 8.00 GiB (0%) Disk (/): 290.16 GiB / 467.40 GiB (64
Other comments
No response
Same issue here.
I received a popup notification that updates were available. When I clicked on the Launch Discover shortcut, nothing happened. The Discover icon was still in the notification area. Double clicking or right clicking and selecting Launch Discover from the notification icon also did nothing.
I rebooted and manually ran eopkg update. After the update, Discover still will not launch and the notification icon was no longer in the notification area.
Launching plasma-discover from the terminal gives the same warning as OP and hangs. Eventually it does return and also prints the following error:
Warning: Setting a new default format with a different version or profile after the global shared context is created may cause issues with context sharing.
kf.dbusaddons: Failed to register name 'org.kde.discover' with DBUS - does this process have permission to use the name, and do no other processes own it already?
QThreadStorage: entry 2 destroyed before end of thread 0x55712cb7b250
QThreadStorage: entry 1 destroyed before end of thread 0x55712cb7b250
Output if inxi -b:
System:
Host: khopesh Kernel: 6.16.12-323.current arch: x86_64 bits: 64
Desktop: Budgie v: 10.9.4 Distro: Solus 4.7 endurance
Machine:
Type: Desktop System: Gigabyte product: X570 I AORUS PRO WIFI v: -CF
serial: <superuser required>
Mobo: Gigabyte model: X570 I AORUS PRO WIFI serial: <superuser required>
UEFI: American Megatrends LLC. v: F39d date: 09/02/2024
CPU:
Info: 8-core AMD Ryzen 7 5800X3D [MT MCP] speed (MHz): avg: 3585
min/max: 576/4553
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Navi 48 [Radeon RX 9070/9070
XT/9070 GRE] driver: amdgpu v: kernel
Device-2: Logitech HD Pro Webcam C920 driver: snd-usb-audio,uvcvideo
type: USB
Display: x11 server: X.Org v: 21.1.20 with: Xwayland v: 24.1.9 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi
gpu: amdgpu resolution: 1: N/A 2: 1920x1080~60Hz 3: 1920x1080~60Hz
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.2.6 renderer: AMD
Radeon RX 9070 XT (radeonsi gfx1201 ACO DRM 3.64 6.16.12-323.current)
Info: Tools: api: eglinfo, glxinfo, vulkaninfo gpu: corectrl,radeontop
x11: xdpyinfo, xprop, xrandr
Network:
Device-1: Intel I211 Gigabit Network driver: igb
Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi
Drives:
Local Storage: total: 4.55 TiB used: 1000.71 GiB (21.5%)
Info:
Memory: total: 64 GiB note: est. available: 62.71 GiB used: 4.49 GiB (7.2%)
Processes: 429 Uptime: 21m Shell: Bash inxi: 3.3.39
Same issue here with a fresh install of 4.7 KDE, updates and epoch done. I've run plasma-discover --backends packagekit,fwupd,kns,flatpak and Discover started but launching via the app icon hangs.
I have the same issue. System: Host: toshiba-port Kernel: 6.17.8-324.current arch: x86_64 bits: 64 Desktop: Budgie v: 10.9.4 Distro: Solus 4.8 opportunity Machine: Type: Laptop System: TOSHIBA product: PORTEGE R30-A v: PT343E-0SM05QEN
This is a known issue. See that Known Issues post for the workaround.
Unfortunately, this is something that needs to be fixed upstream.