[dolphin] [Bug 469271] Double click on folder from desktop opens not only that folder but also random unrelated ones
https://bugs.kde.org/show_bug.cgi?id=469271 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #4 from Jonathan Wakely --- > Especially when I already have another window open. The concept of "last > time" is not even well defined in this situation. Yeah I think this is the problem. I have a dolphin window that I keep open permanently, with two tabs to a bunch of PDFs that I consult every day (docs like the C and C++ standards). So I definitely want that window to be restored when I start dolphin. But if I open a second dolphin window, or a third one, or some other application runs "xdg-open /some/path", or I mount a USB drive via the systray applet, I don't want a new window with all the same tabs in it *again*. I have Firefox set to restore my tabs and windows from last time as well, but if I press Ctrl-N to open a new window it doesn't reopen all those tabs *again*. They're still there in the original window, I don't need them reopened! If I change dolphin's setting to show $HOME (or some other dir) on startup, then launching a new dolphin window to open a specific dir (e.g. with xdg-open) or mounting a removable drive doesn't open with $HOME in a second tab, it *only* opens the location it was told to open. Why doesn't the "show on startup" setting take effect here too? To be clear, I don't think it should take effect, because that would be silly. But that's exactly what it does when "show on startup" is set to restore the previous state. I think the sensible behaviour would be to ignore that setting when dolphin is launched to show a specific dir (like when clicking on a folder on the desktop, or mounting a removable drive, or some other app uses xdg-open). Just show the dir it's been asked to show. If dolphin is launched with no arguments, e.g. from the start menu or the command line, then the "show on startup" would be relevant. That is the action "start dolphin", and not "show dir X in a file manager, which happens to be dolphin". They are two very different use cases. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472346] False positive mismatched frees
https://bugs.kde.org/show_bug.cgi?id=472346 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403563] Memory leak in plasma desktop (plasmashell)
https://bugs.kde.org/show_bug.cgi?id=403563 --- Comment #20 from Jonathan Wakely --- PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 22860 jwakely 20 0 2048664 399404 187656 S 96.3 0.6 0:32.10 QSGRenderThread 3222 jwakely 20 0 2048664 399404 187656 S 0.3 0.6 0:07.03 plasmashell 3238 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.17 QDBusConnection 3239 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.51 QXcbEventQueue 3352 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.31 QQmlThread 3363 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.31 Qt bearer threa 3508 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:01.50 QQuickPixmapRea 3577 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.00 CPMMListener 3588 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.07 plasmashell 3728 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.00 KCupsConnection 4218 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.65 QSGRenderThread 8537 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.34 QSGRenderThread 21405 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.05 QSGRenderThread 21413 jwakely 20 0 2048664 399404 187656 S 0.0 0.6 0:00.38 QSGRenderThread That thread is running code from the nvidia drivers, so maybe that's where the problem is: Thread 14 (Thread 0x7fdd7d5ba6c0 (LWP 22860) "QSGRenderThread"): #0 0x7fddcc52221f in __GI___poll (fds=0x7fdd7d5b95b8, nfds=1, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fddb2912a50 in () at /lib64/libnvidia-glcore.so.530.41.03 #2 0x7fddb29c3e51 in () at /lib64/libnvidia-glcore.so.530.41.03 #3 0x7fddb9aefe1c in () at /lib64/libGLX_nvidia.so.0 #4 0x7fddb9abfe30 in () at /lib64/libGLX_nvidia.so.0 #5 0x7fddc874fe21 in QGLXContext::swapBuffers(QPlatformSurface*) (this=0x7fdd582c79d0, surface=0x55b4cb438680) at qglxintegration.cpp:637 #6 0x7fddcea479db in QSGRenderThread::syncAndRender(QImage*) (this=this@entry=0x55b4cd1bc1c0, grabImage=grabImage@entry=0x0) at scenegraph/qsgthreadedrenderloop.cpp:869 #7 0x7fddcea480eb in QSGRenderThread::run() (this=0x55b4cd1bc1c0) at scenegraph/qsgthreadedrenderloop.cpp:1042 #8 0x7fddccae855b in operator() (__closure=) at thread/qthread_unix.cpp:350 #9 (anonymous namespace)::terminate_on_exception > (t=) at thread/qthread_unix.cpp:287 #10 QThreadPrivate::start(void*) (arg=0x55b4cd1bc1c0) at thread/qthread_unix.cpp:310 #11 0x7fddcc4ae12d in start_thread (arg=) at pthread_create.c:442 #12 0x7fddcc52fbc0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403563] Memory leak in plasma desktop (plasmashell)
https://bugs.kde.org/show_bug.cgi?id=403563 --- Comment #19 from Jonathan Wakely --- > I'll try software rendering tomorrow. That didn't make any difference. The last time I had the problem the plasmashell process grew to 78gb in about 20 minutes. But I've noticed that when I turn off my display and watch plasmashell using `top` in an ssh session on another machine, it spikes to 100% CPU usage every 15-20 seconds. When the display is on, that doesn't happen, it stays at about 0% all the time. This observation seems correlated to the fact that the memory leaks happen when I'm away from the machine and it's idle, because I always turn the screen off when I leave the desk. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403563] Memory leak in plasma desktop (plasmashell)
https://bugs.kde.org/show_bug.cgi?id=403563 --- Comment #18 from Jonathan Wakely --- Well that didn't help: top - 00:29:30 up 8:52, 6 users, load average: 3.24, 2.35, 2.20 Tasks: 412 total, 2 running, 410 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.9 us, 7.7 sy, 0.0 ni, 26.6 id, 63.3 wa, 0.3 hi, 0.3 si, 0.0 st MiB Mem : 64229.3 total,380.3 free, 63408.5 used,440.5 buff/cache MiB Swap: 69618.0 total, 22149.9 free, 47468.1 used.141.8 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 76 root 20 0 0 0 0 R 38.5 0.0 22:44.61 kswapd0 114347 root 20 0 25.4g 39608 25700 S 7.6 0.1 1:32.63 Xorg 114631 jwakely 20 0 1515740 20804 15968 S 2.7 0.0 0:04.83 kded5 3092 jwakely9 -11 473512 12616 8144 S 2.3 0.0 0:02.24 wireplumber 114634 jwakely 20 0 1323284 53276 44564 D 2.3 0.1 1:02.43 kwin_x11 115789 jwakely 20 0 3071832 86556 30860 S 2.0 0.1 3:54.37 Isolated Web Co 115756 jwakely 20 0 3063488 87384 30896 S 1.7 0.1 3:52.92 Isolated Web Co 118895 jwakely 20 0 100.4g 54.9g 33756 D 1.7 87.5 30:56.40 plasmashell It's about 4 hours since I restarted plasmashell (then left the system idle), and it's reached 100gb and the system is performing badly due to swapping. I'll try software rendering tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 403563] Memory leak in plasma desktop (plasmashell)
https://bugs.kde.org/show_bug.cgi?id=403563 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #17 from Jonathan Wakely --- Created attachment 159213 --> https://bugs.kde.org/attachment.cgi?id=159213=edit Settings an KWin support info For the past few weeks plasmashell (version plasma-workspace-x11-5.27.4.1-1.fc37.x86_64 from fedora RPMs) has been growing to tens of gigabytes while idle and getting killed by the oomkiller. I've attached my ~/config/plasma*rc and the kwin support info as requested above. I've tried setting the Render loop to basic and will see if that changes anything. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466671] Discover is very slow to fetch updates
https://bugs.kde.org/show_bug.cgi?id=466671 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > SUMMARY > > When opening discover from the systray widget when it shows updates are > available, it takes 30+ seconds to show the available updates. The previous > cause of slowness was supposed to have been fixed (Bug 457408) but I see no > improvement in the default use case of "click on the systray widget when it > shows updates". Maybe something got fixed in the KNewStuff backend, but > there's another cause of slowness, and it has the same symptom: the > "Fetching updates..." progress bar goes to about 97% immediately, then stops > for 30 seconds. > > The same slowness happens when clicking the "Refresh" button. > > > STEPS TO REPRODUCE > 1. plasma-discover --mode Update > 2. click Refresh > 3. waaaiit > > OBSERVED RESULT > > Slow > > EXPECTED RESULT > > More fastish! > > SOFTWARE/OS VERSIONS > Operating System: Fedora Linux 37 > KDE Plasma Version: 5.27.1 > KDE Frameworks Version: 5.103.0 > Qt Version: 5.15.8 > Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit) > Graphics Platform: X11 > Processors: 12 × Intel® Core™ i7-9850H CPU @ 2.60GHz > Memory: 31.1 GiB of RAM > Graphics Processor: Mesa Intel® UHD Graphics 630 > > ADDITIONAL INFORMATION > > $ plasma-discover --listbackends > Available backends: > * fwupd-backend > * kns-backend > * flatpak-backend > * packagekit-backend > > By a process of elimination I found that it's the packagekit backend that's > slow. Clicking Refresh after running it as 'plasma-discover --mode Update > --backends fwupd-backend,flatpak-backend,kns-backend' finished almost > immediately, and any combination of backends that doesn't involve > packagekit-backend is fast. Any combination that involves packagekit-backend > (including just that one, i.e. --backends packagekit-backend) takes 30+ > seconds. > > > DNF and PackageKit can both refresh their package lists in far less time > than Discover can: > > $ time pkcon refresh > Refreshing cache [=] > Loading cache [=] > Finished [=] > > real0m0.352s > user0m0.007s > sys 0m0.007s Although `pkcon refresh` takes less than a second, `pkcon refresh force` is much slower: $ time pkcon refresh force Refreshing cache [=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Downloading repository information[=] Loading cache [=] Querying [=] Loading cache [=] Finished [=] real0m33.664s user0m0.024s sys 0m0.013s It seems that discover is doing the equivalent of `refresh force` when you click on the systray widget, even if it's recently done a refresh. That's why it's always so slow. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466671] Discover is very slow to fetch updates
https://bugs.kde.org/show_bug.cgi?id=466671 --- Comment #2 from Jonathan Wakely --- Here's the output of pkmon when I click "Refresh" in the plasma-discover GUI: $ pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /5271_ecabaeab /5271_ecabaeab allow_cancel 1 /5271_ecabaeab percentage -1 /5271_ecabaeab role refresh-cache /5271_ecabaeab sender /usr/bin/plasma-discover /5271_ecabaeab status setup /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 1 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 6 /5271_ecabaeab percentage 7 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 13 /5271_ecabaeab percentage 14 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 20 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 27 /5271_ecabaeab status download-repository /5271_ecabaeab percentage 33 /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 34 /5271_ecabaeab percentage 48 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 54 /5271_ecabaeab percentage 55 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 60 /5271_ecabaeab percentage 61 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 68 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 75 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 81 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 88 /5271_ecabaeab percentage 89 /5271_ecabaeab status download-repository /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 95 /5271_ecabaeab percentage 96 /5271_ecabaeab status query /5271_ecabaeab status loading-cache /5271_ecabaeab percentage 100 /5271_ecabaeab status finished /5271_ecabaeab exit code: success Transactions: [none] Transactions: 1 /5272_abaddace /5272_abaddace allow_cancel 1 /5272_abaddace percentage -1 /5272_abaddace role get-updates /5272_abaddace sender /usr/bin/plasma-discover /5272_abaddace status setup /5272_abaddace status query updates-changed /5272_abaddace percentage 3 /5272_abaddace status loading-cache Transactions: 1 /5272_abaddace 2 /5273_cbccceeb /5273_cbccceeb allow_cancel 1 /5273_cbccceeb percentage -1 /5273_cbccceeb role get-updates /5273_cbccceeb sender /usr/libexec/DiscoverNotifier /5273_cbccceeb status wait /5272_abaddace percentage 6 /5272_abaddace percentage 8 /5272_abaddace percentage 39 /5272_abaddace percentage 91 /5272_abaddace percentage 100 /5272_abaddace status finished Transactions: 1 /5273_cbccceeb /5272_abaddace exit code: success /5273_cbccceeb status setup /5273_cbccceeb percentage 91 /5273_cbccceeb percentage 100 /5273_cbccceeb status finished Transactions: [none] /5273_cbccceeb exit code: success -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 433587] Do not fetch updates/packages on every start of Discover (on OpenSUSE)
https://bugs.kde.org/show_bug.cgi?id=433587 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #8 from Jonathan Wakely --- (In reply to Nate Graham from comment #1) > Dunno about Fedora. It's a problem on Fedora (yum repos have a ton of metadata which gets fetched when checking for updates). The time it takes to fetch that metadata seems to be exacerbated by things like Bug 457408 and Bug 466671, so that refreshing the updates is even slower in Discover than for pkcon or dnf. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466671] New: Discover is very slow to fetch updates
https://bugs.kde.org/show_bug.cgi?id=466671 Bug ID: 466671 Summary: Discover is very slow to fetch updates Classification: Applications Product: Discover Version: 5.27.1 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PackageKit Assignee: plasma-b...@kde.org Reporter: zi...@kayari.org CC: aleix...@kde.org Target Milestone: --- SUMMARY When opening discover from the systray widget when it shows updates are available, it takes 30+ seconds to show the available updates. The previous cause of slowness was supposed to have been fixed (Bug 457408) but I see no improvement in the default use case of "click on the systray widget when it shows updates". Maybe something got fixed in the KNewStuff backend, but there's another cause of slowness, and it has the same symptom: the "Fetching updates..." progress bar goes to about 97% immediately, then stops for 30 seconds. The same slowness happens when clicking the "Refresh" button. STEPS TO REPRODUCE 1. plasma-discover --mode Update 2. click Refresh 3. waaaiit OBSERVED RESULT Slow EXPECTED RESULT More fastish! SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-9850H CPU @ 2.60GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 630 ADDITIONAL INFORMATION $ plasma-discover --listbackends Available backends: * fwupd-backend * kns-backend * flatpak-backend * packagekit-backend By a process of elimination I found that it's the packagekit backend that's slow. Clicking Refresh after running it as 'plasma-discover --mode Update --backends fwupd-backend,flatpak-backend,kns-backend' finished almost immediately, and any combination of backends that doesn't involve packagekit-backend is fast. Any combination that involves packagekit-backend (including just that one, i.e. --backends packagekit-backend) takes 30+ seconds. DNF and PackageKit can both refresh their package lists in far less time than Discover can: $ time pkcon refresh Refreshing cache [=] Loading cache [=] Finished [=] real0m0.352s user0m0.007s sys 0m0.007s $ time sudo dnf check-update --refresh Copr repo for centpkg owned by james 7.2 kB/s | 3.3 kB 00:00 Copr repo for elektroid owned by jwakely 7.3 kB/s | 3.3 kB 00:00 Fedora 37 - x86_64 35 kB/s | 18 kB 00:00 Fedora 37 openh264 (From Cisco) - x86_64 1.7 kB/s | 989 B 00:00 Fedora Modular 37 - x86_64 31 kB/s | 18 kB 00:00 Fedora 37 - x86_64 - Updates 29 kB/s | 14 kB 00:00 Fedora Modular 37 - x86_64 - Updates 37 kB/s | 17 kB 00:00 google-chrome 5.7 kB/s | 1.3 kB 00:00 RCM Tools for Fedora 37 (RPMs) 5.5 kB/s | 3.8 kB 00:00 RPM Fusion for Fedora 37 - Free 38 kB/s | 6.8 kB 00:00 RPM Fusion for Fedora 37 - Free - Updates 18 kB/s | 6.5 kB 00:00 RPM Fusion for Fedora 37 - Nonfree 40 kB/s | 6.9 kB 00:00 RPM Fusion for Fedora 37 - Nonfree - Updates 39 kB/s | 6.6 kB 00:00 RHEL8 CSB packages 6.2 kB/s | 3.0 kB 00:00 real0m7.659s user0m2.361s sys 0m0.227s In fact I can usually check *and install* all updates using dnf before Discover has even managed to show me the available updates. --
[Discover] [Bug 466670] New: Discover fails to load when run with an unknown --mode
https://bugs.kde.org/show_bug.cgi?id=466670
Bug ID: 466670
Summary: Discover fails to load when run with an unknown --mode
Classification: Applications
Product: Discover
Version: 5.27.1
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: discover
Assignee: plasma-b...@kde.org
Reporter: zi...@kayari.org
CC: aleix...@kde.org
Target Milestone: ---
SUMMARY
Running 'plasma-discover --mode updates' opens with a "Loading..." progress bar
that never makes progress. It just hangs there forever.
STEPS TO REPRODUCE
1. plasma-discover --mode updates
2.
3.
OBSERVED RESULT
Discover prints an error to the terminal, then opens the GUI but just shows
"Loading..." forever.
$ plasma-discover --mode updates
adding empty sources model QStandardItemModel(0x564516a39890)
org.kde.plasma.discover: unknown mode "updates" ("Browsing", "Installed",
"Search", "Update", "Sources", "About")
org.kde.plasma.discover: couldn't open mode "updates"
packagekitqt.transaction: Unknown Transaction property: "Sender"
QVariant(QString, ":1.14386")
EXPECTED RESULT
Go to Home or some other mode instead.
SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.1
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.11-200.fc37.x86_64 (64-bit)
Graphics Platform: X11
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[Discover] [Bug 466243] Discover Updates new More Information button gives too much initial information.
https://bugs.kde.org/show_bug.cgi?id=466243 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #5 from Jonathan Wakely --- (In reply to Nate Graham from comment #3) > Hmm, perhaps I could add a feature to hide the changelogs and only show the > packages on the "More Information" page. Would that help? That would be great. I don't mind the package list only being shown when you click something, and I do like the fact you can get the full info if you need it. But also having a middle ground between "full info of every package with changes" and "nothing" would be great. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 453629] Show full window titles on Applications tab, as the KCM does
https://bugs.kde.org/show_bug.cgi?id=453629 --- Comment #5 from Jonathan Wakely --- (In reply to Bug Janitor Service from comment #3) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-pa/-/merge_requests/156 This suggests that nothing more useful than "AudioStream" can be shown. But clearly there is better info available, because the KCM for audio volume shows it. The duplicate bug 409453 has screenshots showing that. Maybe the merge request is using the wrong info if it can only show "AudioStream". -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 465224] New: Crash after leaving a room and going to another
https://bugs.kde.org/show_bug.cgi?id=465224 Bug ID: 465224 Summary: Crash after leaving a room and going to another Classification: Applications Product: NeoChat Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: General Assignee: fe...@posteo.de Reporter: zi...@kayari.org CC: c...@carlschwan.eu Target Milestone: --- Application: neochat (22.11) Qt Version: 5.15.7 Frameworks Version: 5.101.0 Operating System: Linux 6.1.5-100.fc36.x86_64 x86_64 Windowing System: X11 Distribution: Fedora Linux 36 (KDE Plasma) DrKonqi: 5.26.4 [KCrashBackend] -- Information about the crash: After right-clicking and selecting "Leave Room" on a room, when I click on another room to read the messages there, NeoChat crashes. The crash can be reproduced sometimes. -- Backtrace: Application: NeoChat (neochat), signal: Segmentation fault [KCrash Handler] #4 0x in ?? () #5 0x7fb97e6d5e42 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /lib64/libQt5Core.so.5 #6 0x557a3ad1f4f7 in UserListModel::setRoom(NeoChatRoom*) [clone .part.0] () #7 0x7fb97e6dbc26 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #8 0x557a3ad22651 in QtPrivate::QFunctorSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) [clone .lto_priv.0] () #9 0x7fb97e6dbc26 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #10 0x557a3ad03773 in RoomManager::enterRoom(NeoChatRoom*) () #11 0x557a3ac9454b in RoomManager::qt_metacall(QMetaObject::Call, int, void**) () #12 0x7fb9806e9933 in QQmlObjectOrGadget::metacall(QMetaObject::Call, int, void**) const () from /lib64/libQt5Qml.so.5 #13 0x7fb9805c1a09 in CallPrecise(QQmlObjectOrGadget const&, QQmlPropertyData const&, QV4::ExecutionEngine*, QV4::CallData*, QMetaObject::Call) () from /lib64/libQt5Qml.so.5 #14 0x7fb9805c3910 in QV4::QObjectMethod::callInternal(QV4::Value const*, QV4::Value const*, int) const () from /lib64/libQt5Qml.so.5 #15 0x7fb9805e090d in QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) () from /lib64/libQt5Qml.so.5 #16 0x7fb9805e4077 in QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) () from /lib64/libQt5Qml.so.5 #17 0x7fb980575586 in QV4::Function::call(QV4::Value const*, QV4::Value const*, int, QV4::ExecutionContext const*) () from /lib64/libQt5Qml.so.5 #18 0x7fb9807043b1 in QQmlJavaScriptExpression::evaluate(QV4::CallData*, bool*) () from /lib64/libQt5Qml.so.5 #19 0x7fb9806b4d3f in QQmlBoundSignalExpression::evaluate(void**) () from /lib64/libQt5Qml.so.5 #20 0x7fb9806b64c8 in QQmlBoundSignal_callback(QQmlNotifierEndpoint*, void**) () from /lib64/libQt5Qml.so.5 #21 0x7fb9806e93ff in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*, void**) () from /lib64/libQt5Qml.so.5 #22 0x7fb97e6db900 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #23 0x7fb97e2ef6d6 in QQuickAction::triggered(QObject*) () from /lib64/libQt5QuickTemplates2.so.5 #24 0x7fb97e2f1ebe in QQuickActionPrivate::trigger(QObject*, bool) () from /lib64/libQt5QuickTemplates2.so.5 #25 0x7fb97e2f82eb in QQuickAction::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libQt5QuickTemplates2.so.5 #26 0x7fb9806e9933 in QQmlObjectOrGadget::metacall(QMetaObject::Call, int, void**) const () from /lib64/libQt5Qml.so.5 #27 0x7fb9805c057d in CallPrecise(QQmlObjectOrGadget const&, QQmlPropertyData const&, QV4::ExecutionEngine*, QV4::CallData*, QMetaObject::Call) () from /lib64/libQt5Qml.so.5 #28 0x7fb9805c3910 in QV4::QObjectMethod::callInternal(QV4::Value const*, QV4::Value const*, int) const () from /lib64/libQt5Qml.so.5 #29 0x7fb9805e090d in QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) () from /lib64/libQt5Qml.so.5 #30 0x7fb9805e4077 in QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) () from /lib64/libQt5Qml.so.5 #31 0x7fb980575586 in QV4::Function::call(QV4::Value const*, QV4::Value const*, int, QV4::ExecutionContext const*) () from /lib64/libQt5Qml.so.5 #32 0x7fb9807043b1 in QQmlJavaScriptExpression::evaluate(QV4::CallData*, bool*) () from /lib64/libQt5Qml.so.5 #33 0x7fb9806b4d3f in QQmlBoundSignalExpression::evaluate(void**) () from /lib64/libQt5Qml.so.5 #34 0x7fb9806b64c8 in QQmlBoundSignal_callback(QQmlNotifierEndpoint*, void**) () from /lib64/libQt5Qml.so.5 #35 0x7fb9806e93ff in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*, void**) () from /lib64/libQt5Qml.so.5 #36 0x7fb97e6db900 in void doActivate(QObject*, int, void**) () from /lib64/libQt5Core.so.5 #37 0x7fb97e2f50b1 in
[Discover] [Bug 457408] Discover is slow to load when a lot of backends fail at the same time
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #12 from Jonathan Wakely --- N.B. it's specifically when hitting the "Refresh" button that it now takes 30-40s -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] Discover is slow to load when a lot of backends fail at the same time
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #11 from Jonathan Wakely --- It's still very very slow for "Fetching updates..." to finish with 5.26.5 Far worse, in fact. Here I run plasma-discover and when it opens (and everything is up to date) I hit "refresh", and it takes FOUR MINUTES: tmp$ time plasma-discover --mode Update QObject::startTimer: Timers cannot have negative intervals qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. adding empty sources model QStandardItemModel(0x55d643689e60) qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/globaltoolbar/ToolBarPageHeader.qml:12:1: QML ToolBarPageHeader: Binding loop detected for property "implicitWidth" qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:76:5: QML Binding: Binding loop detected for property "value" kf.newstuff.core: Could not find category "Calligra Flow Stencil" KNS error in "Calligra_stencils" : KNSCore::ConfigFileError "All categories are missing" QVariant(Invalid) invalid kns backend! "/etc/xdg/calligra_stencils.knsrc" because: "Invalid Calligra_stencils backend, contact your distributor." org.kde.plasma.libdiscover: Discarding invalid backend "calligra_stencils.knsrc" kns error "/etc/xdg/calligra_stencils.knsrc" "Invalid Calligra_stencils backend, contact your distributor." ** (process:477766): WARNING **: 10:54:32.945: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.latte-dock.desktop/*', skipping it. ** (process:477766): WARNING **: 10:54:32.965: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.discover.snap/*', skipping it. ** (process:477766): WARNING **: 10:54:32.980: Found icon of unknown type 'unknown' in 'system/package/os/io.github.syllo.nvtop/*', skipping it. ** (process:477766): WARNING **: 10:54:33.122: Found icon of unknown type 'unknown' in 'system/package/os/com.github.maliit.keyboard/*', skipping it. ** (process:477766): WARNING **: 10:54:33.204: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.kiten.desktop/*', skipping it. real3m57.966s user0m6.412s sys 0m0.498s tmp$ time plasma-discover --mode Update QObject::startTimer: Timers cannot have negative intervals qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. adding empty sources model QStandardItemModel(0x55b55a561640) qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/globaltoolbar/ToolBarPageHeader.qml:12:1: QML ToolBarPageHeader: Binding loop detected for property "implicitWidth" qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:76:5: QML Binding: Binding loop detected for property "value" kf.newstuff.core: Could not find category "Calligra Flow Stencil" KNS error in "Calligra_stencils" : KNSCore::ConfigFileError "All categories are missing" QVariant(Invalid) invalid kns backend! "/etc/xdg/calligra_stencils.knsrc" because: "Invalid Calligra_stencils backend, contact your distributor." org.kde.plasma.libdiscover: Discarding invalid backend "calligra_stencils.knsrc" kns error "/etc/xdg/calligra_stencils.knsrc" "Invalid Calligra_stencils backend, contact your distributor." ** (process:479295): WARNING **: 10:58:42.636: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.latte-dock.desktop/*', skipping it. ** (process:479295): WARNING **: 10:58:42.655: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.discover.snap/*', skipping it. ** (process:479295): WARNING **: 10:58:42.670: Found icon of unknown type 'unknown' in 'system/package/os/io.github.syllo.nvtop/*', skipping it. ** (process:479295): WARNING **: 10:58:42.815: Found icon of unknown type 'unknown' in 'system/package/os/com.github.maliit.keyboard/*', skipping it. ** (process:479295): WARNING **: 10:58:42.895: Found icon of unknown type 'unknown' in 'system/package/os/org.kde.kiten.desktop/*', skipping it. real0m3.756s user0m4.036s sys 0m0.376s tmp$ time plasma-discover --mode Update QObject::startTimer: Timers cannot have negative intervals qrc:/qml/DiscoverPage.qml:17:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. adding empty sources model QStandardItemModel(0x55cb41a30c10) qrc:/qml/DiscoverPage.qml:17
[dragonplayer] [Bug 409201] Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 --- Comment #7 from Jonathan Wakely --- After track 1 finishes and track 2 starts, the "previous" control becomes available, to go back to track 1. But there's still no "next" option. Even if I click "previous" to go back to track 1 after track 2 starts, "next" is still greyed out. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 409201] Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 --- Comment #6 from Jonathan Wakely --- OK I was still using gstreamer. With the vlc backend it plays track 2 straight after track 1. But the "next" control doesn't work, so there's no way to *skip* to track 2, except using the slider to go to the end of track 1 and then waiting. The status at the bottom of the window seems broken with vlc though, instead of "Track 1/4" it just says "Track /" and the play position always shows the length of track 1 after track one finishes and track 2 starts to play. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 409201] Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 --- Comment #3 from Jonathan Wakely --- Actually, I have phonon-vlc installed but I don't know how to tell if I'm using it. Where did the KCM module for selecting backend go? -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 409201] Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 Jonathan Wakely changed: What|Removed |Added Version|18.12 |22.08.1 -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 409201] Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 Jonathan Wakely changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Yes, 22.08.1 still has the same broken behaviour. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 460233] New: Clicking "Advanced..." on any NM connection always prompts to save changes
https://bugs.kde.org/show_bug.cgi?id=460233 Bug ID: 460233 Summary: Clicking "Advanced..." on any NM connection always prompts to save changes Classification: Plasma Product: plasma-nm Version: 5.25.5 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: editor Assignee: plasma-b...@kde.org Reporter: zi...@kayari.org Target Milestone: --- SUMMARY NM connection editor always prompts to save/discard changed settings when you haven't changed any settings. This happens for any of the buttons to open additional settings, on the following tabs in a connection editor: IPv4 -> Advanced... IPv4 -> Routes... IPv6 -> Routes... VPN (openvpn) -> Advanced... STEPS TO REPRODUCE 1. Open System Settings -> Connections and click on any active or inactive connection. 2. Select the IPv4 tab then click the "Advanced..." or "Routes..." button. 3. Cancel to close the popup, then click on a different connection. OBSERVED RESULT A popup appears prompting "Do you want to save changes made to the connection 'Wired Connection 2'?" EXPECTED RESULT If you cancel the "Advanced" or "Routes" dialog without making changes, you should not be prompted to save any changed. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.11-200.fc36.x86_64 (64-bit) Graphics Platform: X11 Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 630 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 434948] "Tasks" progress resets for each separate task
https://bugs.kde.org/show_bug.cgi?id=434948 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 458657] Discover asks for password twice when installing a flatpak bundle
https://bugs.kde.org/show_bug.cgi?id=458657 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 454521] Installing Flatpaks, each dependency restarts the progressbar
https://bugs.kde.org/show_bug.cgi?id=454521 --- Comment #1 from Jonathan Wakely --- (In reply to Marcello Massaro from comment #0) > EXPECTED RESULT > If the progressbar reaches 100%, I expect the package to be *fully* > installed, not only one of its parts. Agreed. As a user, I have no idea there are multiple dependencies being installed here, I just see a single progress bar that keeps jumping back to 0%. It would be more helpful to either show something indicating which dependency the progress bar relates to (so you can see that it's not just restarting, but making actual progress on different packages) or divide 100% by the number of packages, and e.g. use 0-33% for the first one, then 34-66 for the second, and 67-100 for the last one, so it is only 100% complete when actually complete. Possibly related, it seems that the flatpak backend will install multiple updates if there is more than one available. E.g. I had signal-desktop.deb 5.56.0 installed, and Discover told me there was a 5.57.0 update, but after it finishes (with multiple progress bar restarts) it appears to have installed both 5.57.0 and 5.58.0. In that case, it's not even restarting the progress bar for dependencies, it's an entirely separate update, isn't it? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 454521] Installing Flatpaks, each dependency restarts the progressbar
https://bugs.kde.org/show_bug.cgi?id=454521 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] KNewStuff backend is very slow to load when the PackageKit or Flatpak backend also loads at the same time
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > If I use --backends fwupd-backend,kns-backend then it loads immediately. > Similarly, if I use just flatpak-backend or just packagekit-backend, it > loads immediately. This suggests that there is caching happening, and that for some combinations of backends, the already-cached set of updates is reused and quickly loaded. But for some "bad" combinations, the cache isn't used, and so some of the updates get re-fetched every time, making it slow. And the default (all backends enabled) happens to be one of those bad combinations. Just a guess though. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] KNewStuff backend is very slow to load
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #4 from Jonathan Wakely --- Created attachment 151074 --> https://bugs.kde.org/attachment.cgi?id=151074=edit Output of plasma-discover --backends flatpak-backend,kns-backend --mode Update This is the output of the same command but using flatpak-backend,kns-backend Now, the UI takes 16 seconds to go from "Fetching updates" to "Up to date", and then takes even longer to actually be responsive (maybe the flatpak backend is still updating in a background thread?). It takes another 20+ seconds to actually be responsive and let me click on anything (it won't even close the window during that time, clicking the close button brings up the 'Application "discover" is not responding' dialog to kill it). If I use --backends fwupd-backend,kns-backend then it loads immediately. Similarly, if I use just flatpak-backend or just packagekit-backend, it loads immediately. But it's very slow when kns-backend is combined with either flatpak-backend or packagekit-backend. And of course all of them are enabled by default when you click the update notifier. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] KNewStuff backend is very slow to load
https://bugs.kde.org/show_bug.cgi?id=457408 Jonathan Wakely changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] KNewStuff backend is very slow to load
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #3 from Jonathan Wakely --- Created attachment 151072 --> https://bugs.kde.org/attachment.cgi?id=151072=edit Output of plasma-discover --backends kns-backend --mode Update This is the output of that command. However, when I run this, the UI finishes loading and is responsive almost immediately. So although this output shows lots of errors (which I'm told are already fixed after 5.25.3) they don't seem to be the cause of the slowness. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] Opening discover is still horribly slow
https://bugs.kde.org/show_bug.cgi?id=457408 --- Comment #1 from Jonathan Wakely --- Is it even possible to disable that backend? I don't see anything under Settings in the discover app, or any discoverrc config setting that would disable the kns-backend (or any other backend). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443555] Discover takes up to ~5 minutes to fetch updates due to flatpak backend
https://bugs.kde.org/show_bug.cgi?id=443555 Jonathan Wakely changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=457408 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] Opening discover is still horribly slow
https://bugs.kde.org/show_bug.cgi?id=457408 Jonathan Wakely changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=443555 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] Opening discover is still horribly slow
https://bugs.kde.org/show_bug.cgi?id=457408 Jonathan Wakely changed: What|Removed |Added See Also|https://bugs.kde.org/show_b | |ug.cgi?id=455833| -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 455833] Discover constantly indicates updates available.
https://bugs.kde.org/show_bug.cgi?id=455833 Jonathan Wakely changed: What|Removed |Added See Also|https://bugs.kde.org/show_b | |ug.cgi?id=457408| CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 455833] Discover constantly indicates updates available.
https://bugs.kde.org/show_bug.cgi?id=455833 Jonathan Wakely changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=457408 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457408] New: Opening discover is still horribly slow
https://bugs.kde.org/show_bug.cgi?id=457408 Bug ID: 457408 Summary: Opening discover is still horribly slow Product: Discover Version: 5.25.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Notifier Assignee: plasma-b...@kde.org Reporter: zi...@kayari.org CC: aleix...@kde.org Target Milestone: --- There's still something wrong with the Discover UX, despite Bug 443555 fixing the worst source of slowness. If I get a systray notification that there are updates, and I click on it, it takes 30 seconds to stop showing the "fetching updates" progress bar. Why? Is it refreshing something? It doesn't seem to be, because it still tells me I have system RPMs to update, even though I've already updated them on the command line with dnf. So it's not refreshing the packagekit backend, otherwise it would know that the updates have been installed. The available backends are: $ plasma-discover --listbackends Available backends: * kns-backend * packagekit-backend * fwupd-backend * flatpak-backend If I run 'plasma-discover --backends flatpak-backend,packagekit-backend,fwupd-backend' then the window loads instantly, and takes less than a second to finish "Fetching updates" and show "Up to date" at the bottom left corner. If I add kns-backend to that list, the window opens but shows "Fetching updates" and is completely unresponsive for 30 seconds. Is that the same problem as when I click on the "Updates available" notification? What even is KNewStuff, and what do I miss out on if I disable it? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 444917] Make "updates available" notifications more informative
https://bugs.kde.org/show_bug.cgi?id=444917 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #4 from Jonathan Wakely --- (In reply to Aleix Pol from comment #1) > How would a more populated notification improve your experience? It doesn't > even tell you all the things that changed. It could tell me whether the detected updates are "System Updates", or flatpak updates, or firmware etc. I don't use Discover for system updates because it's horribly slow, I just use dnf on the command-line. But I do use it for flatpak and fwupd updates, because I'm lazy and they're less frequent so I don't mind the slowness. So it would be nice if the "updates available" notification let me know if it's something I can ignore. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 452760] "Apply settings dialog" occurs when leaving "Activity Power Settings" though nothing was changed
https://bugs.kde.org/show_bug.cgi?id=452760 Jonathan Wakely changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=408882 --- Comment #3 from Jonathan Wakely --- As soon as you navigate to the Activity Power Settings module an * is shown in the title bar, suggesting there are changes (even though you haven't clicked on anything yet). If you click on "Reset" the * goes away, and it no longer prompts you to apply/discard changes when navigating away. Probably related to Bug 408882. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 408882] Nothing happens when you click on "Reset" button in "Activity power settings" section of the "Power management" kcm
https://bugs.kde.org/show_bug.cgi?id=408882 Jonathan Wakely changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=452760 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 408882] Nothing happens when you click on "Reset" button in "Activity power settings" section of the "Power management" kcm
https://bugs.kde.org/show_bug.cgi?id=408882 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #2 from Jonathan Wakely --- N.B. the * in the title bar does go away when you click Reset, and it no longer prompts to apply changes. So it is doing something, it just doesn't actually reset the settings shown in the GUI. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 452760] "Apply settings dialog" occurs when leaving "Activity Power Settings" though nothing was changed
https://bugs.kde.org/show_bug.cgi?id=452760 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #2 from Jonathan Wakely --- *** Bug 456042 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 456042] kcm_powerdevilactivitiesconfig module always prompts to apply changes, when there aren't any
https://bugs.kde.org/show_bug.cgi?id=456042 Jonathan Wakely changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Oh this is a dup but I looked under the wrong component *** This bug has been marked as a duplicate of bug 452760 *** -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 456042] New: kcm_powerdevilactivitiesconfig module always prompts to apply changes, when there aren't any
https://bugs.kde.org/show_bug.cgi?id=456042 Bug ID: 456042 Summary: kcm_powerdevilactivitiesconfig module always prompts to apply changes, when there aren't any Product: Powerdevil Version: 5.24.5 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: zi...@kayari.org CC: m...@ratijas.tk Target Milestone: --- SUMMARY The powerdevil settings module always prompts you to apply changes before navigating away from it, even though there are no changes. STEPS TO REPRODUCE 1. Open System Settings, go to Power Management then Activity Power Settings 2. Click on any other settings module (e.g. Energy Saving) OBSERVED RESULT Navigating away from the Activities settings plays a notification bell and shows the "Apply Settings - System Settings" dialog, which says "The settings of the current module have changed. Do you want to apply the changes or discard them?" This is shown even if you didn't change anything in the Activities settings. EXPECTED RESULT Only prompt to apply settings if there were changes. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.3 Kernel Version: 5.18.5-200.fc36.x86_64 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 439192] System settings crashes in Bolt::Manager::~Manager() after navigating away from thunderbolt page
https://bugs.kde.org/show_bug.cgi?id=439192 --- Comment #11 from Jonathan Wakely --- Created attachment 150185 --> https://bugs.kde.org/attachment.cgi?id=150185=edit valgrind log of 'kcmshell5 bolt' Valgrind shows the destruction of the bold module is riddled with bugs, but possibly all caused by one double free. Fixing that might make all the later errors go away. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 439192] System settings crashes in Bolt::Manager::~Manager() after navigating away from thunderbolt page
https://bugs.kde.org/show_bug.cgi?id=439192
--- Comment #10 from Jonathan Wakely ---
The crash is an abort in glibc caused by double free on line 2104 of
qt5-qtbase-5.15.3-3.fc36.x86_64/src/corelib/kernel/qobject.cpp
2099// don't use qDeleteAll as the destructor of the child might
2100// delete siblings
2101for (int i = 0; i < children.count(); ++i) {
2102currentChildBeingDeleted = children.at(i);
2103children[i] = 0;
2104delete currentChildBeingDeleted;
2105}
2106children.clear();
The comment suggests that when a child deletes a sibling it fails to set that
entry in the vector to a null pointer, so that the parent subsequently tries to
delete that pointer again.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 439192] System settings crashes in Bolt::Manager::~Manager() after navigating away from thunderbolt page
https://bugs.kde.org/show_bug.cgi?id=439192 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #9 from Jonathan Wakely --- Created attachment 150184 --> https://bugs.kde.org/attachment.cgi?id=150184=edit GDB backtrace of crash 100% reproducible with Fedora RPMs too, using kde-cli-tools-5.24.5-1.fc36.x86_64 in an X11 plasma session. Running kcmshell5 bolt and just clicking the "Close" button shows: Previously registered enum will be overwritten due to name clash: Bolt.Secure Possible conflicting items: Bolt.Auth.Secure from scope Bolt injected by Bolt Bolt.Security.Secure from scope Bolt injected by Bolt file:///usr/lib64/qt5/qml/org/kde/kirigami.2/PlaceholderMessage.qml:235:5: QML Heading: Binding loop detected for property "verticalAlignment" kf.kirigami: The Theme singleton is deprecated (since 5.39). Import Kirigami 2.2 or higher and use the attached property instead. file:///usr/share/kpackage/kcms/kcm_bolt/contents/ui/DeviceList.qml:24:13: QML RowLayout: Cannot anchor to an item that isn't a parent or sibling. double free or corruption (out) KCrash: Application 'kcmshell5' crashing... KCrash: Attempting to start /usr/libexec/drkonqi Alarm clock -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 427516] Thunderbolt kcm crashes in Bolt::Device::~Device() on destruction
https://bugs.kde.org/show_bug.cgi?id=427516 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #2 from Jonathan Wakely --- (In reply to Nate Graham from comment #1) > > *** This bug has been marked as a duplicate of bug 426047 *** It looks like Bug 439192 is a better match for this one, i.e. specific to the thunderbolt module. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 453629] Show full window titles on Applications tab, as the KCM does
https://bugs.kde.org/show_bug.cgi?id=453629 --- Comment #2 from Jonathan Wakely --- Still present with: Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 453629] New: Applications tab only shows "Firefox" for windows, without titles
https://bugs.kde.org/show_bug.cgi?id=453629 Bug ID: 453629 Summary: Applications tab only shows "Firefox" for windows, without titles Product: plasma-pa Version: 5.24.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: applet Assignee: plasma-b...@kde.org Reporter: zi...@kayari.org CC: m...@ratijas.tk, now...@gmail.com Target Milestone: --- SUMMARY The Audio plasmoid just shows "Firefox" as the name on the Applications tab, instead of the titles of the Firefox windows. If there are multiple such windows, you have to look at the horizontal meter to see which one is actually playing Audio. If the audio is paused, the meter is no use and you just have to guess. This matters when trying to change the output device for a specific window, e.g. to have one playing through speakers and one through headphones. The Playback Streams under System Settings -> Audio do show the full titles, which is much more helpful, and shows that the information is available. The plasmoid just doesn't show it. STEPS TO REPRODUCE 1. Have multiple Firefox windows playing audio, e.g. two youtube videos paused in two separate windows. 2. Open the Audio applet, then the Applications tab. 3. Try to guess which "Firefox" is which. OBSERVED RESULT The application just shows "Firefox". EXPECTED RESULT The application shows the window title, like in System Settings -> Audio under Playback Streams. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 35 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.19-100.fc34.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 443555] Discover takes up to ~5 minutes to fetch updates due to flatpak backend
https://bugs.kde.org/show_bug.cgi?id=443555 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 375877] Fetching Updates takes incredibly long time
https://bugs.kde.org/show_bug.cgi?id=375877 --- Comment #12 from Jonathan Wakely --- Time to run the command and then quit the app as soon as it finishes "Loading..." the updates. $ time plasma-discover --backends flatpak file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. real4m46.710s user0m22.899s sys 0m8.797s Running the same command again right away: $ time plasma-discover --backends flatpak file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. real0m10.474s user0m4.988s sys 0m2.028s That's still pretty slow even with a fresh cache. And for PK: $ time plasma-discover --backends packagekit adding empty sources model QStandardItemModel(0x56366b77b160) file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWindow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. ** (process:795073): WARNING **: 14:40:20.266: System cache issue: The AppStream system cache was updated, but some errors were detected, which might lead to missing metadata. Refer to the verbose log for more information. real0m3.491s user0m2.518s sys 0m0.452s So it seems that flatpak is the slow part, even when the cache is up to date. If I just run "plasma-discover" and click on the "Fetching updates..." (which quickly turns into "Update (32)") menu item at the bottom left, the progress bar is still going, at about 95% or so, until at least 10 seconds after starting the app. That matches what I see when I click on the systray popup: it shows a progress bar at about 95% and stays like that for a subjectively long time (sometimes over 30 seconds). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 375877] Fetching Updates takes incredibly long time
https://bugs.kde.org/show_bug.cgi?id=375877 --- Comment #11 from Jonathan Wakely --- (In reply to Aleix Pol from comment #9) > I am sorry but this is simply not true. In PackageKitBackend.cpp:107 you can > see that we only refresh the cache if it's over 1 hour old. And yet when I've JUST booted up and got the systray popup as soon as I login, it takes 30+ seconds to show the available updates. Is the systray popup using stale data straight after boot, so then when I open the GUI it refreshes? > It would be useful if you can provide feedback if you have the same problem > when running with: > > * plasma-discover --backends flatpak > * plasma-discover --backends packagekit I'll try this and report back. > Also could you state which distros are you on respectively? See above, Fedora 34 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 375877] Fetching Updates takes incredibly long time
https://bugs.kde.org/show_bug.cgi?id=375877 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #8 from Jonathan Wakely --- The problem is that Discover is unbearably slow to query updates, and it doesn't cache them so has to keep re-fetching them. When Discover shows a systray alert to tell me there are updates and I click the popup, it takes about 30 seconds for it to show me the available updates. Despite the fact that it JUST finished checking for updates and told me there are available updates. Why check again immediately, when it only checked a few seconds ago? Why isn't there a cache with an expiration age? Is it the firmware and/or flatpak updates that are slow, as dnf doesn't check for those? Is there not a cache for those updates? Checking using dnf or pkcon is much faster. So much faster that while waiting for Discover to finish fetching updates I can open konsole, run sudo dnf, enter my password, **and download and install the updates** before Discover even finishes checking for them. SOFTWARE/OS VERSIONS Discover: 5.24.3 Operating System: Fedora 34 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.18-100.fc34.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 445154] New: hyperlink truncated for an email address with long TLD
https://bugs.kde.org/show_bug.cgi?id=445154
Bug ID: 445154
Summary: hyperlink truncated for an email address with long TLD
Product: konversation
Version: 1.8.21041
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: ircview
Assignee: argo...@gmail.com
Reporter: zi...@kayari.org
CC: konversation-de...@kde.org
Target Milestone: ---
SUMMARY
An email address such as test@foo.invalid is not displayed correctly, the
hyperlink doesn't include the final 'd'
That email address isn't valid, but the same thing happens for any address at
foo.website or foo.computer or foo.academy or any other TLD longer than 6
characters.
STEPS TO REPRODUCE
1. send an IRC message containing foo@test.abcdefghi
2. look at the hyperlink konversation creates
3.
OBSERVED RESULT
Only "foo@test.abcdef" is hyperlinked.
EXPECTED RESULT
The whole email address should be a hyperlink.
SOFTWARE/OS VERSIONS
Konversation: 1.8.21041
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
This seems to be a bug in the urlPattern regex:
https://github.com/KDE/konversation/blob/9288fab598d84ceaf4ff1d5a782adf6882e2ec57/src/common.h#L24
The relevant part for email addresses seems to be
@[a-z0-9.\\-]+[.][a-z]{1,5}[^...] which assumes a maximum length of 5+1
Maybe changing the {1,5} to simply + would work.
--
You are receiving this mail because:
You are watching all bug changes.
[ark] [Bug 292935] Ark should offer an option to ignore common metadata files
https://bugs.kde.org/show_bug.cgi?id=292935 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > If it's easily turned on/off it's probably sufficient to just ignore > __MACOSX and .DS_Store folders at the top level of the archive. If they > occur below the top level, they might be there intentionally (if they'd been > created automatically on MacOS then they'd also be present at the top level). Ah no, that won't work for .DS_Store as that occurs at any level. But the __MACOSX folder should only be at the top-level. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 292935] Ark should offer an option to ignore common metadata files
https://bugs.kde.org/show_bug.cgi?id=292935 --- Comment #6 from Jonathan Wakely --- (In reply to Andrew Udvare from comment #2) > Maybe arkrc can have a section for meta data files to ignore so advanced > users can edit the list without having to modify Ark's source. > > [IgnoreExactMatch] > Thumbs.db > .DS_Store > __MACOSX > .directory That customization feature might be nice, but might cause issues for people who don't realize the feature exists and don't know where to make the customization. I think having the feature off by default is probably safest, but there could be a global configuration to turn it on, and the "Extract" dialog could show a checkbox for it with the other Options, to allow it to be turned on for individual extract operations (rather than globally). If it's easily turned on/off it's probably sufficient to just ignore __MACOSX and .DS_Store folders at the top level of the archive. If they occur below the top level, they might be there intentionally (if they'd been created automatically on MacOS then they'd also be present at the top level). > This also means Ark would never have to actually test the contents of these > files/directories should one appear in an archive that isn't actually what > these normally are (especially since Thumbs.db could definitely mean a > thumbnail database to something completely different). If it's easily enabled/disabled in the Extract dialog I think testing the contents of the metadata dirs probably isn't necessary. If extra checks are desirable though, I suggest the heuristic should be that a folder called __MACOSX or .DS_Store is not extracted if everything below it is either a folder, or an AppleDouble file (i.e. one beginning with "._"). I don't think it's necessary to verify that there's a one-to-one mapping from those AppleDouble files to the actual files elsewhere in the archive. If somebody wants to extract them, they can just uncheck the "Ignore metadata junk" option. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 292935] Ark should offer an option to ignore common metadata files
https://bugs.kde.org/show_bug.cgi?id=292935 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #5 from Jonathan Wakely --- I was just about to create a new wishlist report for exactly this feature. Yes, the problem still exists (using Ark version 20.08.1). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 434150] KisBezierTransformMesh.cpp : FTBFS (gcc11 issue?)
https://bugs.kde.org/show_bug.cgi?id=434150
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> static constexpr bool test(A *pointer) {
Oh, now that 'poionter' is unused you might want to remove the name of that
parameter, to avoid -Wunused-parameter warnings.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 434150] KisBezierTransformMesh.cpp : FTBFS (gcc11 issue?)
https://bugs.kde.org/show_bug.cgi?id=434150
--- Comment #5 from Jonathan Wakely ---
Maybe you meant to use typename A::value_type not typename T::value_type, but
it still wouldn't work.
This would be better:
template().push_back(std::declval()))>
static constexpr bool test(A *pointer) {
return is_container::value && std::is_same::value;
}
You could also use std::is_void::value instead of is_same.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 434150] KisBezierTransformMesh.cpp : FTBFS (gcc11 issue?)
https://bugs.kde.org/show_bug.cgi?id=434150 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #4 from Jonathan Wakely --- KritaUtils::is_appendable_container is completely broken. You need to test the pointer->push_back expression in a SFINAE context, not in the function body. This is not a GCC bug. -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 418814] Add option to remove some special characters from filenames when extracting audio
https://bugs.kde.org/show_bug.cgi?id=418814 --- Comment #8 from Jonathan Wakely --- (In reply to Albert Astals Cid from comment #3) > Honestly i don't think it's k3b issue to circunvent issues with filesystems. It's not an "issue" with the filesystem, it's a property of the filesystem. Just like not being able to use '/' in filenames on unix-like systems. k3b assumes it is always writing to a unix-like filesystem, which isn't true if you're ripping to a removable device like a portable hdd, sdcard, memory stick etc. -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 418814] Add option to remove some special characters from filenames when extracting audio
https://bugs.kde.org/show_bug.cgi?id=418814 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #7 from Jonathan Wakely --- This isn't only a problem on Windows, it also applies when ripping files to any device formatted as FAT32. This is very common, because SD cards and USB sticks are often formatted as FAT32 for compatibility with devices like car stereo systems. If I try to rip a track with a colon or question mark in its name it fails (after ripping any earlier tracks) because the filename can't be created on the FAT32 partition. The only solution is rip to a different partition (e.g. an ext4 drive on the computer) then rename the files then copy them over. There is already an option to replace blanks with another character. I also like need to be able to specify that ':' and '?' characters should be replaced. Ideally it would be fully customisable so that any characters can be replaced, maybe like the UNIX tr utility (e.g. replace all uppercase with lowercase). But that is less important than just being able to rip to FAT32 destinations. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 379848] When there is a lot of WiFi connections, the VPN connection is not shown in the list
https://bugs.kde.org/show_bug.cgi?id=379848 --- Comment #28 from Jonathan Wakely --- I used to see this bug when out and about, somewhere with lots of unknown WiFi networks. With my country being under lockdown or with travel restrictions for most of the year, that hasn't been possible. So maybe it's still happening, but I can't tell. I'll try to verify it at some unknown point in future. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 423052] [FTBFS]: kwin on f33 / s390x
https://bugs.kde.org/show_bug.cgi?id=423052 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org -- You are receiving this mail because: You are watching all bug changes.
[kscd] [Bug 333500] KsCD UI is awful
https://bugs.kde.org/show_bug.cgi?id=333500 --- Comment #10 from Jonathan Wakely --- (In reply to groot from comment #9) > That's not a very satisfying end to this bug, since you -- original > submiutter -- have a lot of ideas with the UI itself. But KSCD is dead, > unless you pick up the kf5 branch and run with it. Actually I'm fairly satisfied with that. Better to just get rid of it than keep that UI! -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 408512] Add new printer gives "Failed to get a list of devices: 'Forbidden'"
https://bugs.kde.org/show_bug.cgi?id=408512 --- Comment #8 from Jonathan Wakely --- Let me try and explain this differently. My original report said: EXPECTED RESULT Prompt for root password, so printers can be detected. That's what I still think should happen. If the user happens to have admin privs due to distro settings, or the specific config on a specific machine, or because the user is root, then there's no need to prompt. Great, it Just Works. But it seems very silly, and unsafe, to say that the solution to "this operation needs elevated privs" is that all distros should give elevated privs to normal users, all the time (or that users should only use less secure distros). If an operation needs elevated privs, ask for them. That's what KAuth is for: https://api.kde.org/frameworks/kauth/html/index.html (In reply to Nate Graham from comment #6) > your options are to go bug your distro, or use a different distro. As a distro maintainer, I consider this is an irresponsible and even dangerous statement. -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 408512] Add new printer gives "Failed to get a list of devices: 'Forbidden'"
https://bugs.kde.org/show_bug.cgi?id=408512 Jonathan Wakely changed: What|Removed |Added Resolution|UPSTREAM|--- Status|RESOLVED|REOPENED --- Comment #7 from Jonathan Wakely --- Why can't you prompt for a root password to get elevated privileges temporarily? -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 408512] Add new printer gives "Failed to get a list of devices: 'Forbidden'"
https://bugs.kde.org/show_bug.cgi?id=408512 Jonathan Wakely changed: What|Removed |Added Resolution|UPSTREAM|--- Status|RESOLVED|REOPENED --- Comment #5 from Jonathan Wakely --- I don't consider this fixed. It should be possible for non-admin users to add a printer. Requiring me to add my user to the wheel group is not a "fix". Yes, I know the Fedora default is to add users to wheel, but I override that during installation. kdesu or equivalent functionality should be used to get elevated privs in order to add the printer. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 --- Comment #6 from Jonathan Wakely --- I tried creating smaller partitions to try and avoid exceeding some limit, but it still said there were more clusters than there was space for FAT entries, e.g. [root@wraith ~]# fsck.fat -r -w -v -V /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 1) Correct 2) Don't correct (FSINFO invalid then) ? 1 Filesystem has 1599615 clusters but only space for 1572862 FAT entries. Even when I tried something like a 32GiB partition I got that same error from fsck.fat. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 --- Comment #5 from Jonathan Wakely --- The first attachment is all that paritionmanager told me. I tried running the failing commands by hand on the terminal, and the output of those is shown in comment 0. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 --- Comment #3 from Jonathan Wakely --- Created attachment 122469 --> https://bugs.kde.org/attachment.cgi?id=122469=edit Output of successful format by gparted -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 --- Comment #2 from Jonathan Wakely --- Created attachment 122468 --> https://bugs.kde.org/attachment.cgi?id=122468=edit Output of failed attempt to format CF card This is the output of one of the paritionmanager runs that gave an error. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 --- Comment #1 from Jonathan Wakely --- I forgot to say that when the card arrived it didn't have any partitions created. I would have hoped that paritionmanager could be used to do the initial format of a new disk, and completely wipe away whatever is needed to do it correctly. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 411559] New: Failed to format a Compact Flash card as FAT32
https://bugs.kde.org/show_bug.cgi?id=411559 Bug ID: 411559 Summary: Failed to format a Compact Flash card as FAT32 Product: partitionmanager Version: 4.0.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: zi...@kayari.org Target Milestone: --- I bought a brand new 64GB CF card and when it arrived I tried to use partitionmanager to format it as a single FAT32 partition. Every time I tried it told me there was an error. Running the fsck.fat commands manually I kept seeing errors: [root@wraith ~]# fsck.fat -a -w -v /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 Auto-correcting it. Filesystem has 1691491 clusters but only space for 1662974 FAT entries. [root@wraith ~]# echo $? 1 No matter what I tried to do in partitionmanager, it would fail and fsck.fat would show similar errors that it couldn't resolve: [root@wraith ~]# fsck.fat -a -w -v /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 Auto-correcting it. Boot sector contents: System ID "lkfs.f`t" Media byte 0xf8 (hard disk) 512 bytes per logical sector 32768 bytes per cluster 64 reserved sectors First FAT starts at byte 32768 (sector 64) 2 FATs, 32 bit entries 6553600 bytes per FAT (= 12800 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 13139968 (sector 25664) 1631599 data clusters (53464236032 bytes) 32 sectors/track, 64 heads 2048 hidden sectors 104448000 sectors total Cluster 0 out of range (251657976 > 1631600). Setting to EOF. Reclaiming unconnected clusters. Checking free cluster summary. Free cluster summary uninitialized (should be 1631598) Auto-setting. Performing changes. /dev/sdg1: 1 files, 1/1631599 clusters [root@wraith ~]# fsck.fat -r -w -v -V /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 1) Correct 2) Don't correct (FSINFO invalid then) ? 1 Boot sector contents: System ID "lkfs.f`t" Media byte 0xf8 (hard disk) 512 bytes per logical sector 32768 bytes per cluster 64 reserved sectors First FAT starts at byte 32768 (sector 64) 2 FATs, 32 bit entries 6553600 bytes per FAT (= 12800 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 13139968 (sector 25664) 1631599 data clusters (53464236032 bytes) 32 sectors/track, 64 heads 2048 hidden sectors 104448000 sectors total Starting check/repair pass. Cluster 0 out of range (251657976 > 1631600). Setting to EOF. Checking for unused clusters. Checking free cluster summary. Free cluster summary uninitialized (should be 1631598) 1) Set it 2) Leave it uninitialized ? 1 Starting verification pass. Checking for unused clusters. Perform changes ? (y/n) y /dev/sdg1: 1 files, 1/1631599 clusters [root@wraith ~]# fatlabel /dev/sdg1 FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 Auto-correcting it. Filesystem has 1691401 clusters but only space for 1662974 FAT entries. [root@wraith ~]# fsck.fat -r -w -v -V /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 1) Correct 2) Don't correct (FSINFO invalid then) ? 1 Filesystem has 1691401 clusters but only space for 1662974 FAT entries. [root@wraith ~]# [root@wraith ~]# [root@wraith ~]# [root@wraith ~]# fsck.fat -r -w -v -V /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 135:6e/6f, 167:6e/6f 1) Copy original to backup 2) Copy backup to original 3) No action ? 3 FSINFO sector has bad magic number(s): Offset 0: 0x40615252 != expected 0x41615252 Offset 484: 0x60417272 != expected 0x61417272 1) Correct 2) Don't correct (FSINFO invalid then) ? 1 Filesystem has 1691401 clusters but only space for 1662974 FAT entries. [root@wraith ~]# [root@wraith ~]# [root@wraith ~]# fsck.fat -r -w -v -V /dev/sdg1 fsck.fat 4.1 (2017-01-24) Checking we can access the last sector of the filesystem FSINFO sector has bad magic number(s):
[plasma-nm] [Bug 379848] When there is a lot of WiFi connections, the VPN connection is not shown in the list
https://bugs.kde.org/show_bug.cgi?id=379848 --- Comment #25 from Jonathan Wakely --- Still present in 5.14.5, and of course after setting the QT_LOGGING_RULES environment variable and restarting plasmashell the bug doesn't happen. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 222844] Dragon Player cannot skip to previous track or next track of an audio CD
https://bugs.kde.org/show_bug.cgi?id=222844 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #4 from Jonathan Wakely --- "only plays the first track" is a completely different bug from comment 0. The original bug report says you can't skip tracks. With recent releases, you can (using the Play->Previous and Play->Next menu items, or the , and . keys). So I think the original bug should be marked as resolved. I've opened Bug 409201 for the "playback stops" bug. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 409201] New: Audio CD stops playing at the end of every track
https://bugs.kde.org/show_bug.cgi?id=409201 Bug ID: 409201 Summary: Audio CD stops playing at the end of every track Product: dragonplayer Version: 18.12 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: sit...@kde.org Reporter: zi...@kayari.org CC: myr...@kde.org Target Milestone: --- SUMMARY When playing an Audio CD (either by launching Dragon from the panel's device notification popup, or the "Play Disc" button in Dragon) playback stops at the end of every track. Once playback has stopped, you cannot play the next track even by using the "next" menu item. The only workaround I've found has been to start playback again and then quickly choose "next" (e.g. by hitting space and then . quickly). Instead of playing track 1 and then skipping to track 2, this starts playing track 1 and then skips to the track after the last one played. This makes NO SENSE. For example if I play track 1 and then playback stops, I hit space and . and it plays track 2. Then after that stops I hit space and . and it plays track 3. After that stops I hit space and . and it plays track 4. This is completely counter-intuitive. This bug has been reported in Bug 222844 comment 1 and Bug 222844 comment 3 as well. STEPS TO REPRODUCE 1. Play a CD with more than one track. 2. Wait for the first track to finish. 3. Be sad. OBSERVED RESULT Playback stops at the end of the first track. EXPECTED RESULT Playback should continue on to the next track, until the end of the CD. I asked to play the disc, not the first track of the disc. SOFTWARE/OS VERSIONS Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.1 Kernel Version: 5.1.8-300.fc30.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 62.8 GiB of RAM ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 408644] New: "Show quick buttons that operate on nicknames in nickname context menus" should apply to %o
https://bugs.kde.org/show_bug.cgi?id=408644 Bug ID: 408644 Summary: "Show quick buttons that operate on nicknames in nickname context menus" should apply to %o Product: konversation Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konversation-de...@kde.org Reporter: zi...@kayari.org Target Milestone: --- The %o placeholder for quick buttons operates on a nickname, so should be affected by the "Show quick buttons that operate on nicknames in nickname context menus" checkbox. If I have a quick button using %o and click on my own nickname, it should include the quick button in the context menu. As a motivating use case, I have a quick button with the action "/msg ChanServ op %c %o%n" to make myself op, but I can't use it via the context menu, so I have to have "show quick buttons" checked to show all buttons at all times, wasting UI real estate. I could change the action to use %u instead, but then I have to be careful not to click on the wrong nick or I'll make somebody else an operator. So I'd like %c to make the action available in the context menu. (And if Bug 408643 is implemented %c should cause the action to be in the context menu for the current channel). SOFTWARE/OS VERSIONS Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.1 Kernel Version: 5.1.6-300.fc30.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 62.8 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 408643] New: Add relevant Quick Buttons to channel context menu
https://bugs.kde.org/show_bug.cgi?id=408643 Bug ID: 408643 Summary: Add relevant Quick Buttons to channel context menu Product: konversation Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: konversation-de...@kde.org Reporter: zi...@kayari.org Target Milestone: --- The Quick Buttons settings dialog has a "Show quick buttons that operate on nicknames in nickname context menus" checkbox. It would be nice if quick buttons that operate on channels could be available in channel context menus too, so if I right-click on a channel name (either in the chat window or the channel list on the left) I get the relevant buttons as menu entries. If this is added either a second checkbox would be needed to enable it, or (probably better) use the same checkbox but change the text to say something like "Show quick buttons that operate on nicknames or channels in context menus". SOFTWARE/OS VERSIONS Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.1 Kernel Version: 5.1.6-300.fc30.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 62.8 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 408512] New: Add new printer gives "Failed to get a list of devices: 'Forbidden'"
https://bugs.kde.org/show_bug.cgi?id=408512 Bug ID: 408512 Summary: Add new printer gives "Failed to get a list of devices: 'Forbidden'" Product: print-manager Version: 18.12 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dantt...@gmail.com Reporter: zi...@kayari.org Target Milestone: --- SUMMARY When a non-root user tries to add a new printer the "Add a New Printer" dialog opens and gives an error saying "Failed to get a list of devices: 'Forbidden'". STEPS TO REPRODUCE 1. Open print manager as non-root user. 2. Try to add a printer. 3. Be sad. OBSERVED RESULT Failed to get a list of devices: 'Forbidden' EXPECTED RESULT Prompt for root password, so printers can be detected. SOFTWARE/OS VERSIONS Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.1 Kernel Version: 5.1.6-300.fc30.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 62.8 GiB of RAM Also seen with: Operating System: Fedora 29 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.58.0 Kernel Version: 5.0.9-200.fc29.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 31.0 GiB of RAM ADDITIONAL INFORMATION Clicking "System Preferences" prompts for a root password, but then doesn't do anything. Running "kdesu kcmshell5 printer_manager" manually allows the printer to be configured. The printer manager should do that automatically if it's necessary. -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 377498] Add a new printer and set to to default requires root password multiple times
https://bugs.kde.org/show_bug.cgi?id=377498 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #2 from Jonathan Wakely --- I used to get something similar on Fedora. It probably happens when CUPS is configured securely (i.e. not on Ubuntu). -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 405046] New: Crash while ripping audio from CD
https://bugs.kde.org/show_bug.cgi?id=405046 Bug ID: 405046 Summary: Crash while ripping audio from CD Product: k3b Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@kde.org Reporter: zi...@kayari.org CC: mich...@jabster.pl, tr...@kde.org Target Milestone: --- Application: k3b (18.04.3) Qt Version: 5.11.3 Frameworks Version: 5.54.0 Operating System: Linux 4.20.8-100.fc28.x86_64 x86_64 Distribution: "Fedora release 28 (Twenty Eight)" -- Information about the crash: - What I was doing when the application crashed: Ripping audio from a CDR copy of an audio CD. The output format was variable bitrate MP3. There were five files created, so either it crashed while ripping the fifth or just before starting the sixth. I deleted the fifth track and tried ripping again from track 5 onwards, and it worked OK. I also tried ripping the whole album again (to a different directory) and that also worked. The crash does not seem to be reproducible. -- Backtrace: Application: K3b (k3b), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 28return SYSCALL_CANCEL (nanosleep, requested_time, remaining); [Current thread is 1 (Thread 0x7fda81006e40 (LWP 22129))] Thread 5 (Thread 0x7fda3b1e0700 (LWP 22256)): #0 0x7fda71903dc4 in __GI___pthread_rwlock_unlock (rwlock=0x7fda76ec6c60 ) at pthread_rwlock_unlock.c:32 #1 0x7fda76b3d1b3 in __dcigettext (domainname=0x7fda76c8c5d8 <_libc_intl_domainname> "libc", msgid1=0x7fda76c8ca27 "Bad file descriptor", msgid2=msgid2@entry=0x0, plural=plural@entry=0, n=n@entry=0, category=category@entry=5) at dcigettext.c:572 #2 0x7fda76b3c00f in __GI___dcgettext (domainname=, msgid=, category=category@entry=5) at dcgettext.c:47 #3 0x7fda76b93e3c in __GI___strerror_r (errnum=errnum@entry=9, buf=buf@entry=0x0, buflen=buflen@entry=0) at _strerror.c:71 #4 0x7fda76b93d5f in strerror (errnum=9) at strerror.c:31 #5 0x7fda394590ef in run_mmc_cmd_linux () at /lib64/libcdio.so.18 #6 0x7fda39463563 in mmc_read_sectors () at /lib64/libcdio.so.18 #7 0x7fda3967872c in read_blocks () at /lib64/libcdio_cdda.so.2 #8 0x7fda39678fcd in cdio_cddap_read_timed () at /lib64/libcdio_cdda.so.2 #9 0x7fda39246f0b in cdio_paranoia_read_limited () at /lib64/libcdio_paranoia.so.2 #10 0x7fda80b4c6ad in K3b::CdparanoiaLibData::paranoiaRead(void (*)(long, int), int) () at /lib64/libk3blib.so.7 #11 0x7fda80b4f506 in K3b::CdparanoiaLib::read(int*, unsigned int*, bool) () at /lib64/libk3blib.so.7 #12 0x55f269e14865 in K3b::(anonymous namespace)::AudioCdReader::readData(char*, long long) () #13 0x7fda777a29b7 in QIODevicePrivate::read(char*, long long, bool) () at /lib64/libQt5Core.so.5 #14 0x55f269e2404e in K3b::MassAudioEncodingJob::encodeTrack(int, QString const&, QString const&) () #15 0x55f269e2c370 in K3b::MassAudioEncodingJob::run() () #16 0x7fda80b3d399 in K3b::Thread::run() () at /lib64/libk3blib.so.7 #17 0x7fda776b408b in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #18 0x7fda718fe594 in start_thread (arg=) at pthread_create.c:463 #19 0x7fda76c05f4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7fda52a7d700 (LWP 22132)): #0 0x7fda776a779a in QMutex::lock() () at /lib64/libQt5Core.so.5 #1 0x7fda77893c5f in postEventSourcePrepare(_GSource*, int*) () at /lib64/libQt5Core.so.5 #2 0x7fda6d0d0199 in g_main_context_prepare () at /lib64/libglib-2.0.so.0 #3 0x7fda6d0d0b8b in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #4 0x7fda6d0d0d80 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #5 0x7fda77893d5b in QEventDispatcherGlib::processEvents(QFlags) () at /lib64/libQt5Core.so.5 #6 0x7fda778425bb in QEventLoop::exec(QFlags) () at /lib64/libQt5Core.so.5 #7 0x7fda776aac16 in QThread::exec() () at /lib64/libQt5Core.so.5 #8 0x7fda7bd6ab39 in QDBusConnectionManager::run() () at /lib64/libQt5DBus.so.5 #9 0x7fda776b408b in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #10 0x7fda718fe594 in start_thread (arg=) at pthread_create.c:463 #11 0x7fda76c05f4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fda58ccd700 (LWP 22131)): #0 0x7fda76bfb429 in __GI___poll (fds=0x7fda58cccb38, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fda6948804f in _xcb_conn_wait () at /lib64/libxcb.so.1 #2 0x7fda69489caa in xcb_wait_for_event () at /lib64/libxcb.so.1 #3 0x7fda5ac08f09 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5 #4 0x7fda776b408b in QThreadPrivate::start(void*) () at /lib64/libQt5Core.so.5 #5 0x7fda718fe594 in start_thread (arg=)
[plasma-nm] [Bug 379848] When there is a lot of WiFi connections, the VPN connection is not shown in the list
https://bugs.kde.org/show_bug.cgi?id=379848 --- Comment #24 from Jonathan Wakely --- (In reply to Jan Grulich from comment #20) > It's hard to say why your wireless networks are now shown in the applet. One > thing is that you need to keep the applet opened for a while, because it > scans for the networks, I can wait forever but they never get shown, so that's not it. > other is that NetworkManager might not report > properly that some networks are around, it doesn't mean if they are shown in > nmcli, that they are properly advertised on DBus, which is what we follow. > You can verify it on DBus yourself. > > For the VPN case, it might be also NM's fault. I would suggest enabling > plasma-nm debug using "export QT_LOGGING_RULES=plasma-nm*.debug=true" in a > terminal, from the same terminal restart plasmashell, reproduce your issue > and attach the output here. Yes, I'm trying to do this, but it's not obvious how to reproduce the issue. Sometimes all the connections are shown, sometimes not. I haven't been able to reproduce it at will. I'll attach output when I can. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 379848] When there is a lot of WiFi connections, the VPN connection is not shown in the list
https://bugs.kde.org/show_bug.cgi?id=379848 --- Comment #18 from Jonathan Wakely --- (In reply to Jan Grulich from comment #1) > You have ~20 configured wireless connections you can connect to in your > area? Isn't the VPN connection visible if you scroll down? VPN connections > should be visible right after configured wireless connections, but they > should be visible nevertheless you have there 20, 50 or 100 wireless > connections. This is *definitely* not the case. I have a new laptop with a fresh installation. Only three wifi networks are configured, but 11 different openvpn connections are configured. The applet shows all the available wifi networks (including 16 of my neighbours' wifi networks) and none of my VPNs. If I turn on my phone's wifi hotspot (which is one of my three configured networks) it doesn't appear in the applet's "Available Connections" list. My phone's hotspot is shown by "nmcli wifi device list" so it's definitely found, it's just the applet that doesn't show it. The list of available connections in the applet is just broken. If I kill plasmashell and restart it the applet shows everything as expected: first the connected wifi network, then the available configured network from my phone's hotspot, then the configured VPNs, then the various wifi SSIDs in the area that I've never used. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 379848] When there is a lot of WiFi connections, the VPN connection is not shown in the list
https://bugs.kde.org/show_bug.cgi?id=379848 Jonathan Wakely changed: What|Removed |Added CC||zi...@kayari.org --- Comment #17 from Jonathan Wakely --- (In reply to valdikss from comment #16) > I have this problem, too. But it's not really related to VPN, because > sometimes not all available Wi-Fi networks are listed in the applet, and > they become visible if you switch off the Wi-Fi adapter(!), so I believe > this problem occurs with all elements in the applet, not only with Wi-Fi. Yes, I see this too. Sometimes all the VPN connections are missing and I can only see wifi networks, sometimes *only* the VPN connections are shown, and none of the available wifi networks are shown. When you need to connect to a wifi network and then connect to a VPN it's frustrating when only one or the other is shown. This bug has been a problem for a while, and is still present in 5.14.3 > Anyway, here's a workaround: if the item is missing, you can right-click the > applet, go to settings, select your (VPN) connection, right-click it and > select "connnect". Yes, this works, but what's the point in the widget applet if it doesn't even show my configured wifi/vpn networks which I've used in the past hour? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 332895] Searching for "backend" in system settings has no results
https://bugs.kde.org/show_bug.cgi?id=332895 --- Comment #3 from Jonathan Wakely --- Bug is still present. plasma-workspace-5.12.7-1.fc27.x86_64 kde-runtime-17.08.3-6.fc27.x86_64 phonon-4.9.1-5.fc27.x86_64 -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 324736] Konversation can not reconnect when I enter VPN
https://bugs.kde.org/show_bug.cgi?id=324736 --- Comment #4 from Jonathan Wakely --- I don't see this with Fedora 27 versions; konversation-1.7.5-2.fc27.x86_64 NetworkManager-vpnc-1.2.6-1.fc27.x86_64 vpnc-0.5.3-30.svn550.fc27.x86_64 kdelibs-4.14.36-1.fc27.x86_64 -- You are receiving this mail because: You are watching all bug changes.
[kscd] [Bug 333500] KsCD UI is awful
https://bugs.kde.org/show_bug.cgi?id=333500 --- Comment #8 from Jonathan Wakely --- The application is unchanged, everything mentioned here still applies. -- You are receiving this mail because: You are watching all bug changes.
[kscd] [Bug 132327] kscd doesn't remember sound volume setting
https://bugs.kde.org/show_bug.cgi?id=132327 --- Comment #6 from Jonathan Wakely --- You say "in the latestversion" but is there actually a newer version? If not, obviously the bug will still be present. The bug is still present in kscd-17.08.1-1.fc27.x86_64 (the version in Fedora 27), which says it's: $ kscd --version Qt: 4.8.7 KDE Development Platform: 4.14.36 KsCD: 1.5 -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 267687] Improve failure notices message box text
https://bugs.kde.org/show_bug.cgi?id=267687 Jonathan Wakely changed: What|Removed |Added Status|NEEDSINFO |REPORTED Ever confirmed|1 |0 Resolution|WAITINGFORINFO |--- --- Comment #9 from Jonathan Wakely --- I believe I answered the question in comment 7 so changing to REPORTED. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 357927] Grouping "only when the task manager is full" should group all windows of the same name
https://bugs.kde.org/show_bug.cgi?id=357927 --- Comment #5 from Jonathan Wakely --- Although I no longer see this with plasma-workspace-5.12.6-1.fc27.x86_64 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 357927] Grouping "only when the task manager is full" should group all windows of the same name
https://bugs.kde.org/show_bug.cgi?id=357927 Jonathan Wakely changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #4 from Jonathan Wakely --- The info was provided within 48 hours of being requested. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 383631] What exactly does "Even when an external monitor is connected" do?
https://bugs.kde.org/show_bug.cgi?id=383631 --- Comment #4 from Jonathan Wakely <zi...@kayari.org> --- (In reply to Nate Graham from comment #3) > I think it's pretty clear. Just read the whole thing as a sentence: > > "When Laptop lid closed, , [ ] Even when an > external monitor is connected." But it's not a sentence, it has three capital letters and no punctuation. That's not a sentence. > So when that setting is checked, then the action you configure for what > happens when you close your laptop lid is also carried out when an external > display is plugged in. If that setting is unchecked, then the action is not > carried out. This is useful to, for example, dock your laptop to an external > screen or docking station and close its screen, but not put it to sleep. Yes I know what it's useful for, that's not the problem. The problem is that the effect of the settings is unclear and undocumented. Simply saying "it is clear" does not solve the usability problem, nor add documentation. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 390505] Path in "Share and receive" settings shows %1 as %251
https://bugs.kde.org/show_bug.cgi?id=390505 --- Comment #1 from Jonathan Wakely <zi...@kayari.org> --- %251 is of course the urlencoded representation of %1 but it should be displayed correctly in the unencoded form. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 390505] New: Path in "Share and receive" settings shows %1 as %251
https://bugs.kde.org/show_bug.cgi?id=390505 Bug ID: 390505 Summary: Path in "Share and receive" settings shows %1 as %251 Product: kdeconnect Version: 1.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm Assignee: albertv...@gmail.com Reporter: zi...@kayari.org Target Milestone: --- If you use %1 in the path then it gets replaced with %251 in the dialog box. It seems to work correctly, using the device name in the path, but just displays wrong. I'm using UK localization settings. -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 385945] New: Useless error logging: Nickname "..." has not been added as it is already in the nickname list
https://bugs.kde.org/show_bug.cgi?id=385945 Bug ID: 385945 Summary: Useless error logging: Nickname "..." has not been added as it is already in the nickname list Product: konversation Version: 1.7.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konversation-de...@kde.org Reporter: zi...@kayari.org Target Milestone: --- Several times a day my system logs show errors like: Oct 13 13:50:42 knitphad.home konversation[3283]: Nickname "someuser" has not been added as it is already in the nickname list. This seems to happen on all networks I'm connected to (freenode, oftc, and an internal work one). Sometimes it's even for my own users: Oct 13 12:53:58 knitphad.home konversation[3283]: Nickname "jwakely" has not been added as it is already in the nickname list. Oct 13 12:53:59 knitphad.home konversation[3283]: Nickname "jwakely" has not been added as it is already in the nickname list. Oct 13 12:54:03 knitphad.home konversation[3283]: Nickname "redi" has not been added as it is already in the nickname list. Oct 13 12:54:03 knitphad.home konversation[3283]: Nickname "ChanServ" has not been added as it is already in the nickname list. Oct 13 12:54:11 knitphad.home konversation[3283]: Nickname "jwakely" has not been added as it is already in the nickname list. There is nothing I can do to prevent these, so it's just useless noise in my logs. Why does it need to be logged, without an option to disable it? (See also Bug 333969 but that's been in NEEDINFO for years, despite the info being provided). -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 385945] Useless error logging: Nickname "..." has not been added as it is already in the nickname list
https://bugs.kde.org/show_bug.cgi?id=385945 Jonathan Wakely <zi...@kayari.org> changed: What|Removed |Added Platform|Other |Fedora RPMs -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 333969] addNickname: Nickname "" has not been added as it is already in the nickname list.
https://bugs.kde.org/show_bug.cgi?id=333969 Jonathan Wakely <zi...@kayari.org> changed: What|Removed |Added CC||zi...@kayari.org --- Comment #3 from Jonathan Wakely <zi...@kayari.org> --- If you need to know the network for the message to be useful, maybe the network should be included in the message! Otherwise it's just noise in the logs, and there's nothing the user can do to avoid the errors (I don't control the Freenode IRC servers!) -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 385525] Entering root password doesn't grant root privs, when launched from kicker
https://bugs.kde.org/show_bug.cgi?id=385525 --- Comment #4 from Jonathan Wakely <zi...@kayari.org> --- OK thanks -- You are receiving this mail because: You are watching all bug changes.
