[kdeconnect] [Bug 486356] New: can't lock phone from pc
https://bugs.kde.org/show_bug.cgi?id=486356 Bug ID: 486356 Summary: can't lock phone from pc Classification: Applications Product: kdeconnect Version: 24.02.2 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: windows-application Assignee: piyushaggarwal...@gmail.com Reporter: martinjohnr...@gmail.com Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Can't lock phone from PC STEPS TO REPRODUCE 1. click on 'lock' 2. 3. OBSERVED RESULT nothing happens EXPECTED RESULT phone should lock SOFTWARE/OS VERSIONS Windows: 11 Pro 23H2 22631.3527 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Android 13 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 473444] New: Latte Dock crashes when opening Virtualbox
https://bugs.kde.org/show_bug.cgi?id=473444 Bug ID: 473444 Summary: Latte Dock crashes when opening Virtualbox Classification: Plasma Product: lattedock Version: unspecified Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: minorsec...@gmail.com Target Milestone: --- Application: latte-dock (0.10.77) Qt Version: 5.15.10 Frameworks Version: 5.108.0 Operating System: Linux 6.4.9-1-default x86_64 Windowing System: X11 Distribution: openSUSE Tumbleweed DrKonqi: 5.27.7 [KCrashBackend] -- Information about the crash: When opening the main Virtualbox window, latte dock crashes sometimes. The crash can be reproduced sometimes. -- Backtrace: Application: Latte Dock (latte-dock), signal: Segmentation fault [KCrash Handler] #4 0x7f932c5c3ac0 in QSGTexture::setFiltering(QSGTexture::Filtering) () from /lib64/libQt5Quick.so.5 #5 0x7f932c5f1d7b in QSGOpaqueTextureMaterialShader::updateState(QSGMaterialShader::RenderState const&, QSGMaterial*, QSGMaterial*) () from /lib64/libQt5Quick.so.5 #6 0x7f932c5da96d in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () from /lib64/libQt5Quick.so.5 #7 0x7f932c5dfd35 in QSGBatchRenderer::Renderer::renderBatches() () from /lib64/libQt5Quick.so.5 #8 0x7f932c5e0826 in QSGBatchRenderer::Renderer::render() () from /lib64/libQt5Quick.so.5 #9 0x7f932c5c8400 in QSGRenderer::renderScene(QSGBindable const&) () from /lib64/libQt5Quick.so.5 #10 0x7f932c6329b3 in QSGOpenGLLayer::grab() () from /lib64/libQt5Quick.so.5 #11 0x7f932c632fc5 in QSGOpenGLLayer::updateTexture() () from /lib64/libQt5Quick.so.5 #12 0x7f932c79e016 in QQuickOpenGLShaderEffectMaterial::updateTextures() const () from /lib64/libQt5Quick.so.5 #13 0x7f932c5c8b95 in QSGRenderer::preprocess() () from /lib64/libQt5Quick.so.5 #14 0x7f932c5c83c7 in QSGRenderer::renderScene(QSGBindable const&) () from /lib64/libQt5Quick.so.5 #15 0x7f932c6329b3 in QSGOpenGLLayer::grab() () from /lib64/libQt5Quick.so.5 #16 0x7f932c632fc5 in QSGOpenGLLayer::updateTexture() () from /lib64/libQt5Quick.so.5 #17 0x7f932c79e016 in QQuickOpenGLShaderEffectMaterial::updateTextures() const () from /lib64/libQt5Quick.so.5 #18 0x7f932c5c8b95 in QSGRenderer::preprocess() () from /lib64/libQt5Quick.so.5 #19 0x7f932c5c83c7 in QSGRenderer::renderScene(QSGBindable const&) () from /lib64/libQt5Quick.so.5 #20 0x7f932c5c88b3 in QSGRenderer::renderScene(unsigned int) () from /lib64/libQt5Quick.so.5 #21 0x7f932c62aa93 in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /lib64/libQt5Quick.so.5 #22 0x7f932c69a389 in QQuickWindowPrivate::renderSceneGraph(QSize const&, QSize const&) () from /lib64/libQt5Quick.so.5 #23 0x7f932c616561 in ?? () from /lib64/libQt5Quick.so.5 #24 0x7f932c6a9075 in QQuickWindow::event(QEvent*) () from /lib64/libQt5Quick.so.5 #25 0x7f932b3a519e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #26 0x7f932a4ed568 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #27 0x7f932ab6c0d3 in QPlatformWindow::windowEvent(QEvent*) () from /lib64/libQt5Gui.so.5 #28 0x7f932b3ac4dc in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #29 0x7f932a4ed568 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #30 0x7f932a545899 in QTimerInfoList::activateTimers() () from /lib64/libQt5Core.so.5 #31 0x7f932a546144 in ?? () from /lib64/libQt5Core.so.5 #32 0x7f93289169b8 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #33 0x7f9328916dc8 in ?? () from /lib64/libglib-2.0.so.0 #34 0x7f9328916e5c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #35 0x7f932a5464a6 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #36 0x7f932a4ebffb in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #37 0x7f932a4f4490 in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #38 0x55b09dfc8c43 in ?? () #39 0x7f9329a281f0 in __libc_start_call_main () from /lib64/libc.so.6 #40 0x7f9329a282b9 in __libc_start_main_impl () from /lib64/libc.so.6 #41 0x55b09dfd1d35 in ?? () [Inferior 1 (process 2363) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 472978] New: Empty Trash not updating correctly
https://bugs.kde.org/show_bug.cgi?id=472978 Bug ID: 472978 Summary: Empty Trash not updating correctly Classification: Applications Product: dolphin Version: 23.04.3 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: minorsec...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY *** When clicking Empty Trash, the files are removed from the FS, but Dolphin still shows them until you close Dolphin and reopen. Furthermore, some items remain. *** STEPS TO REPRODUCE 1. Delete something 2. Open Dolphin and go to trash 3. Empty Trash OBSERVED RESULT Everything remains. Close Dolphin, reopen, and you'll see that almost everything is gone but a couple items remain. EXPECTED RESULT After clicking Empty Trash, everything should disappear from view as they are deleted. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Rolling Distro (available in About System) KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION In .local/share/Trash, both the files and info directories are empty after removing trash but items still appear in Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468264] feature request: resource bundle deletion and user feedback
https://bugs.kde.org/show_bug.cgi?id=468264 --- Comment #1 from Bob Ross --- > 2. I don't find a button to delete a complete bundle. It could be handy, > after selecting a bundle using the 'local resources' combobox, to have a > button 'delete complete bundle' to remove it completely. Maybe it's better to add a 'delete bundle' button in the 'manage resource libraries' window, next to the activate/deactivate button. In this way activating and deleting bundles is all in the same place -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468310] New: open resources folder button not working
https://bugs.kde.org/show_bug.cgi?id=468310 Bug ID: 468310 Summary: open resources folder button not working Classification: Applications Product: krita Version: 5.1.5 Platform: Android OS: Android 12.x Status: REPORTED Severity: normal Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: bobrosspaint...@protonmail.com Target Milestone: --- SUMMARY The 'open resources folder' button is not working. STEPS TO REPRODUCE 1. Go to 'settings' - 'manage resources' 2. The 'open resources folder' button is not working OBSERVED RESULT open resources folder button not working EXPECTED RESULT open resources folder button should work Remember: there are no bugs, only happy little accidents! Bob Ross The joy of painting -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468297] workspace isn't overwritten when using same name
https://bugs.kde.org/show_bug.cgi?id=468297 Bob Ross changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #1 from Bob Ross --- This bug can be closed, because I did something wrong. It's working fine. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468297] New: workspace isn't overwritten when using same name
https://bugs.kde.org/show_bug.cgi?id=468297 Bug ID: 468297 Summary: workspace isn't overwritten when using same name Classification: Applications Product: krita Version: 5.1.5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: bobrosspaint...@protonmail.com Target Milestone: --- Hello friends, SUMMARY When saving a workspace using the same name as a previously created workspace, Krita asks if you want to overwrite the workspace, but this doesn't seem to happen. After loading the overwritten workspace, it's still the old one. STEPS TO REPRODUCE 1. Create a workspace, give it a name "test" 2. Change the workspace, overwrite it using same name "test" 3. Load the workspace and see nothing has changed (it's not overwritten) OBSERVED RESULT The workspace is not overwritten when using the same name EXPECTED RESULT The workspace should be overwritten when using the same name Remember: we don't make bugs, only happy little accidents! Bob Ross The joy of painting -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468264] New: feature request: resource bundle deletion and user feedback
https://bugs.kde.org/show_bug.cgi?id=468264 Bug ID: 468264 Summary: feature request: resource bundle deletion and user feedback Classification: Applications Product: krita Version: 5.1.5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: bobrosspaint...@protonmail.com Target Milestone: --- Hello friends SUMMARY In 'settings' - 'manage resources': there is a button 'import resources' to install a bundle. I like to request 2 things to make this window better for the user. 1. When a bundle is installed by using the 'import resources' button , there is no feedback to the user the installation is finished (also no progress bar of the installation process in the UI). I would like to request a message box saying 'installation finished successfully' and/or a progress bar during installation (big bundle can take some time). 2. I don't find a button to delete a complete bundle. It could be handy, after selecting a bundle using the 'local resources' combobox, to have a button 'delete complete bundle' to remove it completely. Remember: there are no bugs, only happy little accidents! Bob Ross The joy of painting -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468263] New: bundle brushes not all loaded after installing
https://bugs.kde.org/show_bug.cgi?id=468263 Bug ID: 468263 Summary: bundle brushes not all loaded after installing Classification: Applications Product: krita Version: 5.1.5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: bobrosspaint...@protonmail.com Target Milestone: --- Hello friends SUMMARY After installing this brush bundle in krita 5.1.5 https://github.com/Rakurri/rakurri-brush-set-for-krita/releases/tag/V2.1 Only 4 brushes where shown in krita. I had to close and open krita again to make them all appear in the docker. I think something is not refreshed after installing a bundle. STEPS TO REPRODUCE 1. Install https://github.com/Rakurri/rakurri-brush-set-for-krita/releases/tag/V2.1 2. See only 4 brushes are in the docker 3. Close and restart krita to see them all appear OBSERVED RESULT Not all brushes are shown EXPECTED RESULT All brushes should be shown without restarting krita Remember: there are no bugs, only happy little accidents! Bob Ross The joy of painting -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while the system is updated
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #11 from Ross Cannizzaro --- (In reply to Wyatt Childers from comment #10) > @Ross and @yiz...@kulodgei.com are you both using btrfs as well, or > different file systems? > > I've notice an increase in "wonky" IO scheduler behavior lately in general, > use btrfs almost exclusively, and wonder if that's related. I am using BTRFS. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Kwin freezes while flatpaks are updated
https://bugs.kde.org/show_bug.cgi?id=463353 Ross Cannizzaro changed: What|Removed |Added CC||ross.cannizz...@gmail.com --- Comment #1 from Ross Cannizzaro --- I am also experiencing the same issue. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 (Kinoite) KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.14-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12x AMD Ryzen 5 1600 Six-Core Processor Memory: 15.1GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Micro-Star International Co., Ltd. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #4 from Ross Boylan --- By the way, continuing on your remarks that kpmcore isn't a regular library, when I went to file a bug I noticed there was no entry for it under KDE Frameworks; there is one for partitionmanager under Applications. This might also be related to why no API documentation appears on the web. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #3 from Ross Boylan --- Thanks for the pointer. That was the last bit I needed, and I can now compile and run. Qt structures are impenetrable in the debugger, but that's a separate issue. I'm installing kdevelop and qtcreator now; I think both have helpers for debugging. So my final tips to get running were 1. Use CoreBackendManager::self()->backend() to get the backend. 2. The app requires the Qt event loop, which can be started with QCoreApplication app(argc, argv); 3. Those require including and -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #1 from Ross Boylan --- Also, I would expect there to be some master include file, e.g., `#include ` that would get the whole library. It is unclear if such a file exists, or what it's called. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] New: Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 Bug ID: 462611 Summary: Info on how to get started using KPMcore library is incomplete Classification: Applications Product: partitionmanager Version: Git Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY Please provide enough information in README.md to use the library. DETAILS The Initialization section provides some scraps of code, but not a complete working example. I have so far been unable to make the transition. Here are the issues I've encountered: 1. `Device` not declared in this scope. Solution: add `#include ` 2. `backend` not declared in this scope. I've tried a lot of variations to get it; none have worked. `CoreBackendManager.h` says ``` * This is basically a singleton class to give the application access to the currently * selected backend and also to manage the available backend plugins. ``` But my latest variation, `QList devices = CoreBackendManager()->backend()->scanDevices(false);`, yields ``` build] ../test.cpp: In function ‘int main(int, char**)’: [build] ../test.cpp:32:49: error: ‘CoreBackendManager::CoreBackendManager()’ is private within this context [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); [build] | ^ [build] In file included from ../test.cpp:6: [build] /usr/include/kpmcore/backend/corebackendmanager.h:34:5: note: declared private here [build]34 | CoreBackendManager(); [build] | ^~ [build] ../test.cpp:32:49: error: ‘CoreBackendManager::~CoreBackendManager()’ is private within this context [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); [build] | ^ [build] In file included from ../test.cpp:6: [build] /usr/include/kpmcore/backend/corebackendmanager.h:35:5: note: declared private here [build]35 | ~CoreBackendManager(); [build] | ^ [build] ../test.cpp:32:50: error: base operand of ‘->’ has non-pointer type ‘CoreBackendManager’ [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); ``` This code gets called after the suggested `initKPMcore`, though since this is a compile-time error that may not matter. CMAKE PROBLEMS I had lots of trouble getting the test project to find the right include files with `CMake`, mostly because I overlooked the steps you did document in the `README`. But one part of the instructions seemed odd, the requirement to explicitly add the include path. The [tutorial](https://community.kde.org/Guidelines_and_HOWTOs/CMake/Frameworks) says that adding an explicit link target will automatically take care of includes: "This [that is the target_link_libraries declaration] will not only link the tutorial target against the KArchive library, it will set up the include paths properly as well." Is there a reason that pattern doesn't apply here (I tried; the link declaration alone definitely is insufficient)? VERSIONS My test code is running against the development libraries packaged for Debian bullseye, libkpmcore1020.12.3-2, though I've mostly been looking at the source from git. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462087] New: What API documentation?
https://bugs.kde.org/show_bug.cgi?id=462087 Bug ID: 462087 Summary: What API documentation? Classification: Applications Product: partitionmanager Version: Git Platform: Other OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY *** https://invent.kde.org/system/kpmcore/-/blob/master/README.md says, under the "Using KPMCore" section > Most of the usage information on KPMcore is included in the API documentation Where is that API documentation? *** EXPECTED RESULT I expected that the reference would include a link to a place I could view that documentation online. Absent a link, I figured I could find such documentation with a web search; I've searched, but haven't turned up anything. Absent any of that, I thought there might be instructions for how to build such documentation from the source code. I haven't found that either. I expected that "API Documentation" referred to something other than reading the header files. ADDITIONAL INFORMATION I'm not too familiar with building KDE software or its documentation system; perhaps at least my last place fallback (build it myself) is something that would be apparent if I were. I did spend a little time looking for such information and didn't find it. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 455341] [plasma 5.25 / latte v0.10.x] moving an application makes it unclickable
https://bugs.kde.org/show_bug.cgi?id=455341 Ross Wardrup changed: What|Removed |Added CC||minorsec...@gmail.com --- Comment #9 from Ross Wardrup --- I'm also facing this. KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 459901] Kalarm crashes after boot and defer
https://bugs.kde.org/show_bug.cgi?id=459901 --- Comment #3 from Ross --- Update - after booting the computer today I waited about 30 seconds before clicking the defer button. No crash. I am wondering if the alarm popup appears before Kalarm has fully loaded, and if clicking "defer" during that loading time will cause the crash? -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 459901] Kalarm crashes after boot and defer
https://bugs.kde.org/show_bug.cgi?id=459901 --- Comment #2 from Ross --- Created attachment 152563 --> https://bugs.kde.org/attachment.cgi?id=152563=edit kalarmrc file >Also, can you confirm whether there is a KAlarm main window visible when the >crash occurs. If not, is KAlarm running in the system tray? The main window is not visible, only the individual alarms. Kalarm is running in the system tray. It has been set to start at logon. -- You are receiving this mail because: You are watching all bug changes.
[kalarm] [Bug 459901] New: Kalarm crashes after boot and defer
https://bugs.kde.org/show_bug.cgi?id=459901 Bug ID: 459901 Summary: Kalarm crashes after boot and defer Classification: Applications Product: kalarm Version: unspecified Platform: OpenSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: djar...@kde.org Reporter: r...@rguitar.ca Target Milestone: --- Application: kalarm (3.5.1 (KDE Gear 22.08.1)) Qt Version: 5.15.6 Frameworks Version: 5.98.0 Operating System: Linux 5.19.10-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.25.5 [KCrashBackend] -- Information about the crash: When booting the computer and logging into my account, if there is a kalarm alert and I click the defer button, kalarm will crash every time. Only on booting. Waking from sleep does not cause the crash. The reporter is unsure if this crash is reproducible. -- Backtrace: Application: KAlarm (kalarm), signal: Segmentation fault [KCrash Handler] #4 0x556eb1b92169 in std::__atomic_base::load (__m=, this=) at /usr/include/c++/12/bits/atomic_base.h:488 #5 QAtomicOps::loadRelaxed (_q_value=..., _q_value=...) at /usr/include/qt5/QtCore/qatomic_cxx11.h:239 #6 QBasicAtomicInteger::loadRelaxed (this=) at /usr/include/qt5/QtCore/qbasicatomic.h:107 #7 QtPrivate::RefCount::isShared (this=) at /usr/include/qt5/QtCore/qrefcount.h:101 #8 QMap::detach (this=) at /usr/include/qt5/QtCore/qmap.h:361 #9 QMap::operator[] (akey=, this=) at /usr/include/qt5/QtCore/qmap.h:680 #10 MainWindow::showDeferAlarmDlg (this=0x0, data=0x556eb3fd7360) at /usr/src/debug/kalarm-22.08.1-1.1.x86_64/src/mainwindow.cpp:1773 #11 0x556eb1baa5b8 in MessageDisplay::executeDeferDlg (data=0x556eb3fd7360) at /usr/src/debug/kalarm-22.08.1-1.1.x86_64/src/messagedisplay.cpp:228 #12 MessageWindow::slotDefer (this=0x556eb3df90c0) at /usr/src/debug/kalarm-22.08.1-1.1.x86_64/src/messagewindow.cpp:1186 #13 0x7f68d459b05d in ?? () from /lib64/libQt5Core.so.5 #14 0x7f68d5604092 in QAbstractButton::clicked(bool) () from /lib64/libQt5Widgets.so.5 #15 0x7f68d56042fa in ?? () from /lib64/libQt5Widgets.so.5 #16 0x7f68d5605b98 in ?? () from /lib64/libQt5Widgets.so.5 #17 0x7f68d5605db7 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /lib64/libQt5Widgets.so.5 #18 0x7f68d5553c48 in QWidget::event(QEvent*) () from /lib64/libQt5Widgets.so.5 #19 0x7f68d55123fe in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #20 0x7f68d551a922 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #21 0x7f68d4564178 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #22 0x7f68d5518a9e in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool, bool) () from /lib64/libQt5Widgets.so.5 #23 0x7f68d556ca68 in ?? () from /lib64/libQt5Widgets.so.5 #24 0x7f68d556ffc0 in ?? () from /lib64/libQt5Widgets.so.5 #25 0x7f68d55123fe in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #26 0x7f68d4564178 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #27 0x7f68d4c6fa3d in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /lib64/libQt5Gui.so.5 #28 0x7f68d4c4338c in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib64/libQt5Gui.so.5 #29 0x7f68cf3f60ea in ?? () from /lib64/libQt5XcbQpa.so.5 #30 0x7f68d239aa50 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #31 0x7f68d239ae08 in ?? () from /lib64/libglib-2.0.so.0 #32 0x7f68d239ae9c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #33 0x7f68d45bb806 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #34 0x7f68d4562beb in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #35 0x7f68d456ad56 in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #36 0x556eb1af2986 in main (argc=, argv=) at /usr/src/debug/kalarm-22.08.1-1.1.x86_64/src/main.cpp:75 [Inferior 1 (process 2245) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 445158] Yakuake does not open on the screen where the mouse pointer is
https://bugs.kde.org/show_bug.cgi?id=445158 Ross changed: What|Removed |Added CC||rossporter...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 457202] New: crash on open
https://bugs.kde.org/show_bug.cgi?id=457202 Bug ID: 457202 Summary: crash on open Product: Discover Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: wzyh...@gmail.com CC: aleix...@kde.org Target Milestone: --- Application: plasma-discover (5.25.80) Qt Version: 5.15.5 Frameworks Version: 5.97.0 Operating System: Linux 5.18.11-1-default x86_64 Windowing System: Wayland Distribution: "openSUSE Tumbleweed" DrKonqi: 5.25.80 [KCrashBackend] -- Information about the crash: when I click discover, it will crash. every time, cannot start discover The crash can be reproduced every time. -- Backtrace: Application: Discover (plasma-discover), signal: Segmentation fault [KCrash Handler] #4 0x7f339f868010 in QQmlType::QQmlType(QQmlType const&) () from /lib64/libQt5Qml.so.5 #5 0x7f339f8cdad5 in ?? () from /lib64/libQt5Qml.so.5 #6 0x7f339f8d08a0 in ?? () from /lib64/libQt5Qml.so.5 #7 0x7f339f8d0ab9 in ?? () from /lib64/libQt5Qml.so.5 #8 0x7f339f8d191d in ?? () from /lib64/libQt5Qml.so.5 #9 0x7f339f8cc2fd in ?? () from /lib64/libQt5Qml.so.5 #10 0x7f339f81dc15 in ?? () from /lib64/libQt5Qml.so.5 #11 0x7f339f823c03 in ?? () from /lib64/libQt5Qml.so.5 #12 0x7f339f811a25 in QQmlDataBlob::tryDone() () from /lib64/libQt5Qml.so.5 #13 0x7f339f870b6c in QQmlTypeLoader::setData(QQmlDataBlob*, QQmlDataBlob::SourceCodeData const&) () from /lib64/libQt5Qml.so.5 #14 0x7f339f871272 in QQmlTypeLoader::setData(QQmlDataBlob*, QString const&) () from /lib64/libQt5Qml.so.5 #15 0x7f339f8725ef in QQmlTypeLoader::loadThread(QQmlDataBlob*) () from /lib64/libQt5Qml.so.5 #16 0x7f339f872a5c in QQmlTypeLoader::load(QQmlDataBlob*, QQmlTypeLoader::Mode) () from /lib64/libQt5Qml.so.5 #17 0x7f339f873300 in QQmlTypeLoader::getType(QUrl const&, QQmlTypeLoader::Mode) () from /lib64/libQt5Qml.so.5 #18 0x7f339f822ccc in ?? () from /lib64/libQt5Qml.so.5 #19 0x7f339f8258e0 in ?? () from /lib64/libQt5Qml.so.5 #20 0x7f339f870e09 in QQmlTypeLoader::setData(QQmlDataBlob*, QQmlDataBlob::SourceCodeData const&) () from /lib64/libQt5Qml.so.5 #21 0x7f339f871272 in QQmlTypeLoader::setData(QQmlDataBlob*, QString const&) () from /lib64/libQt5Qml.so.5 #22 0x7f339f8725ef in QQmlTypeLoader::loadThread(QQmlDataBlob*) () from /lib64/libQt5Qml.so.5 #23 0x7f339f82d4dd in ?? () from /lib64/libQt5Qml.so.5 #24 0x7f339f8ea79c in ?? () from /lib64/libQt5Qml.so.5 #25 0x7f339f8eaf02 in ?? () from /lib64/libQt5Qml.so.5 #26 0x7f339fdf541e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #27 0x7f339eba0fb8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #28 0x7f339eba3f51 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5 #29 0x7f339ebf8c53 in ?? () from /lib64/libQt5Core.so.5 #30 0x7f339d1fdea0 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #31 0x7f339d1fe258 in ?? () from /lib64/libglib-2.0.so.0 #32 0x7f339d1fe2ec in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #33 0x7f339ebf8456 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #34 0x7f339eb9fa2b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #35 0x7f339e9b9c77 in QThread::exec() () from /lib64/libQt5Core.so.5 #36 0x7f339f8ea455 in ?? () from /lib64/libQt5Qml.so.5 #37 0x7f339e9bae6d in ?? () from /lib64/libQt5Core.so.5 #38 0x7f339e511777 in start_thread () from /lib64/libc.so.6 #39 0x7f339e59bc70 in clone3 () from /lib64/libc.so.6 Thread 4 (Thread 0x7f3393fff640 (LWP 2660) "QDBusConnection"): #1 0x7f339d1fd507 in g_main_context_prepare () from /lib64/libglib-2.0.so.0 #2 0x7f339d1fe0fb in ?? () from /lib64/libglib-2.0.so.0 #3 0x7f339d1fe2ec in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #4 0x7f339ebf846e in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #5 0x7f339eb9fa2b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #6 0x7f339e9b9c77 in QThread::exec() () from /lib64/libQt5Core.so.5 #7 0x7f339fb06277 in ?? () from /lib64/libQt5DBus.so.5 #8 0x7f339e9bae6d in ?? () from /lib64/libQt5Core.so.5 #9 0x7f339e511777 in start_thread () from /lib64/libc.so.6 #10 0x7f339e59bc70 in clone3 () from /lib64/libc.so.6 Thread 3 (Thread 0x7f3398983640 (LWP 2659) "WaylandEventThr"): #1 0x7f3399ceebb6 in ?? () from /lib64/libQt5WaylandClient.so.5 #2 0x7f339e9bae6d in ?? () from /lib64/libQt5Core.so.5 #3 0x7f339e511777 in start_thread () from /lib64/libc.so.6 #4 0x7f339e59bc70 in clone3 () from
[ktorrent] [Bug 456666] KTorrent crashes with "mmap failed : Cannot allocate memory" even with plenty of free memory
https://bugs.kde.org/show_bug.cgi?id=45 Chris Ross changed: What|Removed |Added CC||kdeb1...@tebibyte.org --- Comment #1 from Chris Ross --- Small correction, the Qt version is 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 456666] New: KTorrent crashes with "mmap failed : Cannot allocate memory" even with plenty of free memory
https://bugs.kde.org/show_bug.cgi?id=45 Bug ID: 45 Summary: KTorrent crashes with "mmap failed : Cannot allocate memory" even with plenty of free memory Product: ktorrent Version: 21.12.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: joris.guis...@gmail.com Reporter: kdeb1...@tebibyte.org Target Milestone: --- SUMMARY Ktorrent does not start, instead crashing out with "mmap failed : Cannot allocate memory" despite there being plenty of memory. Rebooting the computer does not help, ktorrent still won't run. chris@xavier 08:13:04 ~ $ free -h totalusedfree shared buff/cache available Mem: 125Gi 4.2Gi 114Gi56Mi 6.4Gi 120Gi Swap: 256Gi 0B 256Gi STEPS TO REPRODUCE 1. Boot the computer 2. Log in (KDE/Plasma) 3. Choose KTorrent from the "Internet" menu 4. "Nothing happens" 5. Open Konsole 6. Enter "ktorrent --verbose" 7. Output as below... OBSERVED RESULT chris@xavier 08:12:58 ~ $ ktorrent --verbose Wed Jul 13 08:13:02 2022: Bound to :: Wed Jul 13 08:13:02 2022: UTP: bound to :: Wed Jul 13 08:13:02 2022: Bound to 0.0.0.0 Wed Jul 13 08:13:02 2022: UTP: bound to 0.0.0.0 Wed Jul 13 08:13:02 2022: Bound to UDP port 6881 Wed Jul 13 08:13:02 2022: Bound to :: Wed Jul 13 08:13:02 2022: Cannot bind to port 0.0.0.0:6881 : Address already in use Wed Jul 13 08:13:02 2022: Bound to TCP port 6881 Wed Jul 13 08:13:02 2022: DHT: Starting on port 7881 Wed Jul 13 08:13:02 2022: Bound to :: Wed Jul 13 08:13:02 2022: DHT: Bound to :: Wed Jul 13 08:13:02 2022: Bound to 0.0.0.0 Wed Jul 13 08:13:02 2022: DHT: Bound to 0.0.0.0 Wed Jul 13 08:13:02 2022: DHT: finding node Wed Jul 13 08:13:02 2022: Cannot open /home/chris/.local/share/ktorrent/groups : No such file or directory Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor0/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor1/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor10/ Wed Jul 13 08:13:02 2022: Encoding : UTF-8 Wed Jul 13 08:13:02 2022: Bound to :: Wed Jul 13 08:13:02 2022: Bound to 0.0.0.0 Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor11/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor12/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor13/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor14/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor15/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor16/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor17/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor18/ Wed Jul 13 08:13:02 2022: Encoding : UTF-8 Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor19/ Wed Jul 13 08:13:02 2022: Loading /home/chris/.local/share/ktorrent/tor2/ Wed Jul 13 08:13:04 2022: mmap failed : Cannot allocate memory Wed Jul 13 08:13:04 2022: mmap failed : Cannot allocate memory Wed Jul 13 08:13:04 2022: mmap failed : Cannot allocate memory Wed Jul 13 08:13:04 2022: Uncaught exception: std::bad_alloc Wed Jul 13 08:13:04 2022: DHT: Stopping EXPECTED RESULT Ktorrent should run SOFTWARE/OS VERSIONS Linux/KDE Plasma: KUbuntu 22.04 LTS KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.13.3 ADDITIONAL INFORMATION This is on a relatively clean install of Kubuntu 22.04 (the current LTS release) although with the preexisting /home -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 455837] New: Discover crash when click update
https://bugs.kde.org/show_bug.cgi?id=455837 Bug ID: 455837 Summary: Discover crash when click update Product: Discover Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: discover Assignee: lei...@leinir.dk Reporter: wzyh...@gmail.com CC: aleix...@kde.org Target Milestone: --- Application: plasma-discover (5.25.80) Qt Version: 5.15.2 Frameworks Version: 5.96.0 Operating System: Linux 5.18.4-1-default x86_64 Windowing System: X11 Distribution: openSUSE Tumbleweed DrKonqi: 5.25.80 [KCrashBackend] -- Information about the crash: Discover crashe when click update click then crash, every time The crash can be reproduced every time. -- Backtrace: Application: Discover (plasma-discover), signal: Segmentation fault [KCrash Handler] #4 0x7f038a394a90 in QQmlType::QQmlType(QQmlType const&) () from /lib64/libQt5Qml.so.5 #5 0x7f038a3fa78c in ?? () from /lib64/libQt5Qml.so.5 #6 0x7f038a3fd381 in ?? () from /lib64/libQt5Qml.so.5 #7 0x7f038a3fd70c in ?? () from /lib64/libQt5Qml.so.5 #8 0x7f038a3fdf34 in ?? () from /lib64/libQt5Qml.so.5 #9 0x7f038a3f8f4b in ?? () from /lib64/libQt5Qml.so.5 #10 0x7f038a34a705 in ?? () from /lib64/libQt5Qml.so.5 #11 0x7f038a35071e in ?? () from /lib64/libQt5Qml.so.5 #12 0x7f038a33e255 in QQmlDataBlob::tryDone() () from /lib64/libQt5Qml.so.5 #13 0x7f038a39da35 in QQmlTypeLoader::setData(QQmlDataBlob*, QQmlDataBlob::SourceCodeData const&) () from /lib64/libQt5Qml.so.5 #14 0x7f038a39e182 in QQmlTypeLoader::setData(QQmlDataBlob*, QString const&) () from /lib64/libQt5Qml.so.5 #15 0x7f038a39eff0 in QQmlTypeLoader::loadThread(QQmlDataBlob*) () from /lib64/libQt5Qml.so.5 #16 0x7f038a359d0d in ?? () from /lib64/libQt5Qml.so.5 #17 0x7f038a4173af in ?? () from /lib64/libQt5Qml.so.5 #18 0x7f038a417b72 in ?? () from /lib64/libQt5Qml.so.5 #19 0x7f038a9233ce in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #20 0x7f03896d1ce8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #21 0x7f03896d4c81 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5 #22 0x7f0389729903 in ?? () from /lib64/libQt5Core.so.5 #23 0x7f0387d35ea0 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #24 0x7f0387d36258 in ?? () from /lib64/libglib-2.0.so.0 #25 0x7f0387d362ec in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #26 0x7f0389729106 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #27 0x7f03896d075b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #28 0x7f03894eab57 in QThread::exec() () from /lib64/libQt5Core.so.5 #29 0x7f038a417045 in ?? () from /lib64/libQt5Qml.so.5 #30 0x7f03894ebd4d in ?? () from /lib64/libQt5Core.so.5 #31 0x7f0389042777 in start_thread () from /lib64/libc.so.6 #32 0x7f03890ccc10 in clone3 () from /lib64/libc.so.6 Thread 2 (Thread 0x7f03831ce640 (LWP 3671) "QDBusConnection"): #1 0x7f0387d8422f in ?? () from /lib64/libglib-2.0.so.0 #2 0x7f0387d35cb6 in g_main_context_check () from /lib64/libglib-2.0.so.0 #3 0x7f0387d36170 in ?? () from /lib64/libglib-2.0.so.0 #4 0x7f0387d362ec in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #5 0x7f038972911e in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #6 0x7f03896d075b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #7 0x7f03894eab57 in QThread::exec() () from /lib64/libQt5Core.so.5 #8 0x7f038a634277 in ?? () from /lib64/libQt5DBus.so.5 #9 0x7f03894ebd4d in ?? () from /lib64/libQt5Core.so.5 #10 0x7f0389042777 in start_thread () from /lib64/libc.so.6 #11 0x7f03890ccc10 in clone3 () from /lib64/libc.so.6 Thread 1 (Thread 0x7f03868f6480 (LWP 3668) "plasma-discover"): #1 0x7f0389041ab0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libc.so.6 #2 0x7f03894f164b in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /lib64/libQt5Core.so.5 #3 0x7f038a41778c in ?? () from /lib64/libQt5Qml.so.5 #4 0x7f038a39f3b1 in QQmlTypeLoader::load(QQmlDataBlob*, QQmlTypeLoader::Mode) () from /lib64/libQt5Qml.so.5 #5 0x7f038a39fcf0 in QQmlTypeLoader::getType(QUrl const&, QQmlTypeLoader::Mode) () from /lib64/libQt5Qml.so.5 #6 0x7f038a378bfd in QQmlComponentPrivate::loadUrl(QUrl const&, QQmlComponent::CompilationMode) () from /lib64/libQt5Qml.so.5 #7 0x7f038a4219b1 in ?? () from /lib64/libQt5Qml.so.5 #8 0x7f038a2b3c63 in ?? () from /lib64/libQt5Qml.so.5 #9 0x7f038a2b6937 in ?? () from /lib64/libQt5Qml.so.5 #10 0x7f038a24ab10 in ?? () from /lib64/libQt5Qml.so.5 #11 0x7f038a2c5c42 in
[valgrind] [Bug 453929] 3.18.1 - make check fails to compile for aarch64-linux with musl C library. FIX PROPOSED.
https://bugs.kde.org/show_bug.cgi?id=453929 Alyssa Ross changed: What|Removed |Added CC||h...@alyssa.is -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 --- Comment #11 from Alyssa Ross --- Created attachment 143818 --> https://bugs.kde.org/attachment.cgi?id=143818=edit Output of make regtest on FreeBSD (with my changes) Oh, and here's the output of make regtest on FreeBSD with my changes applied, incase that's helpful. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 --- Comment #10 from Alyssa Ross --- Hi there(In reply to Paul Floyd from comment #9) > > I can do that, but to save us both some time, is there a list of things I > > should be making sure are installed before I run the tests? I didn't know I > > needed gdb, for example. > > At least you will need gsed and gdb. No harm installing coreutils as well. > You'll need to run autogen and configure again. Thanks for the tips! I was able to get down to 16 failures on FreeBSD, shown before, both before and after my changes: == 755 tests, 16 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pmovmskb (stderr) memcheck/tests/clientperm(stderr) memcheck/tests/demangle-rust (stderr) memcheck/tests/dw4 (stderr) memcheck/tests/gone_abrt_xml (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) helgrind/tests/tls_threads (stderr) drd/tests/atomic_var (stderr) drd/tests/omp_matinv (stderr) drd/tests/omp_matinv_racy(stderr) drd/tests/omp_prime_racy (stderr) none/tests/fdleak_cmsg (stderr) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 --- Comment #8 from Alyssa Ross --- (In reply to Paul Floyd from comment #7) > Hmm. Those figures are fairly high. I guess that you have some things > missing like gdb. At the worst this patch should only affect configure and 2 > testcases. > > Could you please rerun the tests, redirecting the output to a file and > attaching the files here? I can do that, but to save us both some time, is there a list of things I should be making sure are installed before I run the tests? I didn't know I needed gdb, for example. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 --- Comment #6 from Alyssa Ross --- (In reply to Paul Floyd from comment #5) > On FreeBSD I would expect 12 regtest failures on 13.0 amd64 (needs mq, > 'kldload mqueuefs') I got 44 failures on FreeBSD 13 install (with mqueuefs), but my change didn't make a difference to the number of failures. > I haven't tried Illumos in a while. I've run the regression tests for the > last several Valgrind releases on Solaris 11.3, and the last one that I have > a record of gave 13 fails. On OpenIndiana Hipster 2021.04 I got 94 failures, but again my changes didn't make a difference to the number of failures. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 Alyssa Ross changed: What|Removed |Added Attachment #143428|0 |1 is obsolete|| --- Comment #4 from Alyssa Ross --- Created attachment 143535 --> https://bugs.kde.org/attachment.cgi?id=143535=edit Patches that fix make check on Musl (V2) Nixpkgs CI caught that I'd forgotten an #include "config.h" in my first attempt, which caused a build error on Glibc. This new revision fixes that, and has successfully passed make check on Musl and GLibc. I'd usually be able to test Darwin using our CI as well, but unfortunately our Valgrind package is currently broken on Darwin for unrelated reasons I haven't looked into. I'd be happy to test any other free platforms (FreeBSD, illumos, etc.) that would be helpful — I have VMs set up for most of these already — as long as I know what to be testing for — just make check? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 --- Comment #2 from Alyssa Ross --- (In reply to Paul Floyd from comment #1) > How big an issue is this? I'm not sure it's really for me to say — it was blocking us from having a Valgrind package for musl in Nixpkgs[1], because we run make check to make sure everything's working okay. It would be nice to have the fix upstream so we don't have to apply the patches ourselves. I imagine there are potential Valgrind contributors out there running Alpine Linux or Void Linux as well, for whom it would certainly be useful if make check worked. [1]: https://github.com/NixOS/nixpkgs -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445300] New: [PATCH] Fix building tests with Musl
https://bugs.kde.org/show_bug.cgi?id=445300 Bug ID: 445300 Summary: [PATCH] Fix building tests with Musl Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: h...@alyssa.is Target Milestone: --- Created attachment 143428 --> https://bugs.kde.org/attachment.cgi?id=143428=edit Patches that fix make check on Musl. SUMMARY Test suite could not be built on Musl. STEPS TO REPRODUCE 1. Run ./configure && make && make check on a Musl-based system. OBSERVED RESULT Various compilation errors. EXPECTED RESULT Make finishes successfully. SOFTWARE/OS VERSIONS Linux: 5.14.15 Musl: 1.2.2 ADDITIONAL INFORMATION Attached are three patches in mbox format. After applying all of them, I was able to make check successfully. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 444544] [wayland] - latte leaves behind ghost after changes in kwin
https://bugs.kde.org/show_bug.cgi?id=444544 Ross Charles Campbell changed: What|Removed |Added CC||rossbridger...@pm.me --- Comment #4 from Ross Charles Campbell --- The issue is likely caused by nvidia 495 driver. Lattedock and Konsole returned to normal after I downgraded nvidia driver to 470. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 269338] Konsole always starts on the same display when using two independent displays
https://bugs.kde.org/show_bug.cgi?id=269338 --- Comment #7 from Ross --- Hi Justin I am sorry I can no longer confirm if this is the case as I gave up using separate displays and learnt to live with the limitation and advantage of having a unified display. However I will try reconfigure this weekend if I have some spare time and report back. Regards Ross On 2020/11/03 08:16, Justin Zobel wrote: > https://bugs.kde.org/show_bug.cgi?id=269338 > > Justin Zobel changed: > > What|Removed |Added > > Resolution|--- |WAITINGFORINFO > Status|CONFIRMED |NEEDSINFO > CC||justin.zo...@gmail.com > > --- Comment #6 from Justin Zobel --- > Ross/Jekyll I'd first like to acknowledge that this issue has seen a few > years. > :) > > Is this still an issue with current konsole? I'm not 100% familiar with having > alternate display exports. > -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 369050] Konsole crashs randomly.
https://bugs.kde.org/show_bug.cgi?id=369050 --- Comment #23 from Chris Ross --- (In reply to Justin from comment #22) > Can you please confirm if this is still an issue with Konsole 20.08.1+. I am running Konsole 20.04.1 and I can confirm that is stable. It has not crashed for me in a very long time despite my running it all day, every day, on two different computers (one running Fedora 31, the other F32). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 411117] New: KWin crashes when switching between virtual desktops
https://bugs.kde.org/show_bug.cgi?id=47 Bug ID: 47 Summary: KWin crashes when switching between virtual desktops Product: kwin Version: 5.12.8 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: r...@prs.dev Target Milestone: --- Application: kwin_x11 (5.12.8) Qt Version: 5.9.5 Frameworks Version: 5.44.0 Operating System: Linux 4.15.0-55-generic x86_64 Distribution: Ubuntu 18.04.2 LTS -- Information about the crash: - What I was doing when the application crashed: I used a script to switch to virtual desktop 3 (index 2) : `/usr/bin/wmctrl -s 2` Desktop 3 is running the following in full screen: konsole -qwindowtitle Remote Desktop Multimon --icon application-x-remote-connection -e /bin/bash -c cat ~/.rdppass | /opt/freerdp-nightly/bin/xfreerdp /from-stdin /multimon /v: /u: /d: +clipboard /cert-ignore After a few moments, KWin dies and has to be restarted with `kwin --replace` The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin_x11), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f908032ecc0 (LWP 21398))] Thread 6 (Thread 0x7f904a3bd700 (LWP 21413)): #0 0x7f9078cf89f3 in futex_wait_cancelable (private=, expected=0, futex_word=0x7f907c28ffb8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7f907c28ff68, cond=0x7f907c28ff90) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x7f907c28ff90, mutex=0x7f907c28ff68) at pthread_cond_wait.c:655 #3 0x7f907bf995f4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #4 0x7f907bf99639 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #5 0x7f9078cf26db in start_thread (arg=0x7f904a3bd700) at pthread_create.c:463 #6 0x7f907fc9988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7f904b5d9700 (LWP 21410)): #0 0x7f907fc8ccf6 in __GI_ppoll (fds=0x55ebdcf0a408, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x7f907d08e5c1 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7f907d08fcde in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f907d0379ea in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f907ce5622a in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f907ce5b16d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f9078cf26db in start_thread (arg=0x7f904b5d9700) at pthread_create.c:463 #7 0x7f907fc9988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7f9054dc4700 (LWP 21405)): #0 0x7f907d068c69 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #1 0x7f907d08fea0 in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7f907d0379ea in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f907ce5622a in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f90777de6f5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #5 0x7f907ce5b16d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f9078cf26db in start_thread (arg=0x7f9054dc4700) at pthread_create.c:463 #7 0x7f907fc9988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f905700 (LWP 21400)): #0 0x7f907fc8ccf6 in __GI_ppoll (fds=0x7f9058009a98, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x7f907d08e5c1 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7f907d08fcde in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f907d0379ea in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f907ce5622a in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f90766b7d45 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #6 0x7f907ce5b16d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f9078cf26db in start_thread (arg=0x7f905700) at pthread_create.c:463 #8 0x7f907fc9988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f90669aa700 (LWP 21399)): #0 0x7f907fc8cbf9 in __GI___poll (fds=0x7f90669a9c68, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f907eb96747 in ?? () from
[lattedock] [Bug 410931] Latte-Dock blocks Yakuake from opening on left monitor if set to always visible, justify and vertically displayed on left hand side of the right monitor (Dual monitor setup)
https://bugs.kde.org/show_bug.cgi?id=410931 --- Comment #2 from Ross --- (In reply to Michail Vourlakos from comment #1) > What would you think a proper solution for this? To have an Always Visible > panel in that state is not possible. Plasma solves this by disabling the > Always Visible state in that case and windows are put above, but Latte does > not support Window Can Cover mode. Under X11 no other way is possible. > > So what you would consider a proper fix? I raised the point to explore the reason as to why the dropdown terminal would not drop behind the latte dock when vertical (but would work in front). Note: I do not understand the inner workings of X11 etc. However I noted, if the dock is centred the dropdown terminal operates, I did not realise there was a difference between a justified docker and a centred one. Your reply seems to indicate there is a difference which cannot be overcome due to X11 issues, therefore, I will just have to use the docker in Centred mode; unless I can assist you with investigating this as a bug? -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 410931] New: Latte-Dock blocks Yakuake from opening on left monitor if set to always visible, justify and vertically displayed on left hand side of the right monitor (Dual monitor set
https://bugs.kde.org/show_bug.cgi?id=410931 Bug ID: 410931 Summary: Latte-Dock blocks Yakuake from opening on left monitor if set to always visible, justify and vertically displayed on left hand side of the right monitor (Dual monitor setup) Product: lattedock Version: 0.8.9 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: j2flbxp3l...@opayq.com Target Milestone: --- SUMMARY When using the dock on dual monitors and vertically aligning the dock on the left hand side of my right monitor, if the dock is set to Always Visible and Justify; I cannot open Yakuake on my left hand monitor. STEPS TO REPRODUCE 1. Position the dock on the left hand side of my right monitor on a dual monitor setup 2. Set the dock to Always Visible and Justify 3. Fail to open Yakuake (Pressing F12) on the left hand monitor, however, it is possible to open it on the right hand monitor. OBSERVED RESULT Yakuake does not open on the left hand monitor EXPECTED RESULT Yakuake should open on either monitor, just like it does it the dock is set to Centre not Justify. SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE Tumbleweed KDE (available in About System) KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 407952] Race condition when capturing guide frames, with possible fix
https://bugs.kde.org/show_bug.cgi?id=407952 --- Comment #2 from Kevin Ross --- I'm sure it is just a workaround, but I ran it all last night without issue. So, it works for me. :) -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 407952] New: Race condition when capturing guide frames, with possible fix
https://bugs.kde.org/show_bug.cgi?id=407952
Bug ID: 407952
Summary: Race condition when capturing guide frames, with
possible fix
Product: kstars
Version: git
Platform: MS Windows
OS: MS Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mutla...@ikarustech.com
Reporter: ke...@familyross.net
Target Milestone: ---
When capturing guide frames, I would occasionally get the error in the INDI
panel that the requested value (0) was out of range. Also occasionally, I would
get a really, really short exposure, which would result in a guide frame with
just noise.
Digging in, and putting a lot of debug logging in place, I think the problem
comes from when the INDI server sends back status messages about the current
exposure remaining. The problem seems to be made worse because the server and
client are communicating over WiFi, which slows down the responses from the
server to the client.
So, I believe what is happening:
Guide module requests the CCD to capture a new frame.
CCDChip::capture gets the exposure INumberVectorProperty from the device,
and updates the value to the new exposure value.
(I think this is where things go wrong) The client receives a notification
from the server that the exposure value has changed, overwriting the
INumberVectorProperty above
CCDChip::capture sends the wrong value to sendNewNumber()
I verified that # 3 is happening, by modifying CCDCHip::capture so that it
prints the value of the INumberVectorProperty right after it is set, and loops
a few times with a small delay, and prints the values again. During this time,
the value will sometimes change all on its own to 0, leading me to believe that
# 3 above is the culprit.
My fix is to modify CCDChip::capture to clone the INumberVectorProperty into a
local variable and make changes there. Since I don't know the proper way to
clone an INumberVectorProperty, my method is probably not ideal.
But here's my version of CCDChip::capture:
bool CCDChip::capture(double exposure)
{
INumberVectorProperty *expProp = nullptr;
switch (type)
{
case PRIMARY_CCD:
expProp = baseDevice->getNumber("CCD_EXPOSURE");
break;
case GUIDE_CCD:
expProp = baseDevice->getNumber("GUIDER_EXPOSURE");
break;
}
if (expProp == nullptr)
return false;
// clone the INumberVectorProperty, to avoid modifications to the same
// property from two threads
INumber n;
strcpy(n.name, expProp->np[0].name);
n.value = exposure;
auto newExpProp = std::make_unique();
strcpy(newExpProp->device, expProp->device);
strcpy(newExpProp->name, expProp->name);
newExpProp->np =
newExpProp->nnp = 1;
clientManager->sendNewNumber(newExpProp.get());
return true;
}
--
You are receiving this mail because:
You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #9 from Ross Boylan --- Well, the message just says a package isn't installed. The immediate point is that the install instructions for kdiff3 are still incomplete. I don't know if it's a kdiff3 or, more likely, a craft issue, but it seems odd that craft doesn't go ahead and install the package nsis. If the intent of the message from craft was that I should execute 'craft nsis', that is not clear. That phrase currently reads as an appositive for "nsis package" NOT as an instruction. Admittedly it doesn't quite make sense in that reading. On the theory that it was intended as an instruction (which for some reason craft --package didn't want to execute) I executed 'craft nsis' and then repeated the craft --package command. I think this worked. So does the line Output: "C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.exe" mean that file is an installer for the kdiff3 I previously built? Here's the transcript of the final, --package, step: == *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** Overriding C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\bin\data\info\dir Overriding C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\bin\data\info\dir executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe a -r C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.7z -bso2 -bsp1 C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\* executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe a -r C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl-dbg.7z -bso2 -bsp1 C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive-dbg\* executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\makensis.exe /V3 C:\Users\rdboylan\Documents\src\CraftRoot\build\_\51b6ca1c\kdiff3.nsi MakeNSIS v3.03 - Copyright 1999-2018 Contributors See the file COPYING for license details. Credits can be found in the Users Manual. Processing config: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\nsis\nsisconf.nsh Processing script file: "C:\Users\rdboylan\Documents\src\CraftRoot\build\_\51b6ca1c\kdiff3.nsi" (ACP) Processed 1 file, writing output (x86-ansi): Output: "C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.exe" Install: 6 pages (384 bytes), 2 sections (1 required) (4144 bytes), 822 instructions (23016 bytes), 295 strings (5369 bytes), 1 language table (334 bytes). Uninstall: 2 pages (192 bytes), 1 section (2072 bytes), 328 instructions (9184 bytes), 163 strings (2735 bytes), 1 language table (254 bytes). Datablock optimizer saved 1888 bytes (~0.0%). Using zlib compression. EXE header size: 63488 / 37888 bytes Install code: 5929 / 31663 bytes Install data: 74342779 / 75050374 bytes Uninstall code+data: 24201 / 28522 bytes CRC (0x3C024D03): 4 / 4 bytes Total size: 74436401 / 75148451 bytes (99.0%) *** Craft package succeeded: extragear/kdiff3 after 5 minutes 14 seconds *** -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #7 from Ross Boylan --- I deleted both the boost folder and the one above it, 20653f50. This did allow the build to continue. After > 30 minutes it finished, showing success. The next step fails, however, in the same way it did before. craft --package kdiff3: === *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** could not find installed nsis package, 'craft nsis' Action: package for extragear/kdiff3:master FAILED *** Craft package failed: extragear/kdiff3 after 0 seconds *** cs kdiff3 does seem to put me in the source directory, which looks like a git repo. cb kdiff3 puts me in a subdirectory, and from there bin\kdiff3 launches the program! Yea! Ross From: Hannah von Reth Sent: Saturday, March 30, 2019 2:06:41 AM To: Boylan, Ross Subject: [kdiff3] [Bug 405918] INSTALL instructions don't work https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #6 from Hannah von Reth --- Can you try to manually delete the boost folder? Looks like some bad files, created from the failed fallback unpack. -- You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #5 from Ross Boylan --- I enabled developer mode and reran. First time failed with PermissionError: [WinError 5] Access is denied: 'C:\\Users\\rdboylan\\Documents\\src\\CraftRoot\\build\\_\\20653f50\\boost_1_69_0\\libs' I made sure I had nothing open on the directory tree and tried again. I still got FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\rdboylan\\Documents\\src\\CraftRoot\\build\\_\\20653f50\\boost_1_69_0\\libs\\geometry\\doc\\html\\geometry\\reference\\spatial_indexes\\boost__geometry__index__rtree\\rtree_parameters_type_constindexable_getter_constvalue_equal_constallocator_type_const___.html' Do I need to delete the directory (which?)? Restart powershell after having set dev mode (don't think so: tried it and got the 2nd error above)? Do some equivalent of make clean, hopefully one that will only affect boost-headers? Except for the problem with qith MySQL, the stuff before this all seems to have built OK. Does that fact I was not in dev mode means some of those packages might not be quite right either? Ross From: Hannah von Reth Sent: Friday, March 29, 2019 4:34 PM To: Boylan, Ross Subject: [kdiff3] [Bug 405918] INSTALL instructions don't work https://bugs.kde.org/show_bug.cgi?id=405918 Hannah von Reth changed: What|Removed |Added CC||vonr...@kde.org --- Comment #4 from Hannah von Reth --- For the boost tar. Please enable Windows dev mode https://protect2.fireeye.com/url?k=9f8ede37-c3ceb361-9f8ef92a-0cc47adb57f0-5e9fc5eb173cc7c9=https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development so that symlinks are supported(then we can use 7z to unpack stuff) -- You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #3 from Ross Boylan --- craft kdiff3 did a lot more, but had a hiccup along the way and then a heart attack: Hiccup: *** Craft all succeeded: libs/dbus after 5 seconds *** === *** Handling package: binary/mysql, action: all *** *** Action: fetch-binary for binary/mysql *** wget https://files.kde.org/craft/master/Qt_5.12.2/windows/msvc2017_64/cl/RelWithDebInfo/binary/mysql/mysql-5.7.18-7-20190319T110634-windows-msvc2017_64-cl.7z C:/Users/rdboylan/Documents/src/CraftRoot/downl 100%[==>] 60.38M 17.5MB/sin 3.3s executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe x -r -y -oC:\Users\rdboylan\Documents\src\CraftRoot\build\binary\mysql\image-RelWithDebInfo-5.7.18 C:\Users\rdboylan\Documents\src\CraftRoot\download\cache\Qt_5.12.2\windows\msvc2017_64\cl\RelWithDebInfo\binary\mysql\mysql-5.7.18-7-20190319T110634-windows-msvc2017_64-cl.7z -t7z -bso2 -bsp1 executing command: C:\Users\rdboylan\Documents\src\CraftRoot\bin\mysqld.exe --console --initialize-insecure mysqld: Could not create or access the registry key needed for the MySQL application to log to the Windows EventLog. Run the application with sufficient privileges once to create the key, add the key manually, or turn off logging for that application. 2019-03-29T21:44:15.689166Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2019-03-29T21:44:15.690169Z 0 [ERROR] Cannot open Windows EventLog; check privileges, or start server with --log_syslog=0 2019-03-29T21:44:18.180819Z 0 [Warning] InnoDB: New log files created, LSN=45790 2019-03-29T21:44:18.823955Z 0 [Warning] InnoDB: Creating foreign key constraint system tables. 2019-03-29T21:44:19.129020Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: ce849c47-526b-11e9-aca6-b88584b6a8d5. 2019-03-29T21:44:19.225276Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. 2019-03-29T21:44:19.233296Z 1 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option. *** Craft all succeeded: binary/mysql after 1 minute 18 seconds *** === Comments: 1) Running without elevated privileges seems the likely immediate cause; 2) But it seems odd that elevated privileges should be required for what I understand to be a build form source step; 3) It's unclear to me what the status is at the end. On the one hand, there is [ERROR} in the middle of the log. On the other hand the final message indicates success. At any rate, execution continued for quite awhile. But then *** Craft all succeeded: kde/frameworks/tier1/kcodecs after 15 seconds *** === *** Handling package: libs/boost/boost-headers, action: all *** *** Action: fetch-binary for libs/boost/boost-headers *** *** libs/boost/boost-headers not found in cache *** *** Action: fetch for libs/boost/boost-headers *** wget https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.gz C:/Users/rdboylan/Documents/src/CraftRoot/downl 100%[==>] 106.53M 41.6MB/sin 2.6s *** Action: unpack for libs/boost/boost-headers *** Failed to unpack boost_1_69_0.tar.gz Traceback (most recent call last): File "C:\Users\rdboylan\Documents\src\CraftRoot\craft\bin\utils.py", line 86, in unpackFile shutil.unpack_archive(os.path.join(downloaddir, filename), workdir) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\shutil.py", line 999, in unpack_archive func(filename, extract_dir, **kwargs) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\shutil.py", line 934, in _unpack_tarfile tarobj.extractall(extract_dir) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\tarfile.py", line 2002, in extractall numeric_owner=numeric_owner) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\tarfile.py", line 2044, in extract numeric_owner=numeric_owner) Fil
[kdiff3] [Bug 405918] New: INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 Bug ID: 405918 Summary: INSTALL instructions don't work Product: kdiff3 Version: 1.8.x Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY INSTALL instructions don't work. Build fails to find the first package and gives up. STEPS TO REPRODUCE 1. Installed craft on Win 10 with MSVC 2017. 2. Followed new INSTALL instructions from https://cgit.kde.org/kdiff3.git/tree/INSTALL (blob: 88471cbe3d4c11007abf253ee9c60c54ad0a2287). Since I'd already followed most of the steps (except I did not use Admin privileges, and CraftRoot was in my local directory hierarchy). This came down to executing ... 3. Craft --package kdiff3 OBSERVED RESULT PS C:\Users\rdboylan\Documents\src\CraftRoot> Craft --package kdiff3 Craft : C:\Users\rdboylan\Documents\src\CraftRoot Version : master ABI : windows-msvc2017_64-cl Download directory : C:\Users\rdboylan\Documents\src\CraftRoot\download === *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** could not find installed nsis package, 'craft nsis' Action: package for extragear/kdiff3:master FAILED *** Craft package failed: extragear/kdiff3 after 1 second *** PS C:\Users\rdboylan\Documents\src\CraftRoot> EXPECTED RESULT Download and build all required packages. I thought craft would always fetch packages it didn't find; I'm not sure why it just gave up. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION MSVS 2019 Preview is also on the system. The craft setup appeared to have been successful, but this is the first time I've used it for anything other than building itself. craft has some local modifications to support VS2019; I don't think they are material for this scenario. Thank you for providing the INSTALL document in response to my earlier request. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405910] New: Bad pointer for bug submission
https://bugs.kde.org/show_bug.cgi?id=405910 Bug ID: 405910 Summary: Bad pointer for bug submission Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY https://github.com/KDE/craft has a link for bugs that doesn't lead to any obvious way to submit bugs. STEPS TO REPRODUCE 1. Go to https://github.com/KDE/craft 2. Scroll down to the "Getting in Touch" section at the bottom 3. Click on the "Report Bugs" link. OBSERVED RESULT End up at https://phabricator.kde.org/project/profile/61/ which has no obvious way to submit a bug. EXPECTED RESULT End up somewhere I can submit a bug, presumably bugs.kde.org. Ideally it would be partly filled out. Or, the page I arrived at could have a clear way to submit bugs. I gather phabricator will do bug tracking in the future, but for now it doesn't. As a stopgap, it might at least include a link to bugs.kde.org. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION The hyperlink is in the README.md file. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405909] New: Unclear instructions at end of craft setup
https://bugs.kde.org/show_bug.cgi?id=405909 Bug ID: 405909 Summary: Unclear instructions at end of craft setup Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY Instructions presented to the user about what to do at the end of the craft installation are unclear and sometimes contradictory. SPECIFICS 1. CraftBootrap.py's last message is "Please run the following command to get started:". It is unclear whether the indicated command needs to be run once to complete the installation, or needs to be run at the start of every session using craft. Inspection of the code shows some things that are clearly one-time moves, and others that might not be. 2. craftenv.psl, the script to be run has these comments in the header: #this file sets some environment variables that are needed #for finding programs and libraries etc. #by Hannah von Reth #you should copy CraftSettings.ini.template to ..\etc\CraftSettings.ini #and adapt it to your needs (see that file for more info) a) There is no CraftSettings.ini.template file that I can see b) The script itself moves, not copies, kdesettings.ini to CraftSettings.ini c) The instructions to adapt it to your needs are invisible unless you look at the file. d) "this file sets some environment variables" suggests the script should be run in each powershell session 3. craftenv.psl clears the screen. This was a surprise to me, leading me to lose the record of the installation that preceded it. Perhaps don't clear the screen, or ask first. 4. CraftSettings.ini itself is well-commented. I found the [QtSDK] section a bit weird since it had an uncommented Path referring to a non-existent drive, Version referring to an earlier version than I believe the installer downloaded, and Compiler set to mingw even though I selected msvc. I assume none of this matters since Enabled = False in this section. 5. https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows a) The section on installing craft makes no mention of running the environment setup or customizing the ini file. b) The section on using craft says to run the environment setup. I take that as another indication it needs to be run every session. c) The note at the end of the installing craft section, "Note: For Microsoft Visual Studio compiler, it's necessary to have VCTOOLSREDISTDIR." actually refers to steps that must be taken *before* step 3. For us non-powershell gurus, it would be helpful to indicate how to do this in powershell. I hope the answer is $Env:VCTOOLSREDISTDIR = "somepath" d) The section "Using the stock Qt SDK" likewise appears after the installation instructions, but I guess needs to be done earlier if it is to be done at all. I found this whole section somewhat confusing, though my take-away was "don't do this; it might cause trouble." It sounded as if Qt would end up installed through other means. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Setup was for VS2017. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 --- Comment #3 from Ross Boylan --- See https://phabricator.kde.org/D19933 for the patch. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 --- Comment #1 from Ross Boylan --- After a lot of hacking, I have changes that might be appropriate. I still haven't a completely successful install, but the reasons appear unrelated. What is the best way to communicate the changes? They are in a branch in git in my local machine; I cloned from github, but I thought I read that is read-only. Some of the changes permit identification of pre-release versions of MSVS, which are otherwise invisible. Ross -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] New: Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 Bug ID: 405662 Summary: Add MSVS 2019 support + fix nits Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: wishlist Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY Please add support for MS Visual Studio 2019, currently available in preview and RC and scheduled for release April 2 (https://devblogs.microsoft.com/visualstudio/visual-studio-2019-release-candidate-rc-now-available/) Along the way I encountered some documentation and error handling that I think can be improved on. STEPS TO REPRODUCE 1. Following https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows setup powershell and start installation. 2. The script asks to choose a compiler and MSVS 2019 is not on the list. That completes the steps to reproduce. I pressed on, selecting MSVS 2017, which is not on my system. OBSERVED RESULT VS2019 was not a choice. After continuing with 2017 I got the message Execute: C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\python.exe c:\Users\rdboylan\Documents\src\CraftRoot\craft-master\bin\craft.py craft Please ensure that you have installed the C++ component and it stopped. EXPECTED RESULT Well, I kind of expected it to fail :) But it would have been nice if it didn't. I also expected it would be clear whether or not the installation succeeded; it was not. That is, the final message sounded as if it could be recommended post-installation setup. It was also very unclear what exactly was being referred to. Based on looking at the code I'm pretty sure this was a failure. The likely immediate cause was that VCTOOLSREDISTDIR was not set. This was partly because the instructions noted above do not refer to it until AFTER the instructions to install craft. Whether setting it will be sufficient to proceed I don't know; I'll try as soon as I figure the best way to restart. In short: 1. Main issue: Add support for VS 2019 Secondary issues: 2. If installation fails, make it clear it has failed. 3. The message "Please ensure that you have installed the C++ component" could be more explicit about what exactly is missing and how it needs to be installed. 4. Instructions at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows should specify steps in the order in which they are performed, i.e., set env variables before running script. Better yet, the script could handle this itself, minimally by warning if a needed environment variable is missing and maximally by setting it appropriately. FWIW, I believe with my current installation C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Redist\MSVC\14.20.27404 is the right value. I believe $env:VCTOOLSREDISTDIR= "..." is the right way to set it. SOFTWARE/OS VERSIONS Windows: 10 64 bit; MSVS 2019 Preview ADDITIONAL INFORMATION Note the installer did find the Python3.7 that was installed as part of VS. I was doing this to build kdiff3. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405506] New: Needs specific instructions about how to build from source
https://bugs.kde.org/show_bug.cgi?id=405506 Bug ID: 405506 Summary: Needs specific instructions about how to build from source Product: kdiff3 Version: 1.8.x Platform: unspecified OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY Please describe specifically how to build the package from source on Windows or *nix. Ideally this would go in INSTALL; alternately it could go in the README. This would start with a list of prerequisite software, where to obtain it, and whether source or binary versions were necessary. It would then describe environment setup and build steps. DETAILS The current source code (git://anongit.kde.org/kdiff3.git) does not explain in any specific way how to build the package on either Windows (my current concern) or *nix. INSTALL is simply a pointer to the README, which has some general remarks about requirements at the top. The old, specific, instructions were deleted as obsolete, but they haven't been replaced by anything. It doesn't even indicate which specific KF5 frameworks are required. Maybe this is all obvious to those familiar with cmake or KF5, but it's not obvious to me. The old INSTALL recipe of configure; make; make install was "obvious" to those familiar with it, but it was still documented in INSTALL. I'm hoping for something similar. https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows has been only marginally helpful. Having followed the steps, I'm not even sure if I've completed them properly or not (the last thing was the message Execute: C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\python.exe c:\Users\rdboylan\Documents\src\CraftRoot\craft-master\bin\craft.py craft Please ensure that you have installed the C++ component ). And it was also unclear to me from those instructions whether it would suffice to download the Qt binaries. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 360478] Desktop widgets are permanently repositioned when fullscreen games lower display resolution
https://bugs.kde.org/show_bug.cgi?id=360478 Ross changed: What|Removed |Added CC||r.esmaeilbe...@gmail.com --- Comment #30 from Ross --- Related bug? https://bugs.kde.org/show_bug.cgi?id=354802 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #15 from Ross --- Related bug? https://bugs.kde.org/show_bug.cgi?id=360478 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 Ross changed: What|Removed |Added CC||r.esmaeilbe...@gmail.com --- Comment #9 from Ross --- I also have the issue. Linux/KDE Plasma: Kubuntu 18.04.1 KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 This is VERY ANNOYING. The reason I use folder view is because I can arrange the folders in a reasonbale manner to organize things. What is the point of having folder view on desktop if you cannot arrange folders? Any file manger does the job far better. I hope that this long-lasting bug is taken more seriously. -- You are receiving this mail because: You are watching all bug changes.
[print-manager] [Bug 395383] Settings are not saved in printer global settings
https://bugs.kde.org/show_bug.cgi?id=395383 Ross changed: What|Removed |Added CC||r.esmaeilbe...@gmail.com --- Comment #4 from Ross --- I want to second it. I have almost the same issue: SUMMARY On Kubuntu 18.04.1 with Plasma 5.12.7 I can not save printer options properly. I have used the same printer with the same driver with Ubuntu 18.04 without any issues. STEPS TO REPRODUCE 1. Open 'Printers--System Settings Module' 2. In 'Configure your printer' section, select 'Add printer' 3. Choose 'Manual URI' 4. In 'connections' type 'socket://IP' where IP is the ip address for the printer and then click on 'Next'. 5. Select 'Manually provide a PPD file' and then 'Next'. 6. Give the printer a name ... Note: the driver is KONIKA MINOLTA C652SeriesPS(P) After the printer is appeared in the list of Printers: 7. Set it as 'default' and click on 'Configure' 8. In 'Printer Options'change some settings 9. Apply -> OK 10. Open the Printer settings again and you see that the settings have not been saved. OBSERVED RESULT When opening a PDF file with evince to print, I think most of the options are available. The printer will print normally except that I do not see the staple option in evince (in the advanced tab) and so the printer does not apply staple. In Okular I do not see any staple option and presumably it should use the default settings (which are not saved in this case). An observation in the first try: Only in the first try to add staple option, I observed that evince has the option 'staple' available but together with a yellow color (kind of warning, don't remember exactly). EXPECTED RESULT Printer settings are not saved. In particular, staple options do not apply. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.04.1 (available in About System) KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 392447] KIO does not use WS-discovery for SMB network resources discovery, so Dolphin shows nothing on smb:// or smb://workgroup/
https://bugs.kde.org/show_bug.cgi?id=392447 Ross changed: What|Removed |Added CC||j2flbxp3l...@opayq.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 397336] Tooltip timeout is too short and unalterable
https://bugs.kde.org/show_bug.cgi?id=397336 --- Comment #2 from Ross McLean --- (In reply to David Edmundson from comment #1) > Tooltip should persist whilst the mouse is over the control. Is this not the > case? They seem to stick around for about 5 seconds. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 397336] New: Tooltip timeout is too short and unalterable
https://bugs.kde.org/show_bug.cgi?id=397336 Bug ID: 397336 Summary: Tooltip timeout is too short and unalterable Product: frameworks-plasma Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: tooltips Assignee: notm...@gmail.com Reporter: rmclea...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: --- I personally feel the tooltip timeout is too short. As an example, when viewing the tooltip for Pager to see an overview of open windows across workspaces, I don't have enough time to read it. Also, it doesn't seem possible to control the timeout. An option for users to control the timeout length seems to be the sort of feature you would expect to see on KDE. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #52 from Ross Boylan <ross.boy...@ucsf.edu> --- I don't want my previous response to be taken as a vote for the status quo. The behavior I would expect is: 1. If I don't hit save my work disappears.(*) The current application does not have a save function (as distinct from save as), and I'm pretty sure that if I fill in a form, exit, and then open the form my old values will still be there. Worse, if someone else using the same account opens the form, they will see my info. 2. If I do save (not just save as) my work will be saved with the file. In this case I might not expect, but would be pleased if 3. there were an option to save the form data to a separate file and restore it from a separate file. I'd guess such a facility is consistent with the 1600 page XFA spec, though I can't say I know where :) Because the current behavior violates these expectations, it is a security risk. Someone's personal information may be exposed in ways unanticipated, and operations that usually assure security, like not saving a file or deleting it, will not work. And operations that are expected to reveal info, like copying/mailing a pdf or operating on it with a different program, may instead conceal/disappear the information. (*) Some usability experts argue that "work disappears if I don't save" is not the expectation of the lay user, and that our current model of "you must save to keep your work" is aggravating and unintuitive to them. That may well be correct. But unless the surrounding programs all start behaving this way, this behavior is undesirable. An application that may be dealing with sensitive private information is not the place to pioneer new interface models. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 Ross Boylan <ross.boy...@ucsf.edu> changed: What|Removed |Added CC||ross.boy...@ucsf.edu --- Comment #51 from Ross Boylan <ross.boy...@ucsf.edu> --- (In reply to lutz.wrage from comment #50) > Is there any use case that justifies storing form data in > ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in > the pdf itself? > It seems to me that there isn't. While I consider the current behavior undesirable, it does have its advantages. In fact, it's the reason I decided to use okular for my taxes. Here's the use case: 1. Generate some forms automatically (e.g., opentaxsolver computes my taxes and fills in government forms). 2. Resulting forms require some manual tweaks (e.g., check boxes, fill in additional fields). 3. Discover forms need to be regenerated to correct a mistake. Modify inputs and return to 1. In this scenario, the work in 2 is lost if the results have been stored in the pdf, but is retained if the values are stored elsewhere, as okular currently does. Even if the pdf in 2 is saved under a different name, so that the results are not literally lost, one must manually identify the changed information and reenter it. There is another scenario in which the recreation of the information is less desirable. If some of the manually entered information in 2 depends on the values from 1, e.g., you manually enter line 55 as a copy of line 32 but the automatically generated line 32 changes, then the previous manual data may be invalid. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382256] gz compiler flag test doesn't work for gold
https://bugs.kde.org/show_bug.cgi?id=382256 --- Comment #1 from Ross Burton <r...@burtonini.com> --- Created attachment 106565 --> https://bugs.kde.org/attachment.cgi?id=106565=edit Fix the configure test -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382256] New: gz compiler flag test doesn't work for gold
https://bugs.kde.org/show_bug.cgi?id=382256 Bug ID: 382256 Summary: gz compiler flag test doesn't work for gold Product: valgrind Version: 3.12.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: r...@burtonini.com Target Milestone: --- The compiler flag tests for -gz=zlib and -gz=zlib-gnu currently use AC_COMPILE_IFELSE, but as these are basically linker flags it appears this is just checking that the frontend supports them. For example if binutils is configured so that gold is the default linker the tests pass: checking if gcc accepts -g -gz=zlib... yes checking if gcc accepts -g -gz=zlib-gnu... yes but the actual use of them fails: | x86_64-poky-linux-gcc: error: -gz=zlib is not supported in this configuration Changing AC_COMPILE_IFELSE to AC_LINK_IFELSE means that configure detects that -gz=zlib doesn't work but zlib-gnu does, and the build works. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381266] Icontasks identifying Chrome apps as Chrome windows
https://bugs.kde.org/show_bug.cgi?id=381266
--- Comment #6 from Ross Williams <gunzy8...@gmail.com> ---
(In reply to Kai Uwe Broulik from comment #5)
Thanks for the info. That approach sounds like a better solution to the regex
based approach. As you say the StartupWMClass and WM_CLASS are a match so it
should be working:
StartupWMClass=crx_gaedmjdfmmahhbjefcbgaolhhanlaolb
WM_CLASS(STRING) = "crx_gaedmjdfmmahhbjefcbgaolhhanlaolb", "Google-chrome"
One more observation for you: the correct icon shows during launch then
switches to being grouped under the chrome icon. Not sure if that indicates
anything?
I ran the searches that you suggested and nothing appeared out of place. I have
pasted the output below:
find /usr/share/applications/ -name *.desktop | xargs grep StartupWMClass
/usr/share/applications/libreoffice-draw.desktop:StartupWMClass=libreoffice-draw
/usr/share/applications/libreoffice-startcenter.desktop:StartupWMClass=libreoffice-startcenter
/usr/share/applications/libreoffice-base.desktop:StartupWMClass=libreoffice-base
/usr/share/applications/libreoffice-impress.desktop:StartupWMClass=libreoffice-impress
/usr/share/applications/libreoffice-writer.desktop:StartupWMClass=libreoffice-writer
/usr/share/applications/libreoffice-math.desktop:StartupWMClass=libreoffice-math
/usr/share/applications/google-chrome.desktop:StartupWMClass=Google-chrome
/usr/share/applications/google-chrome.desktop:StartupWMClass=Google-chrome
/usr/share/applications/google-chrome.desktop:StartupWMClass=Google-chrome
/usr/share/applications/sublime_text_3.desktop:StartupWMClass=subl3
/usr/share/applications/Discord.desktop:StartupWMClass=discord
/usr/share/applications/libreoffice-calc.desktop:StartupWMClass=libreoffice-calc
find ~/.local/share/applications -name *.desktop | xargs grep StartupWMClass
/home/rwilliams/.local/share/applications/chrome-apdfllckaahabafndbhieahigkjlhalf-Default.desktop:StartupWMClass=crx_apdfllckaahabafndbhieahigkjlhalf
/home/rwilliams/.local/share/applications/chrome-fhbjgbiflinjbdggehcddcbncdddomop-Default.desktop:StartupWMClass=crx_fhbjgbiflinjbdggehcddcbncdddomop
/home/rwilliams/.local/share/applications/chrome-blpcfgokakmgnkcojhhkbfbldkacnbeo-Default.desktop:StartupWMClass=crx_blpcfgokakmgnkcojhhkbfbldkacnbeo
/home/rwilliams/.local/share/applications/chrome-pjkljhegncpnkpknbcohdijeoejaedia-Default.desktop:StartupWMClass=crx_pjkljhegncpnkpknbcohdijeoejaedia
/home/rwilliams/.local/share/applications/chrome-gaedmjdfmmahhbjefcbgaolhhanlaolb-Default.desktop:StartupWMClass=crx_gaedmjdfmmahhbjefcbgaolhhanlaolb
/home/rwilliams/.local/share/applications/chrome-aohghmighlieiainnegkcijnfilokake-Default.desktop:StartupWMClass=crx_aohghmighlieiainnegkcijnfilokake
I also tried clearing the ~/.local/share/applications directory of .desktop
files, deleted my Chrome profile and reinstalled Chrome just to get a fresh
environment and I am still suffering the issue on a fresh profile (not logged
in).
I'm going to have a look at the code myself when I get some time (use the ABS
in Arch to build my own copy of plasma-workspace) but I have one question from
a cursory glance at the code so far:
In terms of these two if blocks:
if (services.empty()) {
services = KServiceTypeTrader::self()->query(QStringLiteral("Application"),
QStringLiteral("exist Exec and ('%1' =~ StartupWMClass)").arg(appId));
}
if (services.empty()) {
services = KServiceTypeTrader::self()->query(QStringLiteral("Application"),
QStringLiteral("exist Exec and ('%1' =~
StartupWMClass)").arg(xWindowsWMClassName));
}
I assume xWindowsWMClassName maps to WM_CLASS but what does appId refer to?
Thanks your help. I understand it is hell trying to debug something you can't
reproduce :(
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 381266] Icontasks identifying Chrome apps as Chrome windows
https://bugs.kde.org/show_bug.cgi?id=381266 --- Comment #4 from Ross Williams <gunzy8...@gmail.com> --- (In reply to Kai Uwe Broulik from comment #3) > I cannot reproduce the issue. Neither in normal task manager nor in > icon-tasks. Can you please paste your /etc/xdg/taskmanagerrulesrc > > Also, how did you add the app to your machine? I went to Chrome Web Store > with my "Default" Chrome profile, installed "Authy" from there and then > launched it through Kickoff. Works just fine here. /etc/xdg/taskmanagerrulesrc: [Mapping] Gimp-2.8=GIMP Google-chrome=Google Chrome Google-chrome-stable=Google Chrome Systemsettings=System Settings oracle-ide-boot-Launcher=Oracle SQL Developer Dragon=dragonplayer [Settings] ManualOnly=Wine MatchCommandLineFirst=perl TryIgnoreRuntimes=perl I added the app the same way as you did via the Chrome Web Store. Interestingly this works for Chromium but not Chrome (from Google). I would just switch back to Chromium but casting my desktop only works for Chrome but not Chromium for some reason (I do this lots at work) and would rather not have to run two browsers. In any case this does not change the fact that I can downgrade 5.9.5 on my Arch system and this works properly with Chrome so something has to have changed since that version. Anything else I can do to try and debug this? I am a sysadmin but I am a bit of a noob when it comes to X related stuff outside of X conf and xrandr? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381266] Icontasks identifying Chrome apps as Chrome windows
https://bugs.kde.org/show_bug.cgi?id=381266
--- Comment #2 from Ross Williams <gunzy8...@gmail.com> ---
(In reply to Eike Hein from comment #1)
> Please supply xprop output for the windows involved as well as the names of
> the respective .desktop files and their contents.
Authy:
**
xprop output:
_NET_WM_ICON_GEOMETRY(CARDINAL) = 3246, 264, 40, 45
_KDE_NET_WM_ACTIVITIES(STRING) = "----"
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE,
_NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_VERT,
_NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_CHANGE_DESKTOP,
_NET_WM_ACTION_CLOSE
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) =
_NET_WM_USER_TIME(CARDINAL) = 98429502
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 1462, 320
program specified minimum size: 350 by 590
program specified maximum size: 700 by 700
WM_NAME(UTF8_STRING) = "Authy"
_NET_WM_NAME(UTF8_STRING) = "Authy"
XdndAware(ATOM) = BITMAP
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 98379769
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_ICON(CARDINAL) =Icon (32 x 32):
░░░░
░░
░░
▒▒▒░
▒▒
▒░
░▒▒░
▒░░▒
░▒░░▒▒ ░░
░▒▒░░▒▒▒▒▒▒
░▒░ ░▒▒░ ░▒▒▒ ░▒▒░
▒▒ ▒▒ ░▒▒▒ ░▒░
▒▒ ░▒▒▒ ░▒▒▒ ▒▒
▒░ ░ ░▒▒░ ▒▒
▒░ ▒▒▒░ ░▒
▒▒ ░▒▒▒ ▒ ░▒
▒▒ ▒▒▒░ ▒▒▒░ ▒▒
░▒░ ▒▒▒░ ░░ ▒░
░▒▒░ ▒▒▒░░░▒▒
▒▒▒░ ▒▒▒
░▒▒▓░ ░░▒▒▒░
░ ▒
░▒▒░
▒▒
▒▒
░░
░░
░░▒▒░░
_GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED(CARDINAL) = 1
WM_WINDOW_ROLE(STRING) = "app"
WM_CLASS(STRING) = "crx_gaedmjdfmmahhbjefcbgaolhhanlaolb", "Google-chrome"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_PID(CARDINAL) = 9726
WM_LOCALE_NAME(STRING) = "en_AU.UTF-8"
WM_CLIENT_MACHINE(STRING) = "CF3Q0G2"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, _NET_WM_PING
chrome-gaedmjdfmmahhbjefcbgaolhhanlaolb-Default.desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Authy
Exec=/opt/google/chrome/google-chrome --profile-directory=Default
--app-id=gaedmjdfmmahhbjefcbgaolhhanlaolb
Icon=chrome-gaedmjdfmmahhbjefcbgaolhhanlaolb-Default
StartupWMClass=crx_gaedmjdfmmahhbjefcbgaolhhanlaolb
Gmail:
**
xprop output:
_NET_WM_ICON_GEOMETRY(CARDINAL) = 3246, 264, 40, 45
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE,
_NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT,
_NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN,
_NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 29, 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 29, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_KDE_NET_WM_ACTIVITIES(STRING) = "bc96b8af-c2e6-4d5e-9c86-2d31bc9740b6"
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT,
_NET_WM_STATE_MAXIMIZED_HORZ
_NET_WM_USER_TIME(CARDINAL) = 101842239
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 0, 0
WM_NAME(UTF8_STRING) = "Inbox (1) - rwilli...@console.com.au - Console
Australia Pty Ltd Mail"
_NET_WM_NAME(UTF8_STRING) = "Inbox (1) - rwilli...@console.com.au - Console
Australia Pty Ltd Mail"
XdndAware(ATOM) = BITMAP
_KDE_NET_WM_USER_CREATION_TIME(CARD
[plasmashell] [Bug 381266] New: Icontasks identifying Chrome apps as Chrome windows
https://bugs.kde.org/show_bug.cgi?id=381266 Bug ID: 381266 Summary: Icontasks identifying Chrome apps as Chrome windows Product: plasmashell Version: 5.10.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Icons-only Task Manager Assignee: h...@kde.org Reporter: gunzy8...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 Overview: * Running Chrome apps are now identified as normal browser windows in 5.10.1 and 5.10.2. This is working correctly in 5.9.5. See screenshot links below: 5.9.5: http://i.imgur.com/MEjVRfJ.png Note the mail and Authy icons are lit up and are not grouped with Chrome. 5.10.1: http://i.imgur.com/K8k9xq4.png Note the mail and Authy apps are grouped with the Chrome windows. Steps to Reproduce: *** 1. Open Chrome. 2. Open Authy chrome app Actual Results: *** Authy is identified as a chrome window and is grouped with the other chrome browser windows. Expected Results: * Authy should start and appear in a group under its own icon, separate from other Chome browser windows. Build Date & Platform: ** Arch Linux Plasma: 5.10.1/5.10.2 KDE Frameworks: 5.35.0 Unsure of exact build date Additional Builds and Platforms: Downgraded plasma-desktop package to 5.9.5, every other package at the same version on Arch Linux and the bug is not present -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 370330] New: Konsole crashes at random
https://bugs.kde.org/show_bug.cgi?id=370330 Bug ID: 370330 Summary: Konsole crashes at random Product: kde Version: unspecified Platform: unspecified OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: kdeb1...@tebibyte.org Application: kdeinit5 (15.12.3) Qt Version: 5.6.1 Frameworks Version: 5.26.0 Operating System: Linux 4.7.5-100.fc23.x86_64 x86_64 Distribution: "Fedora release 23 (Twenty Three)" -- Information about the crash: - What I was doing when the application crashed: Nothing in Konsole. I was using Friefox when Konsole, which was left open from earlier, spontaneously crashed. - Custom settings of the application: Nothing special: tabs at the top, slightly tweaked colour scheme. The crash can be reproduced sometimes. -- Backtrace: Application: Konsole (kdeinit5), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f6a7d8328c0 (LWP 1885))] Thread 3 (Thread 0x7f6a61535700 (LWP 1886)): #0 0x7f6a7ada8b7d in poll () from /lib64/libc.so.6 #1 0x7f6a7943f18c in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #2 0x7f6a7943f29c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x7f6a7bb9db5b in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #4 0x7f6a7bb4e25a in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #5 0x7f6a7b9aebd4 in QThread::exec() () from /lib64/libQt5Core.so.5 #6 0x7f6a7d8ed675 in QDBusConnectionManager::run() () from /lib64/libQt5DBus.so.5 #7 0x7f6a7b9b300c in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5 #8 0x7f6a7a5f461a in start_thread () from /lib64/libpthread.so.0 #9 0x7f6a7adb45fd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f6a590ac700 (LWP 1887)): #0 0x7f6a7ada8b7d in poll () from /lib64/libc.so.6 #1 0x7f6a7cb5f272 in _xcb_conn_wait () from /lib64/libxcb.so.1 #2 0x7f6a7cb60ee7 in xcb_wait_for_event () from /lib64/libxcb.so.1 #3 0x7f6a60c73039 in QXcbEventReader::run() () from /lib64/libQt5XcbQpa.so.5 #4 0x7f6a7b9b300c in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5 #5 0x7f6a7a5f461a in start_thread () from /lib64/libpthread.so.0 #6 0x7f6a7adb45fd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f6a7d8328c0 (LWP 1885)): [KCrash Handler] #6 0x7f6a7ace6a28 in raise () from /lib64/libc.so.6 #7 0x7f6a7ace862a in abort () from /lib64/libc.so.6 #8 0x7f6a7b99f3a1 in QMessageLogger::fatal(char const*, ...) const () from /lib64/libQt5Core.so.5 #9 0x7f6a7d8f91b1 in QDBusConnectionPrivate::deliverCall(QObject*, int, QDBusMessage const&, QVector const&, int) () from /lib64/libQt5DBus.so.5 #10 0x7f6a7bb77871 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #11 0x7f6a7c3df10c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #12 0x7f6a7c3e4646 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #13 0x7f6a7bb4f3ea in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #14 0x7f6a7bb5140a in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5 #15 0x7f6a7bb9dac3 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5 #16 0x7f6a7943ee5a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #17 0x7f6a7943f1f0 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0 #18 0x7f6a7943f29c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #19 0x7f6a7bb9db3f in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #20 0x7f6a7bb4e25a in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #21 0x7f6a7bb55bdc in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #22 0x7f6a6b43563e in kdemain () from /lib64/libkdeinit5_konsole.so #23 0x5642b9c7d4cf in launch(int, char const*, char const*, char const*, int, char const*, bool, char const*, bool, char const*) () #24 0x5642b9c7e7a7 in handle_launcher_request(int, char const*) [clone .isra.26] () #25 0x5642b9c7ef58 in handle_requests(int) () #26 0x5642b9c79f92 in main () Possible duplicates by query: bug 349162, bug 339964. Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 362105] Taskbar options 'autohide'/'windows can cover' not functional
https://bugs.kde.org/show_bug.cgi?id=362105 Chris Ross <kdeb1...@tebibyte.org> changed: What|Removed |Added CC||kdeb1...@tebibyte.org --- Comment #19 from Chris Ross <kdeb1...@tebibyte.org> --- Definitely not an nVidia issue. I see the same issue on this old Dell laptop running Fedora 23. According to lspci the graphics adaptor is 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA controller]) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 344181] konsole 256 color support differs from xterm/rxvt
https://bugs.kde.org/show_bug.cgi?id=344181 Ross Williams <gunzy8...@gmail.com> changed: What|Removed |Added CC||gunzy8...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
