We believe that the bug you reported is fixed in the latest version of
plasma-discover, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1145932@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurélien COUDERC <coucouf@debian.org> (supplier of updated plasma-discover package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 28 Aug 2026 22:28:09 +0200
Source: plasma-discover
Architecture: source
Version: 6.7.4-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Aurélien COUDERC <coucouf@debian.org>
Closes: 1145932
Changes:
 plasma-discover (6.7.4-2) unstable; urgency=medium
 .
   [ Aurélien COUDERC ]
   * Backport upstream commit: SnapBackend: signal completion of update
     check with zero upgradeable snaps. [3a6080ae] (Closes: #1145932)
Checksums-Sha1:
 0272bec03baec2a1374ba887828183ed231eb2ff 4000 plasma-discover_6.7.4-2.dsc
 6f7083b64d067a08b0024a39ee469fdc8fa1471d 25692 plasma-discover_6.7.4-2.debian.tar.xz
 d888082f44c34249301eaa7e132e27d2d4568ea5 35570 plasma-discover_6.7.4-2_amd64.buildinfo
Checksums-Sha256:
 e8f2e95da17a71df8282d5b2bbc8c959a1965795353674338c199757d5b86cc0 4000 plasma-discover_6.7.4-2.dsc
 b5084676babaf6a89d1e9b9a2866817dc0f62c4c74129587d3db6c16b7cc5871 25692 plasma-discover_6.7.4-2.debian.tar.xz
 9a9701354504779269fb8c8709827a61351eef3ba0fd6b82d911c289da0408f9 35570 plasma-discover_6.7.4-2_amd64.buildinfo
Files:
 92668fd6f20373e29a281c10bedaa9ff 4000 kde optional plasma-discover_6.7.4-2.dsc
 2113b4373bbca683203d7cc6e9e8c666 25692 kde optional plasma-discover_6.7.4-2.debian.tar.xz
 a6ba26ad83b0e8581cb976a527972eb4 35570 kde optional plasma-discover_6.7.4-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEEIW//QAAaDgcOKDsfcaflM/KRoyQFAmqR7+4THGNvdWNvdWZA
ZGViaWFuLm9yZwAKCRBxp+Uz8pGjJFM8D/49KK632GqN7uB1db83SCK51yZfNHcM
brwL61rb8oTvyh3KY+vB+i2sLbzWZFRgypI4xiOWuJY8MdP7leoEvEzlWm01SQwS
Xm2ekLaljQWx3ImQWgMhCuQM+gl4ayu9ABUvjwHKhTjm9YXM8Cz2unuD1OdeQ0cX
htpC1EUyn+7HxfgffZ0cMNgRm5wvyWKXamD0qqOQwFkAbbRZTBSlLiSYsMNL53I9
yBRVXjMzfbsjljNRrPTsaL2xXhAjEv0HiG2B6Ui/tHjE8Xi2QDbryuJqWtOXHPq2
9bhAKDLJOeAVJ1l6FvhhlpD6BSv/vjMJnKxQOxi/5jANA7vYA/Aw3p0gohiH2wmQ
YqZOcRpq4cM4O4sP8hya6q6L7uWBiE8I+vZ0fsIAF5o3FGbNKIwHiNwXIY7KPQoY
RTWHTHhbbK2a2DQ6S8zenpBAXQaRFLZV21XekMWHPQGJMLEakb3cqAfNFgVKMnhg
iHSWrZExj2KN02pjAui8yOrbwwgk14PwGcHyYUW0Su9rfD3LeNKqjEjQF67mZkVi
kBrymZQSvcec7u/5c0S1tUzfQoufbfrT5rtIf4I5zsgeEmPATMRyLSmWDKRj8ULF
g6wrQwgjB8roh+R9IyyIHOqxrh60Ci+6gYxxy/nQZk9T9VrTT/l02P25k8by+Dws
CY+2Tkzx+tKr4Q==
=vHz1
-----END PGP SIGNATURE-----

Hello Theodor-Bogdan
Hello Aurélien

I tested the new version 6.7.4-2 and Discover still freezes.

In the original bugreport, there is a bug in the PackageKit backend.
Possibly, the PackageKit backend is still broken.

There is a bug in the Snap backend fixed.

If i start Discover with:
$ plasma-discover               --> freeze
$ plasma-discover --mode Update --> works

I don't know, what to do now.
Re-Open this bugreport?

Best regards and thank you for your support
Bernhard

Hello all,

In my initial bug report, the tracked issue was specifically for the
packagekit back-end, perhaps things got mixed up in the mean time with
another issue for the snap back-end; I can confirm the issue is definitely
not fixed on my side – I've installed 6.7.4-2, when launching
plasma-discover with the packagekit backend, it still freezes, all other
back-ends work (well, the ones I have installed, I don't use snap, so
unfortunately I could not test this).
I believe the issue should be reopened, since the correction listed in
6.7.4-2 do not target packagekit.

To sumarise (what I did on my machine):

Works:
plasma-discover --backends flatpak-backend,fwupd-backend,kns-backend
Works, freezes when changing to package browsing tabs:
plasma-discover --mode Update --backends packagekit
Freezes on start-up (because it launches directly on Home, which is one of
the package browsable tabs):
plasma-discover --backends packagekit
If you need me to open a different bug for 6.4.7-2, or need any other
information, please tell me.
Thank you for your support!

Best,
ThB

Control: reopen -1
Control: reassign -1 src:kf6-kimageformats

Hello,

I would like to add isolation data to this bug, which I believe was closed
in error.

The upload that closed it, plasma-discover 6.7.4-2, backports an upstream
commit for SnapBackend ("signal completion of update check with zero
upgradeable snaps"). That commit does not touch the PackageKit code path
described in the original report, so it cannot address the reported
symptom. Two people have already replied in this log stating the freeze
persists with 6.7.4-2.

I still have 6.7.4-1 installed, so I cannot personally confirm the
behaviour of -2; my data below is from -1. What I can contribute is a
reproducible isolation of the actual failing component.

ISOLATION (three steps, reversible)

1. Moving /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/kimg_jxl.so
   out of the plugin directory: Discover starts and renders the Home page
   normally.
   (Renaming it in place is not sufficient - Qt's plugin loader reads the
   internal metadata regardless of file extension and loads it anyway.)

2. Restoring the plugin: Discover freezes again on Home, window title
   shows "(no responde)".

3. With the plugin restored and only one icon file removed from the
   AppStream catalogue, Discover starts and renders Home normally. That
   file is:

     /var/lib/swcatalog/icons/debian-forky-main/64x64/scite_Sci48M.jxl

EVIDENCE DURING THE FREEZE

strace shows the file being opened immediately before the hang, and the
file descriptor remains open while the process is unresponsive:

  ls -l /proc/<pid>/fd | grep -i jxl
  lr-x------ 1 ... 75 ->
/var/lib/swcatalog/icons/debian-forky-main/64x64/scite_Sci48M.jxl

The main thread sits at 99% CPU in user space for as long as the window is
frozen, with State: R, wchan 0 and an empty /proc/<pid>/stack - i.e. a
loop inside userspace code, not a blocked syscall and not a deadlock on a
backend.

I am attaching the triggering file (scite_Sci48M.jxl, 7656 bytes, reported
by file(1) as a valid JPEG XL codestream).

RELATION TO THE UPSTREAM BUG

This looks like the same component as KDE bug 524885 (frameworks-
kimageformats), "kimg_jxl.so crashes (SIGABRT) when decoding certain JXL
images via QIcon::actualSize / QImageReader::jumpToNextImage":

https://bugs.kde.org/show_bug.cgi?id=524885

One difference worth recording: upstream describes a SIGABRT, whereas both
the original report here and my system show a hang rather than a crash.
Same call path, different outcome, presumably depending on the particular
JXL file. The trigger also differs per system - abe_abe.jxl upstream,
video-downloader in the original report here, scite_Sci48M.jxl on mine -
which argues against a single corrupted file and for a systematic problem
with how libjxl 0.11.2 handles a class of these images.

In that upstream bug, Albert Astals Cid reports it working with
kimageformats 6.29.0 and libjxl 0.12.0. As far as I can tell, libjxl 0.12
is not packaged in Debian in any suite (src:jpeg-xl is at 0.11.2-5 in
unstable), so there is currently no upgrade path for users on testing.

VERSIONS

  plasma-discover         6.7.4-1
  kimageformat6-plugins   6.28.1-1+b1
  libjxl0.11              0.11.2-5.1
  appstream               1.1.6-1
  Qt                      6.10.2
  Architecture            amd64

Disclosure: I run Soplos Linux, a derivative of Debian testing (forky).
The packages involved here are unmodified Debian packages from
deb.debian.org forky/main, with no local patches, diversions or pinning
applied to plasma-discover, kimageformat6-plugins, libjxl or appstream.

Given the above I would suggest this belongs to src:kf6-kimageformats or
src:jpeg-xl rather than src:plasma-discover; I have set a reassign control
command to the former, please redirect it if you judge otherwise.

Happy to run any further tests on request.

Regards,
Sergi Perich
Soplos Linux

Hello,

Follow-up with further data narrowing this down. Short version: libjxl
decodes the affected files correctly, so the fault appears to be specific
to the icon-engine path in kimageformats rather than to JPEG XL decoding
as such.

SECOND TRIGGER FILE

After removing the first trigger, Discover loaded Home but froze again on
the Installed view, on a different file:

  /var/lib/swcatalog/icons/debian-forky-main/64x64/clamtk_clamtk.jxl

Same signature as before: the file descriptor stays open while the process
is unresponsive at 99% CPU.

  ls -l /proc/22121/fd | grep -i jxl
  lr-x------ 1 ... 13 ->
/var/lib/swcatalog/icons/debian-forky-main/64x64/clamtk_clamtk.jxl

So there are at least four independent trigger files across three systems:
abe_abe.jxl (KDE 524885), video-downloader (this bug, original report),
scite_Sci48M.jxl and clamtk_clamtk.jxl (here). They come from unrelated
packages.

LIBJXL DECODES THEM FINE

djxl from libjxl-tools 0.11.2-5.1, i.e. the same libjxl the plugin links
against, decodes both of my trigger files without any problem:

  for f in scite_Sci48M.jxl clamtk_clamtk.jxl ark_ark.jxl; do
      timeout 10 djxl "$f" /tmp/out.png >/dev/null 2>&1; echo "$? $f"
  done
  0  scite_Sci48M.jxl     (freezes Discover)
  0  clamtk_clamtk.jxl    (freezes Discover)
  0  ark_ark.jxl          (renders fine in Discover)

Exit code 0 in all three cases - no hang, no error. jxlinfo also reads all
of them without issue.

Gwenview opens clamtk_clamtk.jxl and displays it correctly as well.

HEADERS ARE IDENTICAL BETWEEN WORKING AND FAILING FILES

jxlinfo output is byte-for-byte the same description for both the files
that freeze Discover and the ones that render fine:

  JPEG XL image, 64x64, (possibly) lossless, 8-bit RGB+Alpha
  Color space: RGB, D65, sRGB primaries, sRGB transfer function,
  rendering intent: Relative

So dimensions, bit depth, alpha and colour profile do not distinguish the
failing files from the working ones. I also checked whether the trigger
files were ones missing some of the 48x48/64x64/128x128 variants in the
catalogue; several hundred icons are incomplete in that way and most of
them render fine, and video-downloader (the trigger in the original
report) has all three sizes, so that is not the discriminator either.

WHAT THIS POINTS AT

Given that libjxl decodes these files correctly on its own, and Gwenview
displays them correctly, but Discover hangs on them via

  kimg_jxl.so
  QImageReader::size()
  QPixmapIconEngine::bestMatch()
  QPixmapIconEngine::actualSize()
  QIcon::actualSize()
  libKirigamiPrimitives

the problem looks specific to how the plugin behaves when driven from the
icon engine path (size query / bestMatch iteration), not to JXL decoding
in general. That is consistent with the reassignment to
src:kf6-kimageformats rather than src:jpeg-xl.

I am attaching the second trigger file (clamtk_clamtk.jxl, 5061 bytes).
The first one (scite_Sci48M.jxl) is attached to my previous message.

Versions unchanged from my previous message: kimageformat6-plugins
6.28.1-1+b1, libjxl0.11 0.11.2-5.1, Qt 6.10.2, amd64.

Happy to run anything else that would help.

Regards,
Sergi Perich
Soplos Linux