[Differential] [Updated, 640 lines] D2854: New: ECMGenerateApiDox, for generating qch & tag files

[kossebau (Friedrich W. H. Kossebau)]

kossebau updated this revision to Diff 6979.
kossebau added a comment.


  Add alternative SOURCES, add IMAGE_DIRS, improve status messages

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2854?vs=6941=6979

BRANCH
  addGenerateApiDox

REVISION DETAIL
  https://phabricator.kde.org/D2854

AFFECTED FILES
  modules/ECMDoxygenQCH.config.in
  modules/ECMGenerateApiDox.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, staniek
Cc: staniek, winterz, ochurlaud, #kdevelop, #frameworks

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 311 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/311/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:26:52 +
Build duration: 3 min 31 sec

CHANGE SET
Revision cf8cf909383d09f44defafbfed3f8cb5c8c30878 by kainz.a: (update 16px 
mimetype colors)
  change: edit icons/mimetypes/16/application-vnd.ms-access.svg
  change: edit icons/mimetypes/16/application-pdf.svg
  change: edit icons/mimetypes/16/application-atom+xml.svg
  change: edit icons/mimetypes/16/application-illustrator.svg
  change: edit icons/mimetypes/16/application-epub+zip.svg
  change: edit icons/mimetypes/16/application-dicom.svg
  change: edit icons/mimetypes/16/application-msoutlook.svg
  change: edit icons/mimetypes/16/application-msonenote.svg
  change: edit icons/mimetypes/16/application-ogg.svg
  change: edit icons/mimetypes/16/android-package-archive.svg
  change: edit 
icons/mimetypes/16/application-vnd.ms-excel.template.macroenabled.12.svg
  change: edit icons/mimetypes/16/application-msword.svg
  change: edit 
icons/mimetypes/16/application-vnd.ms-excel.addin.macroenabled.12.svg
  change: edit icons/mimetypes/16/application-msword-template.svg
  change: edit icons/mimetypes/16/application-pgp-encrypted.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 308 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/308/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:26:52 +
Build duration: 2 min 11 sec

CHANGE SET
Revision cf8cf909383d09f44defafbfed3f8cb5c8c30878 by kainz.a: (update 16px 
mimetype colors)
  change: edit icons/mimetypes/16/application-msword.svg
  change: edit 
icons/mimetypes/16/application-vnd.ms-excel.template.macroenabled.12.svg
  change: edit icons/mimetypes/16/application-ogg.svg
  change: edit icons/mimetypes/16/application-illustrator.svg
  change: edit icons/mimetypes/16/application-epub+zip.svg
  change: edit icons/mimetypes/16/application-msword-template.svg
  change: edit icons/mimetypes/16/application-pgp-encrypted.svg
  change: edit icons/mimetypes/16/application-vnd.ms-access.svg
  change: edit icons/mimetypes/16/application-atom+xml.svg
  change: edit icons/mimetypes/16/application-msoutlook.svg
  change: edit 
icons/mimetypes/16/application-vnd.ms-excel.addin.macroenabled.12.svg
  change: edit icons/mimetypes/16/application-msonenote.svg
  change: edit icons/mimetypes/16/application-dicom.svg
  change: edit icons/mimetypes/16/android-package-archive.svg
  change: edit icons/mimetypes/16/application-pdf.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 310 - Still unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/310/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:13:52 +
Build duration: 4 min 20 sec

CHANGE SET
Revision 32ca75fbb3f9be5c3ca831a88f6f5cbd8267ec0d by kainz.a: (update 
folder_html link)
  change: edit icons/actions/22/folder-html.svg
  change: add icons-dark/actions/22/folder-html.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 307 - Still unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/307/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:13:41 +
Build duration: 4 min 18 sec

CHANGE SET
Revision 32ca75fbb3f9be5c3ca831a88f6f5cbd8267ec0d by kainz.a: (update 
folder_html link)
  change: add icons-dark/actions/22/folder-html.svg
  change: edit icons/actions/22/folder-html.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 309 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/309/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:13:03 +
Build duration: 27 sec

CHANGE SET
Revision 5a956ed75d7fbf7500b91b78d68ae7d084889227 by kainz.a: (sync symlinks 
between 64 and 32px mimetype)
  change: edit icons/mimetypes/32/application-x-mswrite.svg
  change: edit icons/mimetypes/32/application-x-kontour.svg

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 306 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/306/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:12:43 +
Build duration: 22 sec

CHANGE SET
Revision 5a956ed75d7fbf7500b91b78d68ae7d084889227 by kainz.a: (sync symlinks 
between 64 and 32px mimetype)
  change: edit icons/mimetypes/32/application-x-kontour.svg
  change: edit icons/mimetypes/32/application-x-mswrite.svg

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 308 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/308/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:11:21 +
Build duration: 27 sec

CHANGE SET
Revision edf383bf89a343e34a1606db884f324074837f45 by kainz.a: (update 32px 
mimetype)
  change: edit icons/mimetypes/32/image-x-tga.svg
  change: edit icons/mimetypes/32/text-x-qml.svg
  change: edit icons/mimetypes/32/audio-x-generic.svg
  change: edit icons/mimetypes/32/image-bmp.svg
  change: edit icons/mimetypes/32/image-x-xcf.svg
  change: edit icons/mimetypes/32/application-x-zerosize.svg
  change: edit icons/mimetypes/32/x-office-calendar.svg
  change: edit icons/mimetypes/32/audio-x-flac.svg
  change: edit icons/mimetypes/32/image-tiff.svg
  change: edit icons/mimetypes/32/application-x-rpm.svg
  change: edit icons/mimetypes/64/text-rtf.svg
  change: edit icons/mimetypes/32/application-x-bzip-compressed-tar.svg
  change: edit icons/mimetypes/32/audio-x-wav.svg
  change: edit icons/mimetypes/32/x-office-contact.svg
  change: edit icons/mimetypes/32/audio-x-mpeg.svg
  change: add icons/mimetypes/32/application-x-partial-download.svg
  change: edit icons/mimetypes/32/image-x-psd.svg
  change: edit icons/mimetypes/32/application-x-wmf.svg
  change: edit icons/mimetypes/64/image-tiff.svg
  change: edit icons/mimetypes/64/audio-x-flac.svg
  change: edit icons/mimetypes/32/text-rtf.svg
  change: edit icons/mimetypes/64/text-x-qml.svg
  change: edit icons/mimetypes/64/image-x-tga.svg
  change: edit icons/mimetypes/32/image-x-generic.svg
  change: edit icons/mimetypes/32/application-x-sharedlib.svg
  change: edit icons/mimetypes/32/application-x-rar.svg

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 305 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/305/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 23:11:21 +
Build duration: 28 sec

CHANGE SET
Revision edf383bf89a343e34a1606db884f324074837f45 by kainz.a: (update 32px 
mimetype)
  change: edit icons/mimetypes/32/application-x-bzip-compressed-tar.svg
  change: edit icons/mimetypes/32/image-x-generic.svg
  change: edit icons/mimetypes/32/image-x-psd.svg
  change: edit icons/mimetypes/32/text-rtf.svg
  change: edit icons/mimetypes/64/text-rtf.svg
  change: edit icons/mimetypes/32/application-x-rar.svg
  change: edit icons/mimetypes/32/x-office-calendar.svg
  change: edit icons/mimetypes/32/text-x-qml.svg
  change: edit icons/mimetypes/64/text-x-qml.svg
  change: edit icons/mimetypes/32/audio-x-flac.svg
  change: edit icons/mimetypes/32/image-x-xcf.svg
  change: edit icons/mimetypes/32/audio-x-generic.svg
  change: edit icons/mimetypes/32/application-x-zerosize.svg
  change: edit icons/mimetypes/32/image-bmp.svg
  change: edit icons/mimetypes/32/image-x-tga.svg
  change: edit icons/mimetypes/32/application-x-rpm.svg
  change: edit icons/mimetypes/64/image-tiff.svg
  change: edit icons/mimetypes/64/image-x-tga.svg
  change: edit icons/mimetypes/32/x-office-contact.svg
  change: edit icons/mimetypes/32/audio-x-mpeg.svg
  change: edit icons/mimetypes/32/image-tiff.svg
  change: edit icons/mimetypes/32/application-x-sharedlib.svg
  change: edit icons/mimetypes/32/audio-x-wav.svg
  change: edit icons/mimetypes/64/audio-x-flac.svg
  change: edit icons/mimetypes/32/application-x-wmf.svg
  change: add icons/mimetypes/32/application-x-partial-download.svg

Re: License header for test code also required

[Albert Astals Cid]

El divendres, 9 de setembre de 2016, a les 9:12:03 CEST, Ralf Habacker va 
escriure:
> Hi all,
> 
> umbrello supports code import for several compiler languages. To
> increase the code quality we are adding test code fragments to git
> source to motivate developers to use them for unit tests. The fragments
> looks like
> 
> https://quickgit.kde.org/?p=umbrello.git=blob=ee1411a1bfaa0c0376b4fff28d
> 45b9867cf2c053=13a513d629e86e8cc98d750f1d9e5741bbc8791a=test%2Fimport%2
> Fcxx%2Fcxx11-alternative-function-syntax.h
> 
> // https://en.wikipedia.org/wiki/C%2B%2B11#Alternative_function_syntax
> 
> // #1
> template
>   auto adding_func(const Lhs , const Rhs ) -> decltype(lhs+rhs)
> {return lhs + rhs;}
> 
> // #2
> struct SomeStruct  {
> auto func_name(int x, int y) -> int;
> };
> 
> auto SomeStruct::func_name(int x, int y) -> int {
> return x + y;
> }

Is that code being compiled?

Cheers,
  Albert

> 
> In the given example
> https://wikimediafoundation.org/wiki/Terms_of_Use#7._Licensing_of_Content
> states:
> 
> 
> "...When you re-use or re-distribute a text page developed by the
> Wikimedia community, you agree to attribute the authors in any of the
> following fashions: Through hyperlink (where possible) or URL to the
> page or pages that you are re-using (since each page has a history page
> that lists all authors and editors);"
> 
> Because the fragment contains a link to the related source it looks okay
> from my non-layers perspective.
> 
> On adding such test code I got an email about unknown license at
> https://mail.kde.org/pipermail/umbrello-devel/2016-September/020362.html.
> From the related page https://community.kde.org/Policies/Licensing_Policy I
> got the impression that this rule applies to real code compiled into a
> library or application. Is refering to the original source also okay in
> relation to this KDE license policy ?
> 
> Regards
>  Ralf

Re: Review Request 128922: Remove invalid directory from index.theme

[Aleix Pol Gonzalez]

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


Ship it!




Ship It!

- Aleix Pol Gonzalez


On Sept. 15, 2016, 6:25 p.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128922/
> ---
> 
> (Updated Sept. 15, 2016, 6:25 p.m.)
> 
> 
> Review request for KDE Frameworks and Andreas Kainz.
> 
> 
> Repository: oxygen-icons5
> 
> 
> Description
> ---
> 
> This removes the directory "base/" from index.theme. The presence of this 
> directory causes warnings like "Gtk-WARNING **: Theme directory base/ of 
> theme oxygen has no size field".
> 
> This is similar to RR 127839 for breeze-icons.
> 
> 
> Diffs
> -
> 
>   index.theme 2fc77f7 
> 
> Diff: https://git.reviewboard.kde.org/r/128922/diff/
> 
> 
> Testing
> ---
> 
> Warning disappears, oxygen icons still appear in a GTK application.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

Re: Review Request 128922: Remove invalid directory from index.theme

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On Sept. 15, 2016, 4:25 p.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128922/
> ---
> 
> (Updated Sept. 15, 2016, 4:25 p.m.)
> 
> 
> Review request for KDE Frameworks and Andreas Kainz.
> 
> 
> Repository: oxygen-icons5
> 
> 
> Description
> ---
> 
> This removes the directory "base/" from index.theme. The presence of this 
> directory causes warnings like "Gtk-WARNING **: Theme directory base/ of 
> theme oxygen has no size field".
> 
> This is similar to RR 127839 for breeze-icons.
> 
> 
> Diffs
> -
> 
>   index.theme 2fc77f7 
> 
> Diff: https://git.reviewboard.kde.org/r/128922/diff/
> 
> 
> Testing
> ---
> 
> Warning disappears, oxygen icons still appear in a GTK application.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 307 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/307/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 22:29:20 +
Build duration: 30 sec

