[Akonadi] [Bug 473067] Akondai Server crashes randomly
https://bugs.kde.org/show_bug.cgi?id=473067 P Fudd changed: What|Removed |Added CC||bugs.kde@ch.pkts.ca --- Comment #3 from P Fudd --- For me, it happened when I clicked on a Slack notification. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 473067] Akondai Server crashes randomly
https://bugs.kde.org/show_bug.cgi?id=473067 --- Comment #4 from P Fudd --- I should amend that to say this has happened multiple times before, and always just the moment that I click on a Slack notification box in the bottom-right corner of the screen. Only happens 1% of the time, though. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 468019] New: Crash when clicking on a Slack notification
https://bugs.kde.org/show_bug.cgi?id=468019 Bug ID: 468019 Summary: Crash when clicking on a Slack notification Classification: Frameworks and Libraries Product: Akonadi Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: server Assignee: kdepim-b...@kde.org Reporter: bugs.kde@ch.pkts.ca Target Milestone: --- Application: akonadiserver (5.22.3 (22.12.3)) Qt Version: 5.15.8 Frameworks Version: 5.104.0 Operating System: Linux 6.2.8-200.fc37.x86_64 x86_64 Windowing System: Wayland Distribution: "Fedora release 37 (Thirty Seven)" DrKonqi: 5.27.3 [KCrashBackend] -- Information about the crash: I clicked on a notification, and suddenly I was logged out of everything, and the KDE Crash Handler started up. This has happened a few times today, and I'm now reluctant to click on any notifications. The crash can be reproduced sometimes. -- Backtrace: Application: Akonadi Server (akonadiserver), signal: Segmentation fault [KCrash Handler] #4 std::default_delete::operator() (__ptr=0x111, this=) at /usr/include/c++/12/bits/unique_ptr.h:89 #5 std::unique_ptr >::~unique_ptr (this=, this=) at /usr/include/c++/12/bits/unique_ptr.h:396 #6 std::__new_allocator > >::destroy > > (__p=, this=0x7fffa07abf58) at /usr/include/c++/12/bits/new_allocator.h:181 #7 std::allocator_traits > > >::destroy > > (__p=, __a=...) at /usr/include/c++/12/bits/alloc_traits.h:535 #8 std::vector >, std::allocator > > >::_M_erase (__position=..., this=0x7fffa07abf58) at /usr/include/c++/12/bits/vector.tcc:181 #9 std::vector >, std::allocator > > >::erase (__position=..., this=0x7fffa07abf58) at /usr/include/c++/12/bits/stl_vector.h:1530 #10 Akonadi::Server::AkonadiServer::connectionDisconnected (this=0x7fffa07abed0) at /usr/src/debug/kf5-akonadi-server-22.12.3-1.fc37.x86_64/src/server/akonadi.cpp:234 #11 0x7fb423ec8134 in QObject::event (this=0x7fffa07abed0, e=0x7fb3ac048720) at kernel/qobject.cpp:1347 #12 0x7fb423e9d4cb in doNotify (event=0x7fb3ac048720, receiver=0x7fffa07abed0) at kernel/qcoreapplication.cpp:1154 #13 QCoreApplication::notify (event=, receiver=, this=) at kernel/qcoreapplication.cpp:1140 #14 QCoreApplication::notifyInternal2 (receiver=0x7fffa07abed0, event=0x7fb3ac048720) at kernel/qcoreapplication.cpp:1064 #15 0x7fb423e9d6d2 in QCoreApplication::sendEvent (receiver=, event=) at kernel/qcoreapplication.cpp:1462 #16 0x7fb423ea0854 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x56201ede8020) at kernel/qcoreapplication.cpp:1821 #17 0x7fb423ea0aec in QCoreApplication::sendPostedEvents (receiver=, event_type=) at kernel/qcoreapplication.cpp:1680 #18 0x7fb423eeeb07 in postEventSourceDispatch (s=0x56201edec980) at kernel/qeventdispatcher_glib.cpp:277 #19 0x7fb422118c7f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #20 0x7fb42216f118 in g_main_context_iterate.constprop () from /lib64/libglib-2.0.so.0 #21 0x7fb422115f00 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #22 0x7fb423eee5fa in QEventDispatcherGlib::processEvents (this=0x56201ede9df0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #23 0x7fb423e9bf3a in QEventLoop::exec (this=this@entry=0x7fffa07abd40, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #24 0x7fb423ea4002 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #25 0x56201d472058 in AkApplicationBase::exec (this=0x7fffa07abea0) at /usr/src/debug/kf5-akonadi-server-22.12.3-1.fc37.x86_64/src/shared/akapplication.cpp:107 #26 main (argc=, argv=) at /usr/src/debug/kf5-akonadi-server-22.12.3-1.fc37.x86_64/src/server/main.cpp:65 [Inferior 1 (process 4876) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 468019] Crash when clicking on a Slack notification
https://bugs.kde.org/show_bug.cgi?id=468019 --- Comment #1 from P Fudd --- Additionally, the KDE Crash Handler hung after submitting this bug report. The window says "Submitting bug report..." and has a spinning gear, but this bug has already been submitted. Not sure why it's still, uh, "spinning its gears", but that would be a good thing to fix. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488084] New: Updates are slow; consider incremental updates?
https://bugs.kde.org/show_bug.cgi?id=488084 Bug ID: 488084 Summary: Updates are slow; consider incremental updates? Classification: Applications Product: Discover Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Updates (interactive) Assignee: plasma-b...@kde.org Reporter: bugs.kde@ch.pkts.ca CC: aleix...@kde.org Target Milestone: --- When running Discover, it takes a long time to download the list of all known packages. Wouldn't it be nice if it could download just the incremental changes from last time? SUMMARY Discover is slow to start. STEPS TO REPRODUCE 1. Start Discover 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488084] Updates are slow; consider incremental updates?
https://bugs.kde.org/show_bug.cgi?id=488084 --- Comment #2 from P Fudd --- (In reply to Harald Sitter from comment #1) > Please fill in the template Ok > OBSERVED RESULT Click on "Fetching Updates". See progress bar. Run, progress bar, run. Progress bar doesn't run. Progress bar sits. Eventually progress bar jumps to the end. > EXPECTED RESULT Click on "Fetching Updates" Progress bar flickers by too quickly to perceive. > SOFTWARE/OS VERSIONS > Windows: > macOS: > Linux/KDE Plasma: Fedora Linux 40 > (available in About System) > KDE Plasma Version: 6.0.5 > KDE Frameworks Version: 6.2.0 > Qt Version: 6.7.1 > > ADDITIONAL INFORMATION Information was found in "System Settings" App, "About this System" menu item. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488084] Updates are slow; consider incremental updates?
https://bugs.kde.org/show_bug.cgi?id=488084 --- Comment #3 from P Fudd --- The number of packages that change per day is usually not many, less than 1%. The time required to download the list of new packages to add and old packages to remove from the metadata cache should be proportional to the number of changes. Instead, it appears that the contents of the entire package cache directory /var/cache/dnf/ is discarded and redownloaded if the age of the cache is older than metadata_expire in /etc/dnf/dnf.conf, which defaults to 48 hours. I realize that the package cache directory contains metadata from all of the repositories configured in /etc/yum.repos.d, dependency calculations can be drastically altered if there are changes in any of the repositories, and getting all repositories to support some modified protocol would be like herding cats. However, most of the extra repositories added to a system are tiny compared to the repositories for the OS, they don't affect the overall time significantly. There are several possible optimizations: * Calculate a checksum of the repository metadata on the server, and publish it via DNS. A single DNS query could then tell you if you're up to date. * Record changes to the repository metadata as a transaction log stored in an ever-growing file that is rotated as needed; publish the current name and size of the file via DNS, or implement something like curl's `--continue-at` feature for resuming interrupted downloads. * Try using rsync delta-transfer algorithm for updating the metadata; it handles inserts and deletions in the middle of binary files easily. The current method of downloading the entire repository's metadata is wasting bandwidth and money. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488084] Updates are slow; consider incremental updates?
https://bugs.kde.org/show_bug.cgi?id=488084 --- Comment #5 from P Fudd --- Is there any way to tweak the progress bar so it moves at a constant rate and reaches 100% at the right moment? Basically I want to know if I have time to grab a coffee or not. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 488084] Updates are slow; consider incremental updates?
https://bugs.kde.org/show_bug.cgi?id=488084 --- Comment #7 from P Fudd --- Where's the best place to file a bug with Fedora? There's so many to choose from. :-/ -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 448280] New: RFE: Plasma discover needs better progress indicators
https://bugs.kde.org/show_bug.cgi?id=448280 Bug ID: 448280 Summary: RFE: Plasma discover needs better progress indicators Product: Discover Version: 5.23.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: discover Assignee: lei...@leinir.dk Reporter: bugs.kde@ch.pkts.ca CC: aleix...@kde.org Target Milestone: --- Created attachment 145338 --> https://bugs.kde.org/attachment.cgi?id=145338&action=edit Screenshot of app after clicking 'install' and waiting a while. SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Hi; In Discover, it's not obvious when large updates are being installed; after clicking, the display appears frozen. STEPS TO REPRODUCE 1. Wait for a system update containing ~200 package updates 2. Select the update, click 'update' 3. Wait OBSERVED RESULT The app appears to hang for minutes. There's an icon at the bottom that looks like it might be for cancelling the update, but it's hard to say for sure. EXPECTED RESULT * There should be some signs that work is being done and whether it can be safely interrupted. * It would be best if there was a progress bar with an ETA calculation showing when the user will be needed to click on something (system reboot?) or process will finish. * Second best is just a progress bar (calibrated by time, not 'number of packages') * Third best is a 'busy' indicator SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 35 (available in About System) KDE Plasma Version: 5.23.4-1 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Screenshot attached. Also filed as https://bugzilla.redhat.com/show_bug.cgi?id=2039471 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 454713] New: Displaying updates is slow
https://bugs.kde.org/show_bug.cgi?id=454713 Bug ID: 454713 Summary: Displaying updates is slow Product: Discover Version: 5.24.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: lei...@leinir.dk Reporter: bugs.kde@ch.pkts.ca CC: aleix...@kde.org Target Milestone: --- SUMMARY As a user, when I see the "Security Updates Available" icon come on, I want to click on the icon, see what they are, and install them. As it is now, when I click on the icon, the Discover app pauses for a couple of minutes to fetch updates before I can see what they are. STEPS TO REPRODUCE 1. Click on the "Security Updates Available" icon. OBSERVED RESULT * The "Updates -- Discover" window pops up and shows "Fetching Updates..." with a progress bar that seems to instantly jump to 96.32% and stay there for minutes at a time before eventually showing the available update(s). EXPECTED RESULT * Since the system already knows there are updates available, it should be able to display them without having to wait for another update. * If the "Security Updates Available" icon has been on for a while (days?), it could refresh the list of updates in the background. * Progress bars should show progress. Ideally they should move constantly and smoothly, and finally reach 100% when user input is needed. They're even better if they are displayed with an estimated time of completion, so the user could decide if they had enough time to grab a coffee or similar. * If a progress bar freezes for any significant length of time, it's taken as a sign that the program has crashed and needs to be restarted. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 35 KDE Plasma Version: 5.24.4 KDE Frameworks Version: ? Qt Version: ? ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 451709] New: Dolphin can't connect to my Android 11 phone with USB until I restart Dolphin
https://bugs.kde.org/show_bug.cgi?id=451709 Bug ID: 451709 Summary: Dolphin can't connect to my Android 11 phone with USB until I restart Dolphin Product: dolphin Version: 21.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: bugs.kde@ch.pkts.ca CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Dolphin can't connect to my Android phone unless I restart dolphin. STEPS TO REPRODUCE 1. Attach phone 2. Select 'file transfer' and 'controlled by this device' on the phone 3. Click the usb icon on the task bar and select 'Mount and open' OBSERVED RESULT Dolphin reports this error message: ``` No storage media found. Make sure that the device is unlocked and that you have MTP enabled in your USB connection preferences. ``` Killing dolphin and starting it again makes it suddenly work. EXPECTED RESULT It should "just work" the first time. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 35 Server Edition KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Android version: 11 on a Pixel 2 XL Got the solution from https://www.reddit.com/r/kde/comments/p6pp6z/cant_connect_samsung_android_in_dolphin/ -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 466290] New: When the dock icon indicates there are updates available, it shouldn't take 5 minutes to find out what they are.
https://bugs.kde.org/show_bug.cgi?id=466290 Bug ID: 466290 Summary: When the dock icon indicates there are updates available, it shouldn't take 5 minutes to find out what they are. Classification: Applications Product: Discover Version: 5.27.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: bugs.kde@ch.pkts.ca CC: aleix...@kde.org Target Milestone: --- SUMMARY I updated my system to Fedora 37 last night. This morning I see the "Updates Available" icon on my dash. I click on it, and Discover starts up, puts up a "Fetching updates..." message and a progress bar, and then proceeds to take several minutes to load the list of updates. It would be nice if it could download the list of updates *before* trying to gain my attention. This irritation is further compounded by the fact that the progress bar travels fast until it reaches about 95%, and then appears to hang (although I'm sure it'll finish... eventually). And under the hood, the icing on the cake is that the list of updates being downloaded is likely 99% similar to the list it had from the day before, and yet it's downloading the whole thing again. If it could be changed to download and apply a patch to the list of updates, that would speed things up. If you could do a DNS lookup of a TXT record (e.g. update-status.kde.org) that returned a signed serial number and date, then the client wouldn't even have to connect to the repository to discover that nothing's changed since the last time they checked. If the signature is bad or the date is old, fall back to checking the repository. STEPS TO REPRODUCE 1. Install Fedora (or maybe just KDE) 2. Wait for the "Updates available" icon to appear (hours? days?) 3. Click on the icon OBSERVED RESULT "Hurry up and wait" EXPECTED RESULT "Skinner Box" SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora Linux 37 - Kernel 6.1.12-200.fc37.x86_64 (64-bit) (available in About System) KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[ksshaskpass] [Bug 343562] Cannot remove a wrong user/password after it was stored
https://bugs.kde.org/show_bug.cgi?id=343562 P Fudd changed: What|Removed |Added CC||kde@ch.pkts.ca --- Comment #6 from P Fudd --- Reported downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1702884 This is still happening in 2019 with Fedora 29. Ksshaskpass still isn't fixed, 6 years after this was reported. The first time I tried to do 'git push' to my very first Github repository, it asked for my username using a password field (with '*' masking), and the wording was confusing enough that I entered my password instead. Now it won't let me change the username, and instead prints "Password for 'https://@github.com':" I've searched all of my files and can't find the password string anywhere, I guess it's encrypted in KWallet? Thanks -- You are receiving this mail because: You are watching all bug changes.
[ksshaskpass] [Bug 343562] Cannot remove a wrong user/password after it was stored
https://bugs.kde.org/show_bug.cgi?id=343562 --- Comment #7 from P Fudd --- Yes, that was it: to fix, run 'kwalletmanager5', go to the 'ksshaskpass' folder, and there will be one 'password' for 'https://github.com' containing the GitHub username (e.g. usern...@yourdomain.com), and another 'password' for 'https://usern...@yourdomain.com@github.com' containing the actual password. I edited the contents of the first 'password' to replace my password with my username, deleted the second 'password', and everything worked right again. The program still needs to be fixed, though. :-) -- You are receiving this mail because: You are watching all bug changes.
[ksshaskpass] [Bug 343562] Cannot remove a wrong user/password after it was stored
https://bugs.kde.org/show_bug.cgi?id=343562 --- Comment #8 from P Fudd --- Ideally, the first page presented by ksshaskpass should offer a list of possible usernames to use for the site you're attempting to connect to, or let you create, update or delete a username. It should also allow you to change or delete the password associated with the username. It's not clear that it's storing things in the best possible way inside kwallet. It looks like I'm describing an identity management service; has this wheel been invented before, and can we copy it? -- You are receiving this mail because: You are watching all bug changes.
