Review Request 123867: Fix build on OSX clang and replace another abs with std::abs

2015-05-20 Thread Bhushan Shah 

---
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 
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_cast(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

Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.

2015-05-20 Thread Alex Richardson 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123857/#review80677
---



src/kbuildsycoca/kbuildsycoca.cpp (line 426)


`#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

Re: Review Request 123852: Optimize: Do not wipe dict cache when copying speller objects.

2015-05-20 Thread Kåre Särs 

---
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 123857: Fix crash after a user has launched kbuildsycoca as root.

2015-05-20 Thread David Edmundson 

---
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 123857: Fix crash after a user has launched kbuildsycoca as root.

2015-05-20 Thread David Edmundson 


> 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 123735: version of QmlObject with a static engine

2015-05-20 Thread Marco Martin 


> On May 20, 2015, 5:24 p.m., Vishesh Handa wrote:
> > src/quickaddons/quickviewsharedengine.h, line 41
> > 
> >
> > 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 123735: version of QmlObject with a static engine

2015-05-20 Thread Vishesh Handa 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123735/#review80669
---



src/quickaddons/quickviewsharedengine.h (line 41)


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 123861: Make KCodecs::base64Encode() RFC compliant

2015-05-20 Thread Aleix Pol Gonzalez 

---
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

2015-05-20 Thread David Edmundson 


> 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

Re: Review Request 123858: Fix memory leak in drags

2015-05-20 Thread David Edmundson 

---
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 123858: Fix memory leak in drags

2015-05-20 Thread David Edmundson 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123858/#review80659
---


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.

- David Edmundson


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

Review Request 123861: Make KCodecs::base64Encode() RFC compliant

2015-05-20 Thread Daniel Vrátil 

---
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 123857: Fix crash after a user has launched kbuildsycoca as root.

2015-05-20 Thread David Edmundson 


> 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.

2015-05-20 Thread Luigi Toscano 

---
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