CHANGE SET
Revision 22d8a3ffa5bec77c610879ec452ca19d49378506 by kainz.a: (update 
supernovae icon)
  change: edit icons/actions/22/kstars_supernovae.svg
  change: edit icons-dark/actions/22/kstars_supernovae.svg

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 304 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/304/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 22:29:20 +
Build duration: 28 sec

CHANGE SET
Revision 22d8a3ffa5bec77c610879ec452ca19d49378506 by kainz.a: (update 
supernovae icon)
  change: edit icons/actions/22/kstars_supernovae.svg
  change: edit icons-dark/actions/22/kstars_supernovae.svg

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 306 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/306/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 22:24:15 +
Build duration: 28 sec

CHANGE SET
Revision 63a0a3f2c2702c46c45d7d05414ededd54822e96 by kainz.a: (remove 
duplicated files (symlink) test 302)
  change: edit icons/actions/24/tool-pointer.svg
  change: edit icons/actions/24/dialog-xml-editor.svg
  change: edit icons-dark/actions/22/distribute-vertical-center.svg
  change: edit icons-dark/actions/24/distribute-randomize.svg
  change: edit icons/actions/22/kstars_supernovae.svg
  change: edit icons-dark/actions/22/containment.svg
  change: edit icons-dark/actions/24/tool-pointer.svg
  change: add icons/actions/22/folder-html.svg
  change: edit icons-dark/actions/24/format-node-curve.svg
  change: edit icons-dark/actions/22/arrow-left-double.svg
  change: edit icons-dark/actions/24/arrow-right-double.svg
  change: edit icons-dark/actions/16/globe.svg
  change: edit icons-dark/actions/24/mail-encrypted-full.svg
  change: edit icons/actions/22/containment.svg
  change: edit icons-dark/actions/22/arrow-right-double.svg
  change: edit icons-dark/actions/22/globe.svg
  change: edit icons/actions/22/archive-insert-directory.svg
  change: edit icons-dark/actions/24/text_subscript.svg
  change: edit icons-dark/actions/24/arrow-left-double.svg
  change: edit icons/status/symbolic/rating-unrated.svg
  change: edit icons/actions/24/archive-insert-directory.svg
  change: edit icons/actions/22/arrow-left-double.svg
  change: edit icons/actions/24/arrow-left-double.svg
  change: edit icons/actions/24/distribute-vertical-center.svg
  change: edit icons-dark/actions/22/kstars_supernovae.svg
  change: edit icons-dark/devices/22/input-mouse.svg
  change: edit icons-dark/actions/24/view-calendar.svg
  change: edit icons-dark/actions/32/help-donate.svg
  change: edit icons/actions/16/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/32/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/24/dialog-xml-editor.svg
  change: edit icons-dark/actions/22/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/22/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/22/kdenlive-add-text-clip.svg
  change: edit icons/actions/16/archive-insert-directory.svg
  change: edit icons-dark/actions/32/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/22/arrow-right-double.svg
  change: edit icons/devices/22/input-mouse.svg
  change: edit icons/actions/16/format-list-unordered.svg
  change: edit icons/actions/22/distribute-vertical-center.svg
  change: edit icons/actions/symbolic/selection-end-symbolic-rtl.svg
  change: edit icons/actions/24/arrow-right-double.svg
  change: edit icons-dark/actions/16/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/24/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/22/globe.svg
  change: edit icons-dark/actions/32/format-stroke-color.svg
  change: edit icons-dark/actions/22/kdenlive-add-text-clip.svg
  change: edit icons/actions/symbolic/pan-end-symbolic-rtl.svg
  change: add icons/devices/22/transform-browse.svg
  change: edit icons/actions/16/object-stroke.svg
  change: edit icons/actions/16/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/24/align-vertical-bottom-to-anchor.svg
  change: edit icons-dark/actions/16/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/32/editor.svg
  change: edit icons/actions/symbolic/selection-start-symbolic-rtl.svg
  change: edit icons/actions/24/text_subscript.svg
  change: edit icons-dark/actions/24/distribute-vertical-center.svg
  change: edit icons-dark/actions/24/autocorrection.svg
  change: edit icons-dark/actions/16/object-stroke.svg
  change: edit icons-dark/actions/16/distribute-vertical-center.svg
  change: edit icons/actions/16/globe.svg
  change: edit icons/actions/24/autocorrection.svg
  change: edit icons-dark/actions/16/format-list-unordered.svg
  change: edit icons-dark/actions/32/blurimage.svg
  change: edit icons/actions/24/mail-encrypted-full.svg
  change: edit icons-dark/actions/32/games-config-options.svg
  change: edit icons/actions/16/distribute-vertical-center.svg
  change: edit icons-dark/actions/32/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/32/help-keybord-shortcuts.svg
  change: edit icons/actions/24/view-web-browser-dom-tree.svg
  change: edit icons/actions/24/format-node-curve.svg

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 303 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/303/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 22:24:15 +
Build duration: 28 sec

CHANGE SET
Revision 63a0a3f2c2702c46c45d7d05414ededd54822e96 by kainz.a: (remove 
duplicated files (symlink) test 302)
  change: edit icons/actions/24/tool-pointer.svg
  change: edit icons-dark/actions/24/view-calendar.svg
  change: edit icons/actions/24/arrow-left-double.svg
  change: edit icons-dark/actions/24/text_subscript.svg
  change: edit icons/actions/22/archive-insert-directory.svg
  change: edit icons-dark/actions/24/arrow-right-double.svg
  change: edit icons-dark/actions/22/kstars_supernovae.svg
  change: edit icons-dark/actions/32/blurimage.svg
  change: edit icons/devices/22/input-mouse.svg
  change: edit icons-dark/actions/32/format-stroke-color.svg
  change: edit icons-dark/actions/22/arrow-left-double.svg
  change: edit icons/actions/16/distribute-vertical-center.svg
  change: edit icons/actions/24/view-web-browser-dom-tree.svg
  change: edit icons-dark/actions/24/arrow-left-double.svg
  change: edit icons/actions/symbolic/selection-end-symbolic-rtl.svg
  change: edit icons/actions/22/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/16/align-vertical-bottom-to-anchor.svg
  change: edit icons-dark/actions/24/dialog-xml-editor.svg
  change: add icons/actions/22/folder-html.svg
  change: edit icons/actions/22/kstars_supernovae.svg
  change: edit icons-dark/actions/22/distribute-vertical-center.svg
  change: edit icons/actions/22/globe.svg
  change: edit icons/actions/24/dialog-xml-editor.svg
  change: edit icons-dark/actions/16/globe.svg
  change: edit icons-dark/actions/22/globe.svg
  change: edit icons-dark/actions/22/arrow-right-double.svg
  change: edit icons-dark/actions/24/tool-pointer.svg
  change: edit icons/actions/24/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/22/kdenlive-add-text-clip.svg
  change: edit icons/actions/22/arrow-left-double.svg
  change: edit icons/actions/24/text_subscript.svg
  change: edit icons/actions/24/format-node-curve.svg
  change: edit icons-dark/actions/32/help-keybord-shortcuts.svg
  change: edit icons-dark/actions/22/containment.svg
  change: edit icons/actions/24/arrow-right-double.svg
  change: edit icons-dark/actions/24/format-node-curve.svg
  change: edit icons/actions/16/globe.svg
  change: edit icons/status/symbolic/rating-unrated.svg
  change: edit icons/actions/24/archive-insert-directory.svg
  change: edit icons-dark/actions/24/distribute-vertical-center.svg
  change: edit icons-dark/actions/32/align-vertical-bottom-to-anchor.svg
  change: edit icons/actions/symbolic/selection-start-symbolic-rtl.svg
  change: edit icons-dark/actions/16/align-vertical-bottom-to-anchor.svg
  change: edit icons-dark/actions/32/align-vertical-top-to-anchor.svg
  change: edit icons-dark/devices/22/input-mouse.svg
  change: edit icons-dark/actions/32/help-donate.svg
  change: edit icons/actions/16/archive-insert-directory.svg
  change: edit icons/actions/16/format-list-unordered.svg
  change: edit icons/actions/24/distribute-vertical-center.svg
  change: edit icons/actions/24/mail-encrypted-full.svg
  change: edit icons/actions/16/object-stroke.svg
  change: edit icons-dark/actions/32/games-config-options.svg
  change: edit icons/actions/32/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/24/distribute-randomize.svg
  change: edit icons-dark/actions/24/autocorrection.svg
  change: edit icons/actions/16/align-vertical-top-to-anchor.svg
  change: edit icons-dark/actions/24/mail-encrypted-full.svg
  change: edit icons/actions/24/autocorrection.svg
  change: edit icons-dark/actions/24/align-vertical-bottom-to-anchor.svg
  change: edit icons-dark/actions/16/object-stroke.svg
  change: edit icons-dark/actions/22/align-vertical-bottom-to-anchor.svg
  change: edit icons-dark/actions/16/distribute-vertical-center.svg
  change: edit icons/actions/22/distribute-vertical-center.svg
  change: edit icons/actions/symbolic/pan-end-symbolic-rtl.svg
  change: edit icons-dark/actions/32/editor.svg
  change: edit icons/actions/22/arrow-right-double.svg
  change: edit icons-dark/actions/16/format-list-unordered.svg
  change: add icons/devices/22/transform-browse.svg
  change: edit icons-dark/actions/16/align-vertical-top-to-anchor.svg
  change: edit icons/actions/22/containment.svg
  change: edit icons-dark/actions/22/kdenlive-add-text-clip.svg

Re: Scrap baloo?

[Andreas Hartmetz]

On Mittwoch, 28. September 2016 20:42:37 CEST Boudhayan Gupta wrote:
> Hi,
> 
> On 28 September 2016 at 20:33, Christoph Cullmann 
 wrote:
> > Hi,
> > 
> >> Hi,
> >> 
> >> On 28 September 2016 at 02:36, Christoph Cullmann 
 wrote:
> >>> any update?
> >> 
> >> Yep. In all the happennings of the week I just forgot to write this
> >> email.
> >> 
> >> If Baloo is going to be an integral part of the Plasma experience,
> >> do
> >> we really want to depend on an external project where we don't have
> >> control (and indeed, sentiments may prevent unrestricted
> >> contributions based only on merit). This is the political reason
> >> why I don't want to depend against Tracker. The technical reason
> >> is that it's based on SQLite, which is incredibly slow compared to
> >> what we do now.> 
> > I don't see really that it is slow compared to what we do, if you
> > have benchmarks for that, I would be pleased to see them.
> 
> So would I. You already have Tracker based code, could you spare some
> time and run some?
> 
> >> At the same time, LMDB needs to be replaced, and fast. I'm building
> >> a
> >> new KVDB as an university project (it should be able to do 256GB
> >> indexes on 32bit machines), and if that doesn't work out there's
> >> Sophia (http://sophia.systems/). I'll be evaluating both as a
> >> replacement to LMDB.
> > 
Any particular reason why you didn't consider leveldb? When I did 
research about databases for a work project (the application was using 
SQL / SQLite but didn't really need to), lmdb and leveldb were the clear 
leaders. 

Crash / power loss safety is also worth talking about - lmdb and SQLite 
are among the best of the embedded databases. leveldb is theoretically 
great because it only ever appends (and rewrites complete files and then 
replaces them), but file systems together with disks that say they wrote 
when they didn't make that somewhat susceptible to data loss.
Here is the most concise summary I could find - the same authors also 
have much more in-depth presentations, papers and other writeups.
http://docplayer.net/282512-Application-level-crash-consistency.html

> > Do we really want to maintain a own DB system?
> > IMHO that will never work out, all DB systems around need more
> > maintenance power than we have.
> 
> This is something I'm not sure about. The DB will be build anyway, my
> graduation depends on it :D And if I'm going to do something I will do
> it well, so it'll be simple and clean.
> 
> If it doesn't work out, there's always Sophia to fall back on.
> 
> >> Vishesh also wanted to separate out the engine and make it public
> >> API
> >> (apparently other projects want to make use of it as a general data
> >> storage library - and the engine offers fulltext search
> >> capabilities
> >> and other fancy logical operators that make it particularly
> >> attractive. My plan is to move towards that, and eventually also
> >> not
> >> only index files but also other kinds of objects - contacts, or
> >> people, for example.
> >> 
> >> I don't want to move back into the "semantic desktop" idea at all,
> >> but I do want some sort of infrastructure that allows for an
> >> "action on object" metaphor - file objects can be opened with an
> >> application, people objects can be sent mails, and so on.
> >> 
> >> Hope this makes sense.
> > 
> > I still not see how that should work out, atm, IMHO facts are:
> > 
> > 1) baloo is not maintained
> 
> It will, now.
> 
> > 2) lmdb will e.g. never work for us on NFS homes and the code needs
> > major overhaul to handle errors (which you confirm)
> 
> LMDB goes away, either way.
> 
> > 3) you said you have "some time" left to maintain it, but you now
> > propose in addition to maintain Baloo to write a DB system from
> > scratch, I don't really see that working
> I have a personal interest, an academic interest, and now a
> KDE-related interest in the KVDB. It *will* work, because I'm the kind
> of guy who puts a lot of time and effort into things (maybe even
> disproportionately so) into things that genuinely interest me. My
> challenge will be to make the codebase so that after I'm done with
> this (say in about 5 years or so) it'll be comprehensible to the next
> maintainer.
> 
> > 4) tracker on the other side is maintained and in use and we can
> > share the index data with GNOME and others
> > 
> > I really doubt that doing the work to remove lmdb, replace it with
> > an "own one" and then starting to fix all other issues (like
> > indexer running amok, broken file extractors, ...) will work out if
> > we don't clone some more people.
> > 
> > But that is only my opinion.
> 
> *Sigh*
> 
> I don't want to take the easy way out here. Half the fun in KDE is
> doing crazy things and seeing your baby work. That's the entire
> motivation for being here.
> 
> And right now I'm volunteering to do this.
> 
> -- Boudhayan

