Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80649 --- src/kbuildsycoca/kbuildsycoca.cpp (lines 392 - 395) https://git.reviewboard.kde.org/r/123857/#comment55297 would this affect sessions running as root? - Martin Gräßlin On May 20, 2015, 12:11 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 20, 2015, 12:11 a.m.) Review request for KDE Frameworks. Repository: kservice Description --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 Don't write kbuildsycoca cache files as root $HOME is often preserved as root, making us write cache files in the user's home directory. People shouldn't be running apps as root anyway. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123858: Fix memory leak in drags
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123858/#review80652 --- I really wonder why this is necessary. I just checked QtBase/src/corelib/widgets and it does not do this to the QDrag it creates. Maybe we should ask someone from Qt whether this is required here, or alternatively, whether it should also be done everywhere in Qt itself. src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp (line 229) https://git.reviewboard.kde.org/r/123858/#comment55301 on a related note: why is this using parent() here btw and not this? is DeclarativeDragArea not a QObject? src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp (line 312) https://git.reviewboard.kde.org/r/123858/#comment55302 if delete is OK here, then put it into a QScopedPointer - Milian Wolff On May 20, 2015, 12:23 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123858/ --- (Updated May 20, 2015, 12:23 a.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- We don't need each QDrag object to have the entire lifespan of the mousearea. it makes every drag leak not only the qdrag object, but also the associated mimedata. Diffs - src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp 3afaa62ba9ddca12faea333d3336487fb47cc19b Diff: https://git.reviewboard.kde.org/r/123858/diff/ Testing --- Draged lots of items from kickoff to the panel. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123857/#review80650
---
src/services/kservicegroupfactory.cpp (line 37)
https://git.reviewboard.kde.org/r/123857/#comment55298
no need to change the indentation level of all the code if you'd do
if (!str) {
return;
}
instead
- Milian Wolff
On May 19, 2015, 10:11 p.m., David Edmundson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123857/
---
(Updated May 19, 2015, 10:11 p.m.)
Review request for KDE Frameworks.
Repository: kservice
Description
---
3 commits fixing; a crash, what caused the crash, and why we weren't auto
recovering from it.
QFile::open() will return a Read/Write error on failed access,
PermissionsError is only in the result of a setPermissions call.
CCBUG: 342438
Don't write kbuildsycoca cache files as root
$HOME is often preserved as root, making us write cache files in the
user's home directory. People shouldn't be running apps as root anyway.
CCBUG: 342438
Guard against being unable to open stream
This can happen if we are unable to open the database when a
notifyDatabaseChanged signal is emitted.
Other places guard also against this eventuality.
BUG: 342438
Diffs
-
src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1
src/services/kservicegroupfactory.cpp
8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18
Diff: https://git.reviewboard.kde.org/r/123857/diff/
Testing
---
Thanks,
David Edmundson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
On May 20, 2015, 10:37 a.m., Luigi Toscano wrote: One thing is discouraging running applications as root, another thing is blocking them completely: what will it happen with this patch when the application is run as root, simply no cache and slower application? Isn't it possible to discover that the current HOME is not the real home of the (root) user and avoid writing the cache only in that case? I think you're right that I shouldn't merge that part like it is now. It would be possible to compare against what getpwuid says the home dir should be. It would be unix only, but this problem is unix only. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80654 --- On May 19, 2015, 10:11 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 19, 2015, 10:11 p.m.) Review request for KDE Frameworks. Repository: kservice Description --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 Don't write kbuildsycoca cache files as root $HOME is often preserved as root, making us write cache files in the user's home directory. People shouldn't be running apps as root anyway. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80654 --- One thing is discouraging running applications as root, another thing is blocking them completely: what will it happen with this patch when the application is run as root, simply no cache and slower application? Isn't it possible to discover that the current HOME is not the real home of the (root) user and avoid writing the cache only in that case? - Luigi Toscano On May 20, 2015, 12:11 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 20, 2015, 12:11 a.m.) Review request for KDE Frameworks. Repository: kservice Description --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 Don't write kbuildsycoca cache files as root $HOME is often preserved as root, making us write cache files in the user's home directory. People shouldn't be running apps as root anyway. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123861: Make KCodecs::base64Encode() RFC compliant
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123861/#review80663 --- +1 - Aleix Pol Gonzalez On May 20, 2015, 2:46 p.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123861/ --- (Updated May 20, 2015, 2:46 p.m.) Review request for KDE Frameworks. Repository: kcodecs Description --- Don't append a trailing CRLF to the coded data. This was left over from KMime, where this made some sense in respect to RFC822. According to LXR it should not affect anything except for some unreleased KDE PIM code and it will fix code that expects the original behaviour. Diffs - src/kcodecsbase64.cpp fc03262 Diff: https://git.reviewboard.kde.org/r/123861/diff/ Testing --- Thanks, Daniel Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123858: Fix memory leak in drags
On May 20, 2015, 12:59 p.m., David Edmundson wrote: Turns out this isn't needed. It's a seemingly undocumented 'feature' the drag will be deleted by QDragManager::drag() when dropped Sorry for the noise. and by undocummneted, what I mean is; Clearly written in the documentation had I bothered to read it properly. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123858/#review80659 --- On May 20, 2015, 12:59 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123858/ --- (Updated May 20, 2015, 12:59 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- We don't need each QDrag object to have the entire lifespan of the mousearea. it makes every drag leak not only the qdrag object, but also the associated mimedata. Diffs - src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp 3afaa62ba9ddca12faea333d3336487fb47cc19b Diff: https://git.reviewboard.kde.org/r/123858/diff/ Testing --- Draged lots of items from kickoff to the panel. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123861: Make KCodecs::base64Encode() RFC compliant
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123861/ --- Review request for KDE Frameworks. Repository: kcodecs Description --- Don't append a trailing CRLF to the coded data. This was left over from KMime, where this made some sense in respect to RFC822. According to LXR it should not affect anything except for some unreleased KDE PIM code and it will fix code that expects the original behaviour. Diffs - src/kcodecsbase64.cpp fc03262 Diff: https://git.reviewboard.kde.org/r/123861/diff/ Testing --- Thanks, Daniel Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123858: Fix memory leak in drags
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123858/ --- (Updated May 20, 2015, 12:59 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kdeclarative Description --- We don't need each QDrag object to have the entire lifespan of the mousearea. it makes every drag leak not only the qdrag object, but also the associated mimedata. Diffs - src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp 3afaa62ba9ddca12faea333d3336487fb47cc19b Diff: https://git.reviewboard.kde.org/r/123858/diff/ Testing --- Draged lots of items from kickoff to the panel. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/#review80669 --- src/quickaddons/quickviewsharedengine.h (line 41) https://git.reviewboard.kde.org/r/123735/#comment55306 It would be awesome if we could have some tests for this class. Maybe we can just try and copy the QQuickView tests? http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/quick/qquickview/tst_qquickview.cpp - Vishesh Handa On May 18, 2015, 8 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 8 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
On May 20, 2015, 10:37 a.m., Luigi Toscano wrote: One thing is discouraging running applications as root, another thing is blocking them completely: what will it happen with this patch when the application is run as root, simply no cache and slower application? Isn't it possible to discover that the current HOME is not the real home of the (root) user and avoid writing the cache only in that case? David Edmundson wrote: I think you're right that I shouldn't merge that part like it is now. It would be possible to compare against what getpwuid says the home dir should be. It would be unix only, but this problem is unix only. New plan, I keep the permissions the same when running as root if $HOME/.cache/ksycoca5 exists - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80654 --- On May 19, 2015, 10:11 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 19, 2015, 10:11 p.m.) Review request for KDE Frameworks. Repository: kservice Description --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 Don't write kbuildsycoca cache files as root $HOME is often preserved as root, making us write cache files in the user's home directory. People shouldn't be running apps as root anyway. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 20, 2015, 6:33 p.m.) Review request for KDE Frameworks. Repository: kservice Description (updated) --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 If running as root, keep file ownership the same as the original file we're replacing. $HOME is often preserved as root, making us write cache files in the user's home directory. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs (updated) - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123852: Optimize: Do not wipe dict cache when copying speller objects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123852/#review80674 --- +1 I don't see the reason to clear the cache on the copy assignment, but I don't dare to give a ship it as I'm not that familiar with the code. - Kåre Särs On maj 19, 2015, 9:49 f.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123852/ --- (Updated maj 19, 2015, 9:49 f.m.) Review request for KDE Frameworks, Laurent Montel, Martin Tobias Holmedahl Sandsmark, and Kåre Särs. Repository: sonnet Description --- This removes a serious performance penalty from enabling on-the-fly spell checking in KTextEditor. For some reason, the copy assignment of a Speller object invalidated the internal cache which happened very often from the Kate code base. Now, the cache is kept valid and reused, and the performance is good again. I'm not sure whether this has any unintentional side-effects, but the tests work fine and spell checking in KatePart still looks good as well, and is now fast again. E.g. previously I easily ended up with heaptrack reports such as this one: 2284529 calls to allocation functions with 16.23MB peak consumption from HashMgr::add_word(char const*, int, int, unsigned short*, int, char const*, bool) in /usr/lib/libhunspell-1.3.so.0 1978045 calls with 2.30MB peak consumption from: HashMgr::load_tables(char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HashMgr::HashMgr(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 Hunspell::Hunspell(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HunspellDict at .../sonnet/src/plugins/hunspell/hunspelldict.cpp:36 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so HunspellClient::createSpeller(QString const) at .../sonnet/src/plugins/hunspell/hunspellclient.cpp:43 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so Sonnet::Loader::createSpeller(QString const, QString const) const at .../sonnet/src/core/loader.cpp:103 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::updateDict() at .../sonnet/src/core/speller.cpp:64 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::recreateDict() at .../sonnet/src/core/speller.cpp:79 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::operator=(Sonnet::Speller const) at .../sonnet/src/core/speller.cpp:111 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::BackgroundChecker::setSpeller(Sonnet::Speller const) at .../sonnet/src/core/backgroundchecker.cpp:131 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 KateOnTheFlyChecker::performSpellCheck() at .../ktexteditor/src/spellcheck/ontheflycheck.cpp:405 in /home/milian/projects/compiled/kf5/lib64/libKF5TextEditor.so.5 Diffs - src/core/speller.cpp 3903b42ebb4f7cb98a049fcf7a291c74dd9457e0 Diff: https://git.reviewboard.kde.org/r/123852/diff/ Testing --- Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123735: version of QmlObject with a static engine
On May 20, 2015, 5:24 p.m., Vishesh Handa wrote: src/quickaddons/quickviewsharedengine.h, line 41 https://git.reviewboard.kde.org/r/123735/diff/8/?file=370104#file370104line41 It would be awesome if we could have some tests for this class. Maybe we can just try and copy the QQuickView tests? http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/quick/qquickview/tst_qquickview.cpp yeah, good idea, will give a try - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/#review80669 --- On May 18, 2015, 8 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 8 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80677 --- src/kbuildsycoca/kbuildsycoca.cpp (line 426) https://git.reviewboard.kde.org/r/123857/#comment55309 `#if Q_OS_UNIX`? Don't think Windows has getuid(). - Alex Richardson On May 20, 2015, 7:33 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/ --- (Updated May 20, 2015, 7:33 p.m.) Review request for KDE Frameworks. Repository: kservice Description --- 3 commits fixing; a crash, what caused the crash, and why we weren't auto recovering from it. QFile::open() will return a Read/Write error on failed access, PermissionsError is only in the result of a setPermissions call. CCBUG: 342438 If running as root, keep file ownership the same as the original file we're replacing. $HOME is often preserved as root, making us write cache files in the user's home directory. CCBUG: 342438 Guard against being unable to open stream This can happen if we are unable to open the database when a notifyDatabaseChanged signal is emitted. Other places guard also against this eventuality. BUG: 342438 Diffs - src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 src/services/kservicegroupfactory.cpp 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 Diff: https://git.reviewboard.kde.org/r/123857/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123867: Fix build on OSX clang and replace another abs with std::abs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123867/ --- Review request for KDE Frameworks and Milian Wolff. Repository: ki18n Description --- https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/1/console Follow up to, commit 8d392e523e4556f9e434f3e02890fcacfcb492e4 Author: Milian Wolff m...@milianw.de Date: Mon May 18 10:52:29 2015 +0200 Fix compiler warning about potential truncation. klocalizedstring.cpp:1126:46: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of type 'int' which may cause truncation of value kls.d-number = static_castpluraln(abs(a)); ^ klocalizedstring.cpp:1126:46: note: use function 'std::abs' instead Diffs - src/klocalizedstring.cpp 910f44d Diff: https://git.reviewboard.kde.org/r/123867/diff/ Testing --- Thanks, Bhushan Shah ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