Review Request 129065: Fix frameworks compilation with Qt < 5.6

[David Edmundson]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

QQuickWindow::NoStage was new in Qt5.6. This uses a value that's valid
in earlier Qt.

This shouldn't have any behavioural effect.


Diffs
-

  src/declarativeimports/core/windowthumbnail.cpp 
0453c092f7a7144f04fdacc81b031e8c352fa23b 

Diff: https://git.reviewboard.kde.org/r/129065/diff/


Testing
---


Thanks,

David Edmundson

Re: Scrap baloo?

[Christoph Cullmann]

Hi,

first of all: I appreciate all your work and don't want to attack you 
personally in any way,
if my last mail felt that way, I am sorry!

> Hi,
> 
> On 28 September 2016 at 20:33, Christoph Cullmann  wrote:
>> Hi,
>>
>>> Hi,
>>>
>>> On 28 September 2016 at 02:36, Christoph Cullmann  
>>> wrote:
 any update?
>>>
>>> Yep. In all the happennings of the week I just forgot to write this email.
>>>
>>> If Baloo is going to be an integral part of the Plasma experience, do
>>> we really want to depend on an external project where we don't have
>>> control (and indeed, sentiments may prevent unrestricted contributions
>>> based only on merit). This is the political reason why I don't want to
>>> depend against Tracker. The technical reason is that it's based on
>>> SQLite, which is incredibly slow compared to what we do now.
>> I don't see really that it is slow compared to what we do, if you have
>> benchmarks
>> for that, I would be pleased to see them.
> 
> So would I. You already have Tracker based code, could you spare some
> time and run some?
Not really, I would not even known what to benchmark.
But if you have no benchmarks available, I am interested to know why there is 
that
idea we are that much faster? LMDB is fast, as key value storage, but we do
not just lookup a key but do a lot more on top, that means only because we use a
faster DB, we don't need to end up with faster overall performance than other 
solutions.

> 
>>> At the same time, LMDB needs to be replaced, and fast. I'm building a
>>> new KVDB as an university project (it should be able to do 256GB
>>> indexes on 32bit machines), and if that doesn't work out there's
>>> Sophia (http://sophia.systems/). I'll be evaluating both as a
>>> replacement to LMDB.
>> Do we really want to maintain a own DB system?
>> IMHO that will never work out, all DB systems around need more maintenance 
>> power
>> than we have.
> 
> This is something I'm not sure about. The DB will be build anyway, my
> graduation depends on it :D And if I'm going to do something I will do
> it well, so it'll be simple and clean.
I don't doubt that you are capable to write clean and working code.

The only problem is: there is a big difference between a academic implementation
and a product ready thing. Any existing key value database that is usable
for general consumption is a multi man year effort, even if you start today,
that is a solution we can use in some years, if at all.

Actually the most work is to handle all different environments and corner cases,
which is something that more or less can only be done by getting feedback
over several years, and I doubt we want to incubate a new DB in baloo as 
playground
on our user production machines.

> 
> If it doesn't work out, there's always Sophia to fall back on.
Sophia is again designed to be used in server environments, just from their 
start page:

"For server environment, which requires lowest latency access (both read and 
write), predictable behaviour, optimized storage schema and transaction 
guarantees."

This means, like lmdb, most likely (at least google doesn't tell that it will 
do it) real
usable for nfs (or other network) home mounts, which is very common on large 
scale installations.

(sophia doesn't get away to well after the opinion of the lmdb author, too: 
https://www.mail-archive.com/cyrus-devel@lists.andrew.cmu.edu/msg03653.html)

> 
>>> Vishesh also wanted to separate out the engine and make it public API
>>> (apparently other projects want to make use of it as a general data
>>> storage library - and the engine offers fulltext search capabilities
>>> and other fancy logical operators that make it particularly
>>> attractive. My plan is to move towards that, and eventually also not
>>> only index files but also other kinds of objects - contacts, or
>>> people, for example.
>>>
>>> I don't want to move back into the "semantic desktop" idea at all, but
>>> I do want some sort of infrastructure that allows for an "action on
>>> object" metaphor - file objects can be opened with an application,
>>> people objects can be sent mails, and so on.
>>>
>>> Hope this makes sense.
>> I still not see how that should work out, atm, IMHO facts are:
>>
>> 1) baloo is not maintained
> 
> It will, now.
> 
>> 2) lmdb will e.g. never work for us on NFS homes and the code needs major
>> overhaul
>> to handle errors (which you confirm)
> 
> LMDB goes away, either way.
> 
>> 3) you said you have "some time" left to maintain it, but you now propose in
>> addition to maintain
>> Baloo to write a DB system from scratch, I don't really see that working
> 
> I have a personal interest, an academic interest, and now a
> KDE-related interest in the KVDB. It *will* work, because I'm the kind
> of guy who puts a lot of time and effort into things (maybe even
> disproportionately so) into things that genuinely interest me. My
> challenge will be to make the codebase so that after I'm 

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 302 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/302/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 21:23:53 +
Build duration: 3 min 32 sec

CHANGE SET
Revision 252d30aa4a465aa5bc1cc6cc8ee7051c2b1face0 by kainz.a: (update 32px 
mimetype)
  change: edit icons/mimetypes/32/application-x-tarz.svg
  change: edit icons/mimetypes/32/application-x-lzma-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-lzop.svg
  change: edit icons/mimetypes/32/application-x-apple-diskimage.svg
  change: edit icons/mimetypes/32/application-x-arc.svg
  change: edit icons/mimetypes/32/application-x-blender.svg
  change: edit icons/mimetypes/32/application-x-ace.svg
  change: edit icons/mimetypes/32/application-x-pem-key.svg
  change: edit icons/mimetypes/32/package-x-generic.svg
  change: edit icons/mimetypes/32/application-x-desktop.svg
  change: edit icons/mimetypes/32/application-x-tzo.svg
  change: edit icons/mimetypes/32/application-x-ar.svg
  change: edit icons/mimetypes/32/application-x-bzip-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-cda.svg
  change: edit icons/mimetypes/32/application-x-tar.svg
  change: edit icons/mimetypes/32/application-x-deb.svg
  change: edit icons/mimetypes/32/application-x-java.svg
  change: edit icons/mimetypes/32/application-x-bzdvi.svg
  change: edit icons/mimetypes/32/application-x-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-gzip.svg
  change: edit icons/mimetypes/32/application-x-cd-image.svg
  change: edit icons/mimetypes/32/application-x-bzip.svg
  change: edit icons/mimetypes/32/application-x-arj.svg
  change: edit icons/mimetypes/32/application-x-java-archive.svg
  change: edit icons/mimetypes/32/application-zip.svg
  change: edit icons/mimetypes/32/application-x-gzpostscript.svg
  change: edit icons/mimetypes/32/application-vnd.visio.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 305 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/305/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 21:24:58 +
Build duration: 2 min 10 sec

CHANGE SET
Revision 252d30aa4a465aa5bc1cc6cc8ee7051c2b1face0 by kainz.a: (update 32px 
mimetype)
  change: edit icons/mimetypes/32/package-x-generic.svg
  change: edit icons/mimetypes/32/application-x-blender.svg
  change: edit icons/mimetypes/32/application-x-cd-image.svg
  change: edit icons/mimetypes/32/application-x-tzo.svg
  change: edit icons/mimetypes/32/application-x-desktop.svg
  change: edit icons/mimetypes/32/application-x-tar.svg
  change: edit icons/mimetypes/32/application-x-arj.svg
  change: edit icons/mimetypes/32/application-x-ar.svg
  change: edit icons/mimetypes/32/application-x-java.svg
  change: edit icons/mimetypes/32/application-x-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-bzip.svg
  change: edit icons/mimetypes/32/application-x-bzdvi.svg
  change: edit icons/mimetypes/32/application-x-apple-diskimage.svg
  change: edit icons/mimetypes/32/application-x-pem-key.svg
  change: edit icons/mimetypes/32/application-zip.svg
  change: edit icons/mimetypes/32/application-x-deb.svg
  change: edit icons/mimetypes/32/application-x-gzip.svg
  change: edit icons/mimetypes/32/application-x-ace.svg
  change: edit icons/mimetypes/32/application-x-lzma-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-gzpostscript.svg
  change: edit icons/mimetypes/32/application-x-bzip-compressed-tar.svg
  change: edit icons/mimetypes/32/application-x-lzop.svg
  change: edit icons/mimetypes/32/application-vnd.visio.svg
  change: edit icons/mimetypes/32/application-x-java-archive.svg
  change: edit icons/mimetypes/32/application-x-arc.svg
  change: edit icons/mimetypes/32/application-x-tarz.svg
  change: edit icons/mimetypes/32/application-x-cda.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Re: Review Request 128749: Backport karchive fix for out of directory files

[Albert Astals Cid]

> On Sept. 7, 2016, 9:49 a.m., Sebastian Kügler wrote:
> > This patch seems to have caused a regression when installing some wallpaper 
> > packages, Marco fixed it in the knewstuff frameworks with 
> > 39b33ddd1e21c017b. We may have a problem now -- we'll have to fix Plasma 4? 
> > :/
> 
> Albert Astals Cid wrote:
> a quick look on that commit, how is related to this one? they seem to be 
> touching different parts of the code
> 
> Sebastian Kügler wrote:
> Wallpaper packages were unzipped into the parent directory instead of 
> creating a subdirectory for the wallpaper. This commit caused this 
> regression, Marco's commit fixed it in knewstuff. (It should be relatively 
> easy to test, try installing my "Borneo Pink" wallpaper from the wallpaper 
> dialog in Plasma and look into ~/.local/share/wallpapers/ directory (with and 
> without patches).
> 
> Albert Astals Cid wrote:
> I'm going to be away from a computer for almost 3 weeks, make sure you 
> cotnact Andreas/David off this site (it's easy to ignore comments on already 
> submitted reviews) if they don't answer to try to get this fixed.

Was there any progress on this front?


- Albert


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


On Aug. 25, 2016, 10:34 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128749/
> ---
> 
> (Updated Aug. 25, 2016, 10:34 p.m.)
> 
> 
> Review request for kdelibs, Andreas Cord-Landwehr and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> What the summary says
> 
> 
> Diffs
> -
> 
>   kdecore/io/karchive.cpp eb0bf2e 
>   kdecore/tests/karchivetest.h e64e0ed 
>   kdecore/tests/karchivetest.cpp 7786b98 
> 
> Diff: https://git.reviewboard.kde.org/r/128749/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 304 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/304/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 21:18:43 +
Build duration: 3 min 33 sec

CHANGE SET
Revision e08ee01bed07b294569770ddf49db55583217f6a by kainz.a: (update some 64px 
mime)
  change: edit icons/mimetypes/64/text-x-pascal.svg
  change: edit icons/mimetypes/64/application-vnd.visio.svg
  change: edit icons/mimetypes/64/application-x-font-otf.svg
  change: edit icons/mimetypes/64/application-x-cd-image.svg
  change: edit icons/mimetypes/64/application-x-perl.svg
  change: edit icons/mimetypes/64/application-msoutlook.svg
  change: edit icons/mimetypes/64/message-partial.svg
  change: edit icons/mimetypes/64/application-x-rpm.svg
  change: edit icons/mimetypes/64/application-x-gzpostscript.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Re: Scrap baloo?

[Christoph Cullmann]

Hi,

> Generally speaking, in terms of Plasma feedback, Baloo doesn't come up
> /that/ much.
> I'm sure there's stuff in the bug tracker, but we don't have the big public
> problem that we used to have.
> 
> I think your problems are exagerrated because of the NFS mount.
> 
> The only problem we have is the runner bringing down the shell when we have
> the corrupt database - and from the comments above, that should be
> catchable.
You can catch that, by rewriting all current code, as there is no error 
handling,
but yes, that is true. One can write lmdb code that handles corrupted DBs and
catch all error cases. lmdb is no bad database in that aspect.

> 
> 
> 
> Questions:
> 
> Tracker doesn't look at xattrs at all.
> 
> At which point we would need to think about migration.
> 
> This is possibly solvable with a patch in tracker. The tracker maintainer
> (in 2014) sounds like he would be in support of it: https://mail.gnome.org/
> archives/tracker-list/2014-September/msg00045.html
> and there is a writeback module in tracker.
A one way migration would be to write a tracker "miner" (if don't use the wrong 
word)
and move the tags into the tracker tag db, or what you cite above.

> 
> -
> 
> A sizable part of your argument is based on problems with NFS . SQlite
> (that tracker uses) will surely have the same problems.
> Surely If file locks don't work, then file locks don't work?
Not file locks in itself are the problem (at least not on recent NFS versions),
but that mmap won't work like you want. As long as the locks work, sqlite should
behave better. And tracker seems to handle corruption better, which is as said
above possible for us, too, if we rewrite all code.

> 
> -
> 
> A big reason tracker seems faster/smaller than baloo is that it only
> indexes the main XDG folders: Documents/Music/Pictures/Downloads by
> default.
> Would you change that?
Actually: No idea. Perhaps such a default is better for the "normal" user,
perhaps not, but actually which folders are indexed is a indexer independent
debate I think.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 301 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/301/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 21:18:43 +
Build duration: 2 min 20 sec

CHANGE SET
Revision e08ee01bed07b294569770ddf49db55583217f6a by kainz.a: (update some 64px 
mime)
  change: edit icons/mimetypes/64/text-x-pascal.svg
  change: edit icons/mimetypes/64/application-x-font-otf.svg
  change: edit icons/mimetypes/64/application-msoutlook.svg
  change: edit icons/mimetypes/64/application-x-perl.svg
  change: edit icons/mimetypes/64/application-x-gzpostscript.svg
  change: edit icons/mimetypes/64/application-x-rpm.svg
  change: edit icons/mimetypes/64/application-vnd.visio.svg
  change: edit icons/mimetypes/64/application-x-cd-image.svg
  change: edit icons/mimetypes/64/message-partial.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Re: Scrap baloo?

[Dominik Haumann]

On Wed, Sep 28, 2016 at 7:09 PM, David Edmundson
 wrote:
> Generally speaking, in terms of Plasma feedback, Baloo doesn't come up
> /that/ much.
> I'm sure there's stuff in the bug tracker, but we don't have the big public
> problem that we used to have.
>
> I think your problems are exagerrated because of the NFS mount.

I don't think this discussion is really that much about NFS mounts.
NFS mounts are just one issue among many.

The most pressing issues are entirely missing error handling in baloo,
which was already brought up in previous mails the last weeks.

See:
- 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED_id=1390073=frameworks-baloo_format=advanced
- 
https://bugs.kde.org/reports.cgi?product=frameworks-baloo=show_chart=ASSIGNED=REOPENED=UNCONFIRMED=CONFIRMED

Out of these bugs, 49 are crashes, and probably not all easy to fix -
Christoph already fixed some and triaged 200 bugs, so I also think he
knows what he is talking about :-)

> The only problem we have is the runner bringing down the shell when we have
> the corrupt database - and from the comments above, that should be
> catchable.

I sent a mail to plasma-devel some weeks ago, mentioning that baloo is
in a bad shape.

If you want stability in Plasma, we / you need to fix baloo - and not
by writing an own DB or other experiments. This is about getting
things done.

Greetings
Dominik

Re: Scrap baloo?

[Dominik Haumann]

Hi,

On Wed, Sep 28, 2016 at 4:52 PM, Boudhayan Gupta  wrote:
> On 28 September 2016 at 02:36, Christoph Cullmann  wrote:
>> any update?
>
> Yep. In all the happennings of the week I just forgot to write this email.
>
> If Baloo is going to be an integral part of the Plasma experience, do

It already is. And that's exactly why we have this discussion. If you
look into baloo's bug tracker, almost *all* of the bugs are critical
crashes, and even of a kind that some people cannot use the desktop
anymore.

> we really want to depend on an external project where we don't have
> control (and indeed, sentiments may prevent unrestricted contributions
> based only on merit). This is the political reason why I don't want to
> depend against Tracker. The technical reason is that it's based on
> SQLite, which is incredibly slow compared to what we do now.
>
> At the same time, LMDB needs to be replaced, and fast.

Interestingly, this is not even necessarily the case: In NFS mounts,
sysadmins typically do not *want* an index, since it spams the network
load a lot. So not having it in an NFS environment is not the worst
option.

Further, 32 bit is going away. While the 1GB limit is not nice at all,
it's as simple as also not providing baloo there in case the db is
full. Given that most users are 64 bit meanwhile, this is not really
an issue. Still these are weak arguments for LMDB.

> I'm building a
> new KVDB as an university project (it should be able to do 256GB
> indexes on 32bit machines), and if that doesn't work out there's
> Sophia (http://sophia.systems/). I'll be evaluating both as a
> replacement to LMDB.

The reason why I bothered writing a mail is exactly this paragraph.

You also state that being able to do something crazy motivates you,
and that's the best motivation you could ever have :-) This is how KDE
came to life, and why it still lives today.

But trust me, writing a database on your own is neither easy nor
quickly done, and most certainly an issue maintainability wise.

Given we are looking for a solution now (in fact, better yesterday),
Christophs proposal is not that far away.

And: we can still switch away from tracker, think of it as a backend.
And in fact, I also believe that a shared index across desktops is a
nice-to-have. What we would need to agree on is probably that baloo is
a linux-only (?) framework then, but I guess that would possibly even
be fine.

Greetings
Dominik

Re: Scrap baloo?

[Dāvis Mosāns]

What about using already existing solutions for indexing and storage?
like for example there are projects:

* Apache Lucene - https://lucene.apache.org/
* Apache Solr - https://lucene.apache.org/solr/  (it's built on top of Lucene)
* ElasticSearch - https://www.elastic.co/
* Xapian - https://xapian.org/

these all are search engines and isn't that Baloo's goal to index
files and search them...
I'm just throwing this idea about using something already meant for
such purpose.
For example, for my use case currently I've like ~20TB of data
(documents, photos, audio, video) and I want to index and search them
all.

Re: Review Request 128916: kconfig: Make test XFAIL when running as root

[David Faure]

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


Ship it!




Ship It!

- David Faure


On Sept. 19, 2016, 6:14 p.m., Evgeniy Sadovnik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128916/
> ---
> 
> (Updated Sept. 19, 2016, 6:14 p.m.)
> 
> 
> Review request for KDE Frameworks and Gleb Popov.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> The test checks that saving a read-only config file fails. But because root 
> can write into read-only files, the test is failing when running by root.
> Check for uid when running the test and make it XFAIL if we are running as 
> root.
> 
> 
> Diffs
> -
> 
>   autotests/kconfigtest.cpp 2b905b5 
> 
> Diff: https://git.reviewboard.kde.org/r/128916/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Evgeniy Sadovnik
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Hrvoje Senjan]

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




src/declarativeimports/core/windowthumbnail.cpp (line 231)


This is added in Qt 5.6, but:
set (REQUIRED_QT_VERSION "5.3.0")
which is also wrong.


- Hrvoje Senjan


On Sept. 3, 2016, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Sept. 3, 2016, 10:33 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128910: [kio_trash] Fill in UDS_LOCAL_PATH in UDSEntry

[David Faure]

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



I'm very afraid of side effects of this.

For instance, deleting the file will do a direct deletion using the local path, 
not using kio_trash, and therefore leaving the .trashinfo file lying around 
(and not updating the total size usage of the trash).

And more such unwanted side effects.

Do we really need previews of folders in the trash? How about we disable that, 
rather?

- David Faure


On Sept. 14, 2016, 6:02 p.m., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128910/
> ---
> 
> (Updated Sept. 14, 2016, 6:02 p.m.)
> 
> 
> Review request for KDE Runtime, KDE Frameworks and David Faure.
> 
> 
> Bugs: 208625, 272249, 329155, and 368104
> https://bugs.kde.org/show_bug.cgi?id=208625
> https://bugs.kde.org/show_bug.cgi?id=272249
> https://bugs.kde.org/show_bug.cgi?id=329155
> https://bugs.kde.org/show_bug.cgi?id=368104
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Not doing so results in PreviewJob assuming the files/folders are remote and 
> copying them to /tmp when generating previews.
> This is especially annoying and dangerous if there are large folders in the 
> trash.
> 
> KDE4's kio_trash in kde-runtime has the same problem, as the code is 
> basically the same, the same patch fixes it too.
> 
> 
> Diffs
> -
> 
>   src/ioslaves/trash/kio_trash.cpp 3810941 
> 
> Diff: https://git.reviewboard.kde.org/r/128910/diff/
> 
> 
> Testing
> ---
> 
> Trash some files/folders, open dolphin, navigate to trash:/, and hover over 
> them.
> Previews are still generated (if enabled), and the files/folders are not 
> copied to /tmp any more.
> 
> Also tried with files on an USB stick, where a folder .Trash-XXX is used as 
> trash.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Jenkins-kde-ci: syntax-highlighting master kf5-qt5 » Linux,gcc - Build # 1 - Successful!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/syntax-highlighting%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/1/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 19:48:24 +
Build duration: 2 min 41 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 32/34 (94%)CLASSES 32/34 (94%)LINE 1867/2186 
(85%)CONDITIONAL 1407/2022 (70%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 386/392 (98%)CONDITIONAL 
226/400 (57%)
src.indexer
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 53/71 (75%)CONDITIONAL 
73/92 (79%)
src.lib
FILES 24/26 (92%)CLASSES 24/26 (92%)LINE 1428/1723 
(83%)CONDITIONAL 1108/1530 (72%)

Re: Scrap baloo?

[Jos van den Oever]

On Wednesday 28 September 2016 18:09:12 David Edmundson wrote:
> A sizable part of your argument is based on problems with NFS . SQlite
> (that tracker uses) will surely have the same problems.
> Surely If file locks don't work, then file locks don't work?

CLucene does not have the same problem. It has files to which it appends. Once 
the files grow too large, they are merged into a new one, but the old ones 
remain available as long as they are used by an IndexReader.

As to the idea of pluggable indexes, that is what Strigi uses. It adds 
development overhead, but the tests can be shared.

Cheers,
Jos

Re: Scrap baloo?

[David Edmundson]

On Wed, Sep 28, 2016 at 4:03 PM, Christoph Cullmann 
wrote:

> Hi,
>
> > Hi,
> >
> > On 28 September 2016 at 02:36, Christoph Cullmann 
> wrote:
> >> any update?
> >
> > Yep. In all the happennings of the week I just forgot to write this
> email.
> >
> > If Baloo is going to be an integral part of the Plasma experience, do
> > we really want to depend on an external project where we don't have
> > control (and indeed, sentiments may prevent unrestricted contributions
> > based only on merit). This is the political reason why I don't want to
> > depend against Tracker. The technical reason is that it's based on
> > SQLite, which is incredibly slow compared to what we do now.
> I don't see really that it is slow compared to what we do, if you have
> benchmarks
> for that, I would be pleased to see them.
>
> >
> > At the same time, LMDB needs to be replaced, and fast. I'm building a
> > new KVDB as an university project (it should be able to do 256GB
> > indexes on 32bit machines), and if that doesn't work out there's
> > Sophia (http://sophia.systems/). I'll be evaluating both as a
> > replacement to LMDB.
> Do we really want to maintain a own DB system?
> IMHO that will never work out, all DB systems around need more maintenance
> power
> than we have.
>
> >
> > Vishesh also wanted to separate out the engine and make it public API
> > (apparently other projects want to make use of it as a general data
> > storage library - and the engine offers fulltext search capabilities
> > and other fancy logical operators that make it particularly
> > attractive. My plan is to move towards that, and eventually also not
> > only index files but also other kinds of objects - contacts, or
> > people, for example.
> >
> > I don't want to move back into the "semantic desktop" idea at all, but
> > I do want some sort of infrastructure that allows for an "action on
> > object" metaphor - file objects can be opened with an application,
> > people objects can be sent mails, and so on.
> >
> > Hope this makes sense.
> I still not see how that should work out, atm, IMHO facts are:
>
> 1) baloo is not maintained
> 2) lmdb will e.g. never work for us on NFS homes and the code needs major
> overhaul
> to handle errors (which you confirm)
> 3) you said you have "some time" left to maintain it, but you now propose
> in addition to maintain
> Baloo to write a DB system from scratch, I don't really see that working
> 4) tracker on the other side is maintained and in use and we can share the
> index data with GNOME and others
>
> I really doubt that doing the work to remove lmdb, replace it with an "own
> one" and then starting
> to fix all other issues (like indexer running amok, broken file
> extractors, ...) will work out if
> we don't clone some more people.
>
> But that is only my opinion.
>

Generally speaking, in terms of Plasma feedback, Baloo doesn't come up
/that/ much.
I'm sure there's stuff in the bug tracker, but we don't have the big public
problem that we used to have.

I think your problems are exagerrated because of the NFS mount.

The only problem we have is the runner bringing down the shell when we have
the corrupt database - and from the comments above, that should be
catchable.



Questions:

Tracker doesn't look at xattrs at all.

At which point we would need to think about migration.

This is possibly solvable with a patch in tracker. The tracker maintainer
(in 2014) sounds like he would be in support of it: https://mail.gnome.org/
archives/tracker-list/2014-September/msg00045.html
and there is a writeback module in tracker.

-

A sizable part of your argument is based on problems with NFS . SQlite
(that tracker uses) will surely have the same problems.
Surely If file locks don't work, then file locks don't work?

-

A big reason tracker seems faster/smaller than baloo is that it only
indexes the main XDG folders: Documents/Music/Pictures/Downloads by
default.
Would you change that?

Re: Scrap baloo?

[Boudhayan Gupta]

Hi,

On 28 September 2016 at 20:33, Christoph Cullmann  wrote:
> Hi,
>
>> Hi,
>>
>> On 28 September 2016 at 02:36, Christoph Cullmann  
>> wrote:
>>> any update?
>>
>> Yep. In all the happennings of the week I just forgot to write this email.
>>
>> If Baloo is going to be an integral part of the Plasma experience, do
>> we really want to depend on an external project where we don't have
>> control (and indeed, sentiments may prevent unrestricted contributions
>> based only on merit). This is the political reason why I don't want to
>> depend against Tracker. The technical reason is that it's based on
>> SQLite, which is incredibly slow compared to what we do now.
> I don't see really that it is slow compared to what we do, if you have 
> benchmarks
> for that, I would be pleased to see them.

So would I. You already have Tracker based code, could you spare some
time and run some?

>> At the same time, LMDB needs to be replaced, and fast. I'm building a
>> new KVDB as an university project (it should be able to do 256GB
>> indexes on 32bit machines), and if that doesn't work out there's
>> Sophia (http://sophia.systems/). I'll be evaluating both as a
>> replacement to LMDB.
> Do we really want to maintain a own DB system?
> IMHO that will never work out, all DB systems around need more maintenance 
> power
> than we have.

This is something I'm not sure about. The DB will be build anyway, my
graduation depends on it :D And if I'm going to do something I will do
it well, so it'll be simple and clean.

If it doesn't work out, there's always Sophia to fall back on.

>> Vishesh also wanted to separate out the engine and make it public API
>> (apparently other projects want to make use of it as a general data
>> storage library - and the engine offers fulltext search capabilities
>> and other fancy logical operators that make it particularly
>> attractive. My plan is to move towards that, and eventually also not
>> only index files but also other kinds of objects - contacts, or
>> people, for example.
>>
>> I don't want to move back into the "semantic desktop" idea at all, but
>> I do want some sort of infrastructure that allows for an "action on
>> object" metaphor - file objects can be opened with an application,
>> people objects can be sent mails, and so on.
>>
>> Hope this makes sense.
> I still not see how that should work out, atm, IMHO facts are:
>
> 1) baloo is not maintained

It will, now.

> 2) lmdb will e.g. never work for us on NFS homes and the code needs major 
> overhaul
> to handle errors (which you confirm)

LMDB goes away, either way.

> 3) you said you have "some time" left to maintain it, but you now propose in 
> addition to maintain
> Baloo to write a DB system from scratch, I don't really see that working

I have a personal interest, an academic interest, and now a
KDE-related interest in the KVDB. It *will* work, because I'm the kind
of guy who puts a lot of time and effort into things (maybe even
disproportionately so) into things that genuinely interest me. My
challenge will be to make the codebase so that after I'm done with
this (say in about 5 years or so) it'll be comprehensible to the next
maintainer.

> 4) tracker on the other side is maintained and in use and we can share the 
> index data with GNOME and others
>
> I really doubt that doing the work to remove lmdb, replace it with an "own 
> one" and then starting
> to fix all other issues (like indexer running amok, broken file extractors, 
> ...) will work out if
> we don't clone some more people.
>
> But that is only my opinion.

*Sigh*

I don't want to take the easy way out here. Half the fun in KDE is
doing crazy things and seeing your baby work. That's the entire
motivation for being here.

And right now I'm volunteering to do this.

-- Boudhayan

Re: Review Request 128831: Check whether kwallet is enabled in Wallet::isOpen(name)

[Elvis Angelaccio]

> On Sept. 24, 2016, 12:40 p.m., Elvis Angelaccio wrote:
> > src/api/KWallet/kwallet.cpp, line 366
> > 
> >
> > You should probably use isEnabled() instead, in case someone is using 
> > ksecretservice (though m_walletEnabled is already used all over the 
> > place)...
> > 
> > Anyway +1
> 
> Wolfgang Bauer wrote:
> This is inside the non-ksecretservice codepath, so it makes no difference 
> whether one uses m_walletEnabled or isEnabled() (not to mention that I think 
> the distinction is not even necessary in isEnabled(), AFAICS m_walletEnabled 
> is set accordingly in the ksecretservice case too).
> 
> And as you write the check is like that everywhere else in the code.
> I don't think it makes sense to deviate here in this one method, if 
> that's desirable it should be changed everywhere in a separate commit IMHO.
> 
> In case you mean that the check should be done using isEnabled() right at 
> the start of the method (i.e. before the if):
> I'm not sure this check is needed at all in the ksecretservice case, 
> there is no ->getInterface().xxx call that could crash.
> 
> KWalletDLauncher does check whether the wallet is enabled and just 
> returns if not without doing anything. This means it doesn't start the 
> KWallet service in the non-ksecretservice, that's what causes the mentioned 
> crash in the first place because a nullptr is dereferenced.
> 
> I don't know anything about ksecretservice, but the code here probably 
> will return false in case the wallet is disabled anyway (at least that's my 
> feeling after looking at this code).
> 
> Elvis Angelaccio wrote:
> > This is inside the non-ksecretservice codepath, so it makes no 
> difference whether one uses m_walletEnabled or isEnabled() (not to mention 
> that I think the distinction is not even necessary in isEnabled(), AFAICS 
> m_walletEnabled is set accordingly in the ksecretservice case too).
> And as you write the check is like that everywhere else in the code.
> I don't think it makes sense to deviate here in this one method, if 
> that's desirable it should be changed everywhere in a separate commit IMHO.
> 
> It probably makes more sense, yes. Ignore my comment then :)
> 
> Elvis Angelaccio wrote:
> Meanwhile I realized that the ksecretservice code path is broken, so 
> there is no way that someone is using it.
> 
> Wolfgang Bauer wrote:
> So, can/shall I commit this then?
> 
> I do think it gives a somewhat bad impression of our software if even the 
> crash reporter crashes... ;-)

Feel free to commit if no one says otherwise before the tagging day (next 
Saturday) :)


- Elvis


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


On Sept. 4, 2016, 9:20 p.m., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128831/
> ---
> 
> (Updated Sept. 4, 2016, 9:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Valentin Rusu.
> 
> 
> Bugs: 358260
> https://bugs.kde.org/show_bug.cgi?id=358260
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> If kwallet is disabled, walletlauncher() fails and 
> walletLauncher()->getInterface().isOpen(name) causes a crash.
> This affects e.g. drkonqi, but probably also other applications.
> 
> Return false in this case, if kwallet is disabled a wallet cannot be open 
> either.
> 
> 
> Diffs
> -
> 
>   src/api/KWallet/kwallet.cpp dffebda 
> 
> Diff: https://git.reviewboard.kde.org/r/128831/diff/
> 
> 
> Testing
> ---
> 
> - disable kwallet in the settings
> - start a KF5 application (say, dolphin)
> - make it crash, e.g. via "killall -ILL dolphin"
> - try to report the crash with drkonqi
> 
> When you get to the page where you have to enter the bugzilla 
> username/password, drkonqi crashed, with this patch it doesn't crash.
> 
> drkonqi is also still able to get the username/password from kwallet if it is 
> enabled.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Re: Scrap baloo?

[Christoph Cullmann]

Hi,

> Hi,
> 
> On 28 September 2016 at 02:36, Christoph Cullmann  wrote:
>> any update?
> 
> Yep. In all the happennings of the week I just forgot to write this email.
> 
> If Baloo is going to be an integral part of the Plasma experience, do
> we really want to depend on an external project where we don't have
> control (and indeed, sentiments may prevent unrestricted contributions
> based only on merit). This is the political reason why I don't want to
> depend against Tracker. The technical reason is that it's based on
> SQLite, which is incredibly slow compared to what we do now.
I don't see really that it is slow compared to what we do, if you have 
benchmarks
for that, I would be pleased to see them.

> 
> At the same time, LMDB needs to be replaced, and fast. I'm building a
> new KVDB as an university project (it should be able to do 256GB
> indexes on 32bit machines), and if that doesn't work out there's
> Sophia (http://sophia.systems/). I'll be evaluating both as a
> replacement to LMDB.
Do we really want to maintain a own DB system?
IMHO that will never work out, all DB systems around need more maintenance power
than we have.

> 
> Vishesh also wanted to separate out the engine and make it public API
> (apparently other projects want to make use of it as a general data
> storage library - and the engine offers fulltext search capabilities
> and other fancy logical operators that make it particularly
> attractive. My plan is to move towards that, and eventually also not
> only index files but also other kinds of objects - contacts, or
> people, for example.
> 
> I don't want to move back into the "semantic desktop" idea at all, but
> I do want some sort of infrastructure that allows for an "action on
> object" metaphor - file objects can be opened with an application,
> people objects can be sent mails, and so on.
> 
> Hope this makes sense.
I still not see how that should work out, atm, IMHO facts are:

1) baloo is not maintained
2) lmdb will e.g. never work for us on NFS homes and the code needs major 
overhaul
to handle errors (which you confirm)
3) you said you have "some time" left to maintain it, but you now propose in 
addition to maintain
Baloo to write a DB system from scratch, I don't really see that working
4) tracker on the other side is maintained and in use and we can share the 
index data with GNOME and others

I really doubt that doing the work to remove lmdb, replace it with an "own one" 
and then starting
to fix all other issues (like indexer running amok, broken file extractors, 
...) will work out if 
we don't clone some more people.

But that is only my opinion.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: Review Request 128910: [kio_trash] Fill in UDS_LOCAL_PATH in UDSEntry

[Wolfgang Bauer]

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



Ping?

This can really cause bad problems and should be fixed ASAP IMHO, even if the 
problems exist since years.

- Wolfgang Bauer


On Sept. 14, 2016, 8:02 nachm., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128910/
> ---
> 
> (Updated Sept. 14, 2016, 8:02 nachm.)
> 
> 
> Review request for KDE Runtime, KDE Frameworks and David Faure.
> 
> 
> Bugs: 208625, 272249, 329155, and 368104
> https://bugs.kde.org/show_bug.cgi?id=208625
> https://bugs.kde.org/show_bug.cgi?id=272249
> https://bugs.kde.org/show_bug.cgi?id=329155
> https://bugs.kde.org/show_bug.cgi?id=368104
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Not doing so results in PreviewJob assuming the files/folders are remote and 
> copying them to /tmp when generating previews.
> This is especially annoying and dangerous if there are large folders in the 
> trash.
> 
> KDE4's kio_trash in kde-runtime has the same problem, as the code is 
> basically the same, the same patch fixes it too.
> 
> 
> Diffs
> -
> 
>   src/ioslaves/trash/kio_trash.cpp 3810941 
> 
> Diff: https://git.reviewboard.kde.org/r/128910/diff/
> 
> 
> Testing
> ---
> 
> Trash some files/folders, open dolphin, navigate to trash:/, and hover over 
> them.
> Previews are still generated (if enabled), and the files/folders are not 
> copied to /tmp any more.
> 
> Also tried with files on an USB stick, where a folder .Trash-XXX is used as 
> trash.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Re: Review Request 128831: Check whether kwallet is enabled in Wallet::isOpen(name)

[Wolfgang Bauer]

> On Sept. 24, 2016, 2:40 nachm., Elvis Angelaccio wrote:
> > src/api/KWallet/kwallet.cpp, line 366
> > 
> >
> > You should probably use isEnabled() instead, in case someone is using 
> > ksecretservice (though m_walletEnabled is already used all over the 
> > place)...
> > 
> > Anyway +1
> 
> Wolfgang Bauer wrote:
> This is inside the non-ksecretservice codepath, so it makes no difference 
> whether one uses m_walletEnabled or isEnabled() (not to mention that I think 
> the distinction is not even necessary in isEnabled(), AFAICS m_walletEnabled 
> is set accordingly in the ksecretservice case too).
> 
> And as you write the check is like that everywhere else in the code.
> I don't think it makes sense to deviate here in this one method, if 
> that's desirable it should be changed everywhere in a separate commit IMHO.
> 
> In case you mean that the check should be done using isEnabled() right at 
> the start of the method (i.e. before the if):
> I'm not sure this check is needed at all in the ksecretservice case, 
> there is no ->getInterface().xxx call that could crash.
> 
> KWalletDLauncher does check whether the wallet is enabled and just 
> returns if not without doing anything. This means it doesn't start the 
> KWallet service in the non-ksecretservice, that's what causes the mentioned 
> crash in the first place because a nullptr is dereferenced.
> 
> I don't know anything about ksecretservice, but the code here probably 
> will return false in case the wallet is disabled anyway (at least that's my 
> feeling after looking at this code).
> 
> Elvis Angelaccio wrote:
> > This is inside the non-ksecretservice codepath, so it makes no 
> difference whether one uses m_walletEnabled or isEnabled() (not to mention 
> that I think the distinction is not even necessary in isEnabled(), AFAICS 
> m_walletEnabled is set accordingly in the ksecretservice case too).
> And as you write the check is like that everywhere else in the code.
> I don't think it makes sense to deviate here in this one method, if 
> that's desirable it should be changed everywhere in a separate commit IMHO.
> 
> It probably makes more sense, yes. Ignore my comment then :)
> 
> Elvis Angelaccio wrote:
> Meanwhile I realized that the ksecretservice code path is broken, so 
> there is no way that someone is using it.

So, can/shall I commit this then?

I do think it gives a somewhat bad impression of our software if even the crash 
reporter crashes... ;-)


- Wolfgang


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


On Sept. 4, 2016, 11:20 nachm., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128831/
> ---
> 
> (Updated Sept. 4, 2016, 11:20 nachm.)
> 
> 
> Review request for KDE Frameworks and Valentin Rusu.
> 
> 
> Bugs: 358260
> https://bugs.kde.org/show_bug.cgi?id=358260
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> If kwallet is disabled, walletlauncher() fails and 
> walletLauncher()->getInterface().isOpen(name) causes a crash.
> This affects e.g. drkonqi, but probably also other applications.
> 
> Return false in this case, if kwallet is disabled a wallet cannot be open 
> either.
> 
> 
> Diffs
> -
> 
>   src/api/KWallet/kwallet.cpp dffebda 
> 
> Diff: https://git.reviewboard.kde.org/r/128831/diff/
> 
> 
> Testing
> ---
> 
> - disable kwallet in the settings
> - start a KF5 application (say, dolphin)
> - make it crash, e.g. via "killall -ILL dolphin"
> - try to report the crash with drkonqi
> 
> When you get to the page where you have to enter the bugzilla 
> username/password, drkonqi crashed, with this patch it doesn't crash.
> 
> drkonqi is also still able to get the username/password from kwallet if it is 
> enabled.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Re: Scrap baloo?

[Boudhayan Gupta]

Hi,

On 28 September 2016 at 02:36, Christoph Cullmann  wrote:
> any update?

Yep. In all the happennings of the week I just forgot to write this email.

If Baloo is going to be an integral part of the Plasma experience, do
we really want to depend on an external project where we don't have
control (and indeed, sentiments may prevent unrestricted contributions
based only on merit). This is the political reason why I don't want to
depend against Tracker. The technical reason is that it's based on
SQLite, which is incredibly slow compared to what we do now.

At the same time, LMDB needs to be replaced, and fast. I'm building a
new KVDB as an university project (it should be able to do 256GB
indexes on 32bit machines), and if that doesn't work out there's
Sophia (http://sophia.systems/). I'll be evaluating both as a
replacement to LMDB.

Vishesh also wanted to separate out the engine and make it public API
(apparently other projects want to make use of it as a general data
storage library - and the engine offers fulltext search capabilities
and other fancy logical operators that make it particularly
attractive. My plan is to move towards that, and eventually also not
only index files but also other kinds of objects - contacts, or
people, for example.

I don't want to move back into the "semantic desktop" idea at all, but
I do want some sort of infrastructure that allows for an "action on
object" metaphor - file objects can be opened with an application,
people objects can be sent mails, and so on.

Hope this makes sense.

Thanks,
Boudhayan

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[David Edmundson]

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



+1

though I'd suggest to wait till the start of the next frameworks cycle before 
merging.

- David Edmundson


On Sept. 28, 2016, 1:41 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129057/
> ---
> 
> (Updated Sept. 28, 2016, 1:41 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> I've been looking into what we're actually doing nowadays when we learn about 
> a plasmoid at boot. I realized that we were doing a bit of a roundabout and 
> there's definitely shorter paths.
> 
> As far as I understood, what we're doing is:
> 
> 1. We list all plugins and construct their KPluginMetaData
> 2. We get the metadata file path and send it to corona, that will create a 
> KService::Ptr and then construct a KPluginInfo from it.
> 3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
> parsing the files twice
> 3.1. using KPluginMetaData
> 3.2. using KDesktopFileParser
> 
> This patch, tries to simplify 2 and 3 into a KPluginMetaData construction 
> call.
> 
> Furthermore, this will allow us eventually (in a separate iteration, and 
> everything works according to the plan) to load plugins from metadata.json 
> which would make it possible to get rid of the internal usage of the 
> desktopfileparser within kcoreaddons. (With something like this 
> https://paste.kde.org/pth9wmasc)
> 
> 
> Diffs
> -
> 
>   src/plasma/applet.h 449f761 
>   src/plasma/applet.cpp 5e278dc 
>   src/plasma/containment.cpp 803887d 
>   src/plasma/private/applet_p.h c3fe1d2 
>   src/plasma/private/applet_p.cpp 0f37fe5 
>   src/plasma/private/storage.cpp 8983128 
>   src/plasma/scripting/appletscript.cpp 42c0395 
>   src/plasmaquick/appletquickitem.cpp 95695d5 
>   src/plasmaquick/configview.cpp b6ef7ac 
>   src/scriptengines/qml/plasmoid/appletinterface.cpp 466dbd8 
> 
> Diff: https://git.reviewboard.kde.org/r/129057/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass, plasmashell starts beautifully.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[Aleix Pol Gonzalez]

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

(Updated Sept. 28, 2016, 3:41 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

oops


Repository: plasma-framework


Description
---

I've been looking into what we're actually doing nowadays when we learn about a 
plasmoid at boot. I realized that we were doing a bit of a roundabout and 
there's definitely shorter paths.

As far as I understood, what we're doing is:

1. We list all plugins and construct their KPluginMetaData
2. We get the metadata file path and send it to corona, that will create a 
KService::Ptr and then construct a KPluginInfo from it.
3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
parsing the files twice
3.1. using KPluginMetaData
3.2. using KDesktopFileParser

This patch, tries to simplify 2 and 3 into a KPluginMetaData construction call.

Furthermore, this will allow us eventually (in a separate iteration, and 
everything works according to the plan) to load plugins from metadata.json 
which would make it possible to get rid of the internal usage of the 
desktopfileparser within kcoreaddons. (With something like this 
https://paste.kde.org/pth9wmasc)


Diffs (updated)
-

  src/plasma/applet.h 449f761 
  src/plasma/applet.cpp 5e278dc 
  src/plasma/containment.cpp 803887d 
  src/plasma/private/applet_p.h c3fe1d2 
  src/plasma/private/applet_p.cpp 0f37fe5 
  src/plasma/private/storage.cpp 8983128 
  src/plasma/scripting/appletscript.cpp 42c0395 
  src/plasmaquick/appletquickitem.cpp 95695d5 
  src/plasmaquick/configview.cpp b6ef7ac 
  src/scriptengines/qml/plasmoid/appletinterface.cpp 466dbd8 

Diff: https://git.reviewboard.kde.org/r/129057/diff/


Testing
---

Tests still pass, plasmashell starts beautifully.


Thanks,

Aleix Pol Gonzalez

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[Aleix Pol Gonzalez]

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

(Updated Sept. 28, 2016, 3:31 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Address issues.


Repository: plasma-framework


Description
---

I've been looking into what we're actually doing nowadays when we learn about a 
plasmoid at boot. I realized that we were doing a bit of a roundabout and 
there's definitely shorter paths.

As far as I understood, what we're doing is:

1. We list all plugins and construct their KPluginMetaData
2. We get the metadata file path and send it to corona, that will create a 
KService::Ptr and then construct a KPluginInfo from it.
3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
parsing the files twice
3.1. using KPluginMetaData
3.2. using KDesktopFileParser

This patch, tries to simplify 2 and 3 into a KPluginMetaData construction call.

Furthermore, this will allow us eventually (in a separate iteration, and 
everything works according to the plan) to load plugins from metadata.json 
which would make it possible to get rid of the internal usage of the 
desktopfileparser within kcoreaddons. (With something like this 
https://paste.kde.org/pth9wmasc)


Diffs (updated)
-

  src/plasma/applet.h 449f761 
  src/plasma/applet.cpp 5e278dc 
  src/plasma/containment.cpp 803887d 
  src/plasma/corona.cpp 7ff64cd 
  src/plasma/private/applet_p.h c3fe1d2 
  src/plasma/private/applet_p.cpp 0f37fe5 
  src/plasma/private/storage.cpp 8983128 
  src/plasma/scripting/appletscript.cpp 42c0395 
  src/plasmaquick/appletquickitem.cpp 95695d5 
  src/plasmaquick/configview.cpp b6ef7ac 
  src/scriptengines/qml/plasmoid/appletinterface.cpp 466dbd8 

Diff: https://git.reviewboard.kde.org/r/129057/diff/


Testing (updated)
---

Tests still pass, plasmashell starts beautifully.


Thanks,

Aleix Pol Gonzalez

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[Aleix Pol Gonzalez]

> On Sept. 28, 2016, 11:10 a.m., Marco Martin wrote:
> > src/plasma/applet.cpp, line 92
> > 
> >
> > don't we have already a kpluginmetadata, built in the private ctor?

I guess? I'm trying not to change the logic too much for the moment. If you 
think it can go, I'll drop it.


- Aleix


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


On Sept. 28, 2016, 4:44 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129057/
> ---
> 
> (Updated Sept. 28, 2016, 4:44 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> I've been looking into what we're actually doing nowadays when we learn about 
> a plasmoid at boot. I realized that we were doing a bit of a roundabout and 
> there's definitely shorter paths.
> 
> As far as I understood, what we're doing is:
> 
> 1. We list all plugins and construct their KPluginMetaData
> 2. We get the metadata file path and send it to corona, that will create a 
> KService::Ptr and then construct a KPluginInfo from it.
> 3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
> parsing the files twice
> 3.1. using KPluginMetaData
> 3.2. using KDesktopFileParser
> 
> This patch, tries to simplify 2 and 3 into a KPluginMetaData construction 
> call.
> 
> Furthermore, this will allow us eventually (in a separate iteration, and 
> everything works according to the plan) to load plugins from metadata.json 
> which would make it possible to get rid of the internal usage of the 
> desktopfileparser within kcoreaddons. (With something like this 
> https://paste.kde.org/pth9wmasc)
> 
> 
> Diffs
> -
> 
>   src/plasma/applet.h 449f761 
>   src/plasma/applet.cpp 5e278dc 
>   src/plasma/private/applet_p.h c3fe1d2 
>   src/plasma/private/applet_p.cpp 0f37fe5 
>   src/plasma/scripting/appletscript.cpp 42c0395 
> 
> Diff: https://git.reviewboard.kde.org/r/129057/diff/
> 
> 
> Testing
> ---
> 
> My `plasmashell` starts beautifully, `CoronaTest::startupCompletion` doesn't 
> for some reason I need to investigate further, but yes it's that late.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: Review Request 129059: Use correct config entry in autostart condition

[David Edmundson]

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

(Updated Sept. 28, 2016, 11:46 a.m.)


Status
--

This change has been marked as submitted.


Review request for Baloo.


Changes
---

Submitted with commit e73849e052c1a2ca174efe18d4a4958c6576fc33 by David 
Edmundson to branch master.


Repository: baloo


Description
---

Balooctl and the KCMs write the config entry "Indexing-Enabled" not just
"Enabled"

This saves baloo launching when it is only going to immediately quit
again anyway.


Diffs
-

  src/file/baloo_file.desktop d79000cb9b367d490955350af38331e022dd981e 

Diff: https://git.reviewboard.kde.org/r/129059/diff/


Testing
---


Thanks,

David Edmundson

Re: Review Request 129059: Use correct config entry in autostart condition

[Rohan Garg]

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


Ship it!




LGTM

- Rohan Garg


On Sept. 28, 2016, 5:11 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129059/
> ---
> 
> (Updated Sept. 28, 2016, 5:11 p.m.)
> 
> 
> Review request for Baloo.
> 
> 
> Repository: baloo
> 
> 
> Description
> ---
> 
> Balooctl and the KCMs write the config entry "Indexing-Enabled" not just
> "Enabled"
> 
> This saves baloo launching when it is only going to immediately quit
> again anyway.
> 
> 
> Diffs
> -
> 
>   src/file/baloo_file.desktop d79000cb9b367d490955350af38331e022dd981e 
> 
> Diff: https://git.reviewboard.kde.org/r/129059/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Review Request 129059: Use correct config entry in autostart condition

[David Edmundson]

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

Review request for Baloo.


Repository: baloo


Description
---

Balooctl and the KCMs write the config entry "Indexing-Enabled" not just
"Enabled"

This saves baloo launching when it is only going to immediately quit
again anyway.


Diffs
-

  src/file/baloo_file.desktop d79000cb9b367d490955350af38331e022dd981e 

Diff: https://git.reviewboard.kde.org/r/129059/diff/


Testing
---


Thanks,

David Edmundson

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 300 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/300/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 10:56:25 +
Build duration: 6 min 33 sec

CHANGE SET
Revision ac53f0f1cc73644819ca777495bb43567f90c620 by alessandro.longo: (Updated 
some mimetypes with new colors at 32 and 64px)
  change: edit icons/mimetypes/32/application-vnd.iccprofile.svg
  change: edit icons/mimetypes/32/application-x-krita.svg
  change: edit icons/mimetypes/32/text-x-c++hdr.svg
  change: edit icons/mimetypes/32/libreoffice-drawing.svg
  change: edit icons/mimetypes/32/application-x-php.svg
  change: edit icons/mimetypes/32/application-x-executable.svg
  change: edit icons/mimetypes/32/text-html.svg
  change: edit icons/mimetypes/32/text-x-chdr.svg
  change: edit icons/mimetypes/32/application-x-ruby.svg
  change: edit icons/mimetypes/32/text-x-csrc.svg
  change: edit icons/mimetypes/64/application-x-bittorrent.svg
  change: edit 
icons/mimetypes/32/application-vnd.oasis.opendocument.database.svg
  change: edit icons/mimetypes/32/application-x-bittorrent.svg
  change: edit icons/mimetypes/32/application-x-ms-dos-executable.svg
  change: edit icons/mimetypes/32/text-x-c++src.svg
  change: edit icons/mimetypes/32/text-xml.svg
  change: edit icons/mimetypes/32/image-gif.svg
  change: edit icons/mimetypes/32/image-x-vnd.trolltech.qpicture.svg
  change: edit icons/mimetypes/32/image-svg+xml-compressed.svg
  change: edit icons/mimetypes/32/text-css.svg
  change: edit icons/mimetypes/32/application-x-tgif.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 303 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/303/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 28 Sep 2016 10:56:25 +
Build duration: 5 min 47 sec

CHANGE SET
Revision ac53f0f1cc73644819ca777495bb43567f90c620 by alessandro.longo: (Updated 
some mimetypes with new colors at 32 and 64px)
  change: edit icons/mimetypes/32/image-gif.svg
  change: edit icons/mimetypes/32/application-x-bittorrent.svg
  change: edit icons/mimetypes/32/application-x-ms-dos-executable.svg
  change: edit icons/mimetypes/32/application-x-executable.svg
  change: edit 
icons/mimetypes/32/application-vnd.oasis.opendocument.database.svg
  change: edit icons/mimetypes/32/text-html.svg
  change: edit icons/mimetypes/32/text-x-c++src.svg
  change: edit icons/mimetypes/32/text-x-csrc.svg
  change: edit icons/mimetypes/32/application-x-tgif.svg
  change: edit icons/mimetypes/32/text-xml.svg
  change: edit icons/mimetypes/32/text-css.svg
  change: edit icons/mimetypes/32/application-x-krita.svg
  change: edit icons/mimetypes/32/image-svg+xml-compressed.svg
  change: edit icons/mimetypes/32/text-x-c++hdr.svg
  change: edit icons/mimetypes/32/application-x-php.svg
  change: edit icons/mimetypes/32/application-x-ruby.svg
  change: edit icons/mimetypes/64/application-x-bittorrent.svg
  change: edit icons/mimetypes/32/libreoffice-drawing.svg
  change: edit icons/mimetypes/32/text-x-chdr.svg
  change: edit icons/mimetypes/32/application-vnd.iccprofile.svg
  change: edit icons/mimetypes/32/image-x-vnd.trolltech.qpicture.svg


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.dupe

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 105/132 
(80%)CONDITIONAL 46/78 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 63/75 (84%)CONDITIONAL 
32/52 (62%)

Re: Review Request 128437: raise to core dump handlers when drkonqi is done

[Harald Sitter]

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

(Updated Sept. 28, 2016, 1:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 85eef3241e45a0f1799069fa687f68ed9f802ef9 by Harald Sitter 
to branch master.


Repository: kcrash


Description
---

with the rise of useful core dump handlers such as systemd's coredump and
ubuntu's apport it is no longer useful to handle things exclusively in
drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
putting the entire flow of information on us.

the new behavior instead checks if a core pattern executable is set and if
so re-raises the signal so the kernel jumps in and invokes the handler.

(this unfortunately means that the core will contain our kcrash frames,
but that seems hardly avoidable)


Diffs
-

  CMakeLists.txt 21ccd1df72f6ab2e60bb3f8f9212359f1c24c53f 
  autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
  autotests/core_patterns/exec PRE-CREATION 
  autotests/core_patterns/no-exec PRE-CREATION 
  autotests/coreconfigtest.cpp PRE-CREATION 
  src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
  src/config-kcrash.h.cmake f1b3a9babda3e2220aed3c19b735f90eb1ea8e7e 
  src/coreconfig.cpp PRE-CREATION 
  src/coreconfig_p.h PRE-CREATION 
  src/kcrash.cpp d9acb591edb2232db6c9e0dc2726cf0f189823a0 

Diff: https://git.reviewboard.kde.org/r/128437/diff/


Testing
---

builds and passes


Thanks,

Harald Sitter

Re: Review Request 128437: raise to core dump handlers when drkonqi is done

[Marco Martin]

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


Ship it!




Ship It!

- Marco Martin


On Sept. 28, 2016, 10:36 a.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128437/
> ---
> 
> (Updated Sept. 28, 2016, 10:36 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcrash
> 
> 
> Description
> ---
> 
> with the rise of useful core dump handlers such as systemd's coredump and
> ubuntu's apport it is no longer useful to handle things exclusively in
> drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
> putting the entire flow of information on us.
> 
> the new behavior instead checks if a core pattern executable is set and if
> so re-raises the signal so the kernel jumps in and invokes the handler.
> 
> (this unfortunately means that the core will contain our kcrash frames,
> but that seems hardly avoidable)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 21ccd1df72f6ab2e60bb3f8f9212359f1c24c53f 
>   autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
>   autotests/core_patterns/exec PRE-CREATION 
>   autotests/core_patterns/no-exec PRE-CREATION 
>   autotests/coreconfigtest.cpp PRE-CREATION 
>   src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
>   src/config-kcrash.h.cmake f1b3a9babda3e2220aed3c19b735f90eb1ea8e7e 
>   src/coreconfig.cpp PRE-CREATION 
>   src/coreconfig_p.h PRE-CREATION 
>   src/kcrash.cpp d9acb591edb2232db6c9e0dc2726cf0f189823a0 
> 
> Diff: https://git.reviewboard.kde.org/r/128437/diff/
> 
> 
> Testing
> ---
> 
> builds and passes
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

Re: Review Request 128437: raise to core dump handlers when drkonqi is done

[Harald Sitter]

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

(Updated Sept. 28, 2016, 10:36 a.m.)


Review request for KDE Frameworks.


Changes
---

discussed this a bit on IRC.

Given the fact that integrators might not wish to raise to a core handler we'll 
have a cmake option for this.
Presently the suggested rollout is that we'll have the raising disabled by 
default for 2 releases (opt-in) and then switched on by default (opt-out) so 
integrators can disable the re-raising if they either find it useless or 
counter productive to UX (e.g. handler UI conflicting with drkonqi UI).

This ultimately renders this a policy decision. Either one raises into the 
kernel and resolves potential UI conflicts by building better integration (e.g. 
https://community.kde.org/Kubuntu/QA/Whoopsie) or by simply not installing 
drkonqi to disable our UI, or one doesn't raise into the kernel and only uses 
drkonqi.

>From a platform POV it is more suitable for us to default to raising as this 
>is the default behavior one would expect from a crashing application on posix 
>systems. Small concession here is that we will not raise core file dumps (i.e. 
>without handler process) to make it harder to litter the users hard disk with 
>core dumps (I may be convinced that this should be an option though, currently 
>no one presented a use case for this).


Repository: kcrash


Description
---

with the rise of useful core dump handlers such as systemd's coredump and
ubuntu's apport it is no longer useful to handle things exclusively in
drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
putting the entire flow of information on us.

the new behavior instead checks if a core pattern executable is set and if
so re-raises the signal so the kernel jumps in and invokes the handler.

(this unfortunately means that the core will contain our kcrash frames,
but that seems hardly avoidable)


Diffs (updated)
-

  CMakeLists.txt 21ccd1df72f6ab2e60bb3f8f9212359f1c24c53f 
  autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
  autotests/core_patterns/exec PRE-CREATION 
  autotests/core_patterns/no-exec PRE-CREATION 
  autotests/coreconfigtest.cpp PRE-CREATION 
  src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
  src/config-kcrash.h.cmake f1b3a9babda3e2220aed3c19b735f90eb1ea8e7e 
  src/coreconfig.cpp PRE-CREATION 
  src/coreconfig_p.h PRE-CREATION 
  src/kcrash.cpp d9acb591edb2232db6c9e0dc2726cf0f189823a0 

Diff: https://git.reviewboard.kde.org/r/128437/diff/


Testing
---

builds and passes


Thanks,

Harald Sitter

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[Kai Uwe Broulik]

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




src/plasma/applet.h (line 274)


@deprecated since and explain what to do instead


- Kai Uwe Broulik


On Sept. 28, 2016, 2:44 vorm., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129057/
> ---
> 
> (Updated Sept. 28, 2016, 2:44 vorm.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> I've been looking into what we're actually doing nowadays when we learn about 
> a plasmoid at boot. I realized that we were doing a bit of a roundabout and 
> there's definitely shorter paths.
> 
> As far as I understood, what we're doing is:
> 
> 1. We list all plugins and construct their KPluginMetaData
> 2. We get the metadata file path and send it to corona, that will create a 
> KService::Ptr and then construct a KPluginInfo from it.
> 3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
> parsing the files twice
> 3.1. using KPluginMetaData
> 3.2. using KDesktopFileParser
> 
> This patch, tries to simplify 2 and 3 into a KPluginMetaData construction 
> call.
> 
> Furthermore, this will allow us eventually (in a separate iteration, and 
> everything works according to the plan) to load plugins from metadata.json 
> which would make it possible to get rid of the internal usage of the 
> desktopfileparser within kcoreaddons. (With something like this 
> https://paste.kde.org/pth9wmasc)
> 
> 
> Diffs
> -
> 
>   src/plasma/applet.h 449f761 
>   src/plasma/applet.cpp 5e278dc 
>   src/plasma/private/applet_p.h c3fe1d2 
>   src/plasma/private/applet_p.cpp 0f37fe5 
>   src/plasma/scripting/appletscript.cpp 42c0395 
> 
> Diff: https://git.reviewboard.kde.org/r/129057/diff/
> 
> 
> Testing
> ---
> 
> My `plasmashell` starts beautifully, `CoronaTest::startupCompletion` doesn't 
> for some reason I need to investigate further, but yes it's that late.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: KDE.org Modernization

[Ben Cooksley]

On Wed, Sep 28, 2016 at 3:00 AM, aayush arora  wrote:
> Hi all,

Hi Lays, Aayush,

>  Thanks, Lays Rodrigues.
>  I am Aayush Arora, I am doing front-end development from past three years.
> I have worked with Fossasia as a Google Summer of Code student this year. I
> will suggest making kde.org completely responsive that supports all
> platforms. Kde.org seems to be a representation of KDE data. Hence, I can
> suggest working with Angular.js to make it a Single Page Application which
> will be fast as compared to the current website ( without reloading of pages
> ) , also using Bootstrap ( Responsive Web design framework) can help to
> complete the work easily.
> I will love to be a part of this, developers who maintain kde.org can help
> and provide suggestions.

Can I suggest raising this on kde-...@kde.org?
I think there were a couple of people (Ingo? Jens? Oliver?) who had
made discussions around this already.

There may have been a session at Akademy/QtCon about this, although
i'm not sure if that ended up happening.

> Thanks

Cheers,
Ben

>
> Aayush Arora
> Google Summer Of Code 2016, Fossasia
> B.tech , Information Technology
> JSS ACADEMY OF TECHNICAL EDUCATION ,NOIDA
> Linkedin , Github
>
> On Tue, Sep 27, 2016 at 6:56 PM, Lays Rodrigues
>  wrote:
>>
>> Hello guys, everything ok?
>> Last night I tried to read the KDE dot story about the KDE Advisor Board
>> on my smartphone and was very hard since kde.org isn't friend mobile.
>> For me, the KDE pages look like too static, and a dynamism could be a good
>> way to present KDE and make easy the life of the people that access the site
>> to find the information that they need.
>> A few weeks ago an ex GSoC student from Fossassia, Aayush Arora, reached
>> me out on facebook and asked me how he could contribute to KDE, and his
>> skills are with web development.
>> I'm a newbie in web development, so I don't know how hard would be to make
>> this port to a modern website for KDE, or even if the community would be
>> opened to it.
>> So that is the why that I'm writing this email =D
>> What do you think? People that works on the kde.org could give their
>> opinions?
>> It's just an idea...
>> --
>> Lays Rodrigues
>> Software Developer at KDE
>> Computer Science Student at Federal Fluminense University
>> laysrodriguesdev.wordpress.com
>> Telegram: @lays147
>> IRC: lays147
>> Phone: +55 22 999899467
>
>

Re: kdereview

[Ben Cooksley]

On Wed, Sep 28, 2016 at 9:06 AM, Allen Winter  wrote:
> On Tuesday, September 27, 2016 09:20:32 PM Burkhard Lück wrote:
>> Am Mittwoch, 21. September 2016, 11:01:18 CEST schrieb Allen Winter:
>> > I suggest we remove bodega-client, kdev-perforce, kdots, kor and kpeg from
>> > kde_projects.xml and virtually move them into scratch.
>>
>> Any objections to move bodega-client, kdev-perforce, kdots, kor and kpeg to
>> unmaintained?
>>
> kdev-perforce should be moved into kdevplatform or kdevelop/plugins or 
> somesuch.
> I asked Ben to do that last week.  Not sure if that has been done yet.

I haven't moved it, as I was under the impression the repository was
defacto dead, as it's code had been merged into kdevplatform.
Not sure if the repository was going to be mothballed or deleted once
KDevPlatform 5.1 was released though.

>
> I have heard nothing about bodega-client, kdots, kor, kpeg since my initial 
> inquiry.
>

Cheers,
Ben

Re: Review Request 129057: RFC: Make sense out of Plasma plugin metadata loading

[Marco Martin]

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



still not ready, but big +1 as it was one of those old todo items that always 
get delayed for something being more urgent :)


src/plasma/applet.h (line 276)


not in favor of not having an official way to access metadata from an 
instance, at least a new metadata() method should be introduced



src/plasma/applet.cpp (line 63)


deprecate this as well?



src/plasma/applet.cpp (line 92)


don't we have already a kpluginmetadata, built in the private ctor?



src/plasma/private/applet_p.h (line 49)


since this is a private, it can even be removed, once its usage is cleared


- Marco Martin


On Sept. 28, 2016, 2:44 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129057/
> ---
> 
> (Updated Sept. 28, 2016, 2:44 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> I've been looking into what we're actually doing nowadays when we learn about 
> a plasmoid at boot. I realized that we were doing a bit of a roundabout and 
> there's definitely shorter paths.
> 
> As far as I understood, what we're doing is:
> 
> 1. We list all plugins and construct their KPluginMetaData
> 2. We get the metadata file path and send it to corona, that will create a 
> KService::Ptr and then construct a KPluginInfo from it.
> 3. KPluginInfo in turn parses the file again. Since recently KPluginInfo is 
> parsing the files twice
> 3.1. using KPluginMetaData
> 3.2. using KDesktopFileParser
> 
> This patch, tries to simplify 2 and 3 into a KPluginMetaData construction 
> call.
> 
> Furthermore, this will allow us eventually (in a separate iteration, and 
> everything works according to the plan) to load plugins from metadata.json 
> which would make it possible to get rid of the internal usage of the 
> desktopfileparser within kcoreaddons. (With something like this 
> https://paste.kde.org/pth9wmasc)
> 
> 
> Diffs
> -
> 
>   src/plasma/applet.h 449f761 
>   src/plasma/applet.cpp 5e278dc 
>   src/plasma/private/applet_p.h c3fe1d2 
>   src/plasma/private/applet_p.cpp 0f37fe5 
>   src/plasma/scripting/appletscript.cpp 42c0395 
> 
> Diff: https://git.reviewboard.kde.org/r/129057/diff/
> 
> 
> Testing
> ---
> 
> My `plasmashell` starts beautifully, `CoronaTest::startupCompletion` doesn't 
> for some reason I need to investigate further, but yes it's that late.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: Review Request 128437: raise to core dump handlers when drkonqi is done

[Marco Martin]

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



+1 from me as well.
maybe the distributions need to adapt, on out level this makes sense

- Marco Martin


On July 13, 2016, 12:40 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128437/
> ---
> 
> (Updated July 13, 2016, 12:40 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcrash
> 
> 
> Description
> ---
> 
> with the rise of useful core dump handlers such as systemd's coredump and
> ubuntu's apport it is no longer useful to handle things exclusively in
> drkonqi. it bypasses sysadmins as well as distros in debugging efforts,
> putting the entire flow of information on us.
> 
> the new behavior instead checks if a core pattern executable is set and if
> so re-raises the signal so the kernel jumps in and invokes the handler.
> 
> (this unfortunately means that the core will contain our kcrash frames,
> but that seems hardly avoidable)
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt e442520269835df71968bf7818aa34bd8bd945cf 
>   autotests/core_patterns/exec PRE-CREATION 
>   autotests/core_patterns/no-exec PRE-CREATION 
>   autotests/coreconfigtest.cpp PRE-CREATION 
>   src/CMakeLists.txt e733be69c6ca6e6c1a0608c8910cf4a9b52ffcc9 
>   src/coreconfig.cpp PRE-CREATION 
>   src/coreconfig_p.h PRE-CREATION 
>   src/kcrash.cpp b8c6477a70291ca9c1f0efef3bba061b6af247b0 
> 
> Diff: https://git.reviewboard.kde.org/r/128437/diff/
> 
> 
> Testing
> ---
> 
> builds and passes
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

Re: Review Request 129028: introduce dupe test from breeze-icons

[Harald Sitter]

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


Ship it!




shipping as part of 129026

- Harald Sitter


On Sept. 26, 2016, 3:15 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129028/
> ---
> 
> (Updated Sept. 26, 2016, 3:15 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: oxygen-icons5
> 
> 
> Description
> ---
> 
> this test uses the external binary fdupes to find duplicated files and
> complains about them as they should be symlinked to conserve space
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 97b8517e88fcda0ff7dd709e3b39fe5476e8efc8 
>   autotests/CMakeLists.txt 5fd6b125a2832071c58471b1a27964051252d07c 
>   autotests/dupetest.cpp PRE-CREATION 
>   autotests/testdata.h.cmake 476cf9ebf8b45c65e5479e14adcb1ea352e1f24d 
>   autotests/testhelpers.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129028/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

Re: Review Request 129028: introduce dupe test from breeze-icons

[Harald Sitter]

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

(Updated Sept. 28, 2016, 10:58 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 54a388ecb700f9e0030ce66535fe84b0e22276b1 by Harald Sitter 
to branch master.


Repository: oxygen-icons5


Description
---

this test uses the external binary fdupes to find duplicated files and
complains about them as they should be symlinked to conserve space


Diffs
-

  CMakeLists.txt 97b8517e88fcda0ff7dd709e3b39fe5476e8efc8 
  autotests/CMakeLists.txt 5fd6b125a2832071c58471b1a27964051252d07c 
  autotests/dupetest.cpp PRE-CREATION 
  autotests/testdata.h.cmake 476cf9ebf8b45c65e5479e14adcb1ea352e1f24d 
  autotests/testhelpers.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/129028/diff/


Testing
---


Thanks,

Harald Sitter

Re: Review Request 128115: do not load and debug in the same line

[Harald Sitter]

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

(Updated Sept. 28, 2016, 8:55 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Jeremy Whiting.


Repository: knewstuff


Description
---

if debugging is off the line is no-op and the load never happens, thus
breaking the test since the entry is always empty.

broke as result of review 126017

do not category debug in test

there's not much gain to be had from making tests less verbose, on the
contrary it might make debugging harder if something fails in an
isolated testbed (e.g. CI)


Diffs
-

  autotests/knewstuffentrytest.cpp a886afc514abfa21b6396a8b2c8c3a88d65b4a5d 

Diff: https://git.reviewboard.kde.org/r/128115/diff/


Testing
---

makes && test passes


Thanks,

Harald Sitter

Re: Review Request 129032: Don't 'inline' public functions to avoid ABI breakage.

[José Manuel Santamaría Lema]

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

(Updated Sept. 28, 2016, 11:40 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 89f8bcf00fc2fc17527d7bb4e0e2aea51f8776cb by José Manuel 
Santamaría Lema to branch master.


Repository: kio


Description
---

Don't 'inline' public functions to avoid ABI breakage.


Diffs
-

  src/widgets/kpropertiesdialog.h a85037a 
  src/widgets/kpropertiesdialog.cpp 5f64478 

Diff: https://git.reviewboard.kde.org/r/129032/diff/


Testing
---

When packaging kio for kubuntu we realized there was a couple of missing 
symbols which are a couple of deprecated functions, these functions were 
"inlined" (without using the 'inline' keyword). 
This is the offending commit:
https://quickgit.kde.org/?p=kio.git=commitdiff=b36d368f8004d949597fbe9dc83d6b70418c22f8

>From the binary compatibility page "Do's and Don'ts":
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
You cannot...
[...]
For existing functions of any type:
[...]
inline it (this includes moving a member function's body to the class 
definition, even without the inline keyword).

The proposed patch moves the functions implementation from the .h file to the 
.cpp file so this way the binary compatibility is kept.


Thanks,

José Manuel  Santamaría Lema

Re: Scrap baloo?

[Luca Beltrame]

Il giorno Thu, 22 Sep 2016 21:54:26 +0200 (CEST)
Christoph Cullmann  ha scritto:

> anyone had some time to take a look at Baloo and Co.?

Last thing on the topic I saw was this comment to this review:
https://git.reviewboard.kde.org/r/128664/


pgp3TaryU1XpJ.pgp
Description: Firma digitale OpenPGP