[Differential] [Commented On] D4421: Reverse meaning of :split, :vsplit to match vi and Kate actions.

[Milian Wolff]

mwolff added a comment.


  +1 from my side but one of the kate people should comment on this as well

REPOSITORY
  R39 KTextEditor

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

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

To: flherne, #ktexteditor
Cc: mwolff, kwrite-devel, #frameworks

Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 232 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/232/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 03 Feb 2017 05:12:34 +
Build duration: 5 min 34 sec

CHANGE SET
Revision 2fbaff66673f89a4a2e0b577c6f80eec1fa00120 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/services/application.desktop


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5483/8008 
(68%)CONDITIONAL 2965/6178 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1464/1554 
(94%)CONDITIONAL 890/1792 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1766/3045 
(58%)CONDITIONAL 763/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2037/2796 
(73%)CONDITIONAL 1227/2066 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 232 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/232/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 03 Feb 2017 05:12:34 +
Build duration: 5 min 34 sec

CHANGE SET
Revision 2fbaff66673f89a4a2e0b577c6f80eec1fa00120 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/services/application.desktop


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5483/8008 
(68%)CONDITIONAL 2965/6178 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1464/1554 
(94%)CONDITIONAL 890/1792 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1766/3045 
(58%)CONDITIONAL 763/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2037/2796 
(73%)CONDITIONAL 1227/2066 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 411 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/411/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 03 Feb 2017 05:12:09 +
Build duration: 8 min 40 sec

CHANGE SET
Revision 104aca10e101aca057f5951fb2b1b26b32556578 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit 
src/urifilters/ikws/searchproviders/ruby_application_archive.desktop
  change: edit src/kssld/kssld.json
  change: edit src/new_file_templates/linkProgram.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 
53 test(s)Failed: TestSuite.kiocore-threadtest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 273/342 (80%)CLASSES 273/342 (80%)LINE 29714/51571 
(58%)CONDITIONAL 16317/38721 (42%)

By packages
  
autotests
FILES 66/66 (100%)CLASSES 66/66 (100%)LINE 7883/8210 
(96%)CONDITIONAL 4414/8642 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 97/117 (83%)CLASSES 97/117 (83%)LINE 8078/14179 
(57%)CONDITIONAL 4424/9259 (48%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 26/36 (72%)CLASSES 26/36 (72%)LINE 3449/7559 
(46%)CONDITIONAL 1281/4381 (29%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 447/849 (53%)CONDITIONAL 
330/749 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1773/3780 
(47%)CONDITIONAL 1283/3460 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 621/782 (79%)CONDITIONAL 
607/839 (72%)
src.ioslaves.trash
FILES 8/10 (80%)CLASSES 8/10 (80%)LINE 705/1139 
(62%)CONDITIONAL 402/833 (48%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 242/727 (33%)CONDITIONAL 
150/546 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 21/29 (72%)CONDITIONAL 
16/26 (62%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 237/266 (89%)CONDITIONAL 
332/412 (81%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3639/11016 
(33%)CONDITIONAL 1748/7096 (25%)

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 227 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/227/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 03 Feb 2017 05:12:34 +
Build duration: 2 min 7 sec

CHANGE SET
Revision 2fbaff66673f89a4a2e0b577c6f80eec1fa00120 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/services/application.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.kservicetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5484/8008 
(68%)CONDITIONAL 2972/6178 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1464/1554 
(94%)CONDITIONAL 895/1792 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1766/3045 
(58%)CONDITIONAL 763/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2038/2796 
(73%)CONDITIONAL 1229/2066 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

Re: Phabricator: All repositories registered - upcoming workflow changes

[Nicolás Alvarez]

2017-02-02 7:23 GMT-03:00 René J.V. Bertin :
> On Thursday February 2 2017 22:09:34 Ben Cooksley wrote:
>
>>For those who dismiss decay as an issue - problems with previous
>>Reviewboard upgrades not taking cleanly have resulted in some reviews
>>being damaged, causing their diffs to become unavailable. These sorts
>>of problems do happen.
>
> Yes, I bet they do, and I bet there are ways to prevent them from happening.
> Bitrot should not be an issue with the ready availability of ZFS (on Linux or 
> BSD, FreeNAS etc) and btrfs, and

You missed the point. This "bit rot" is not about disk damage but
about software incompatibility. ZFS doesn't help with that...

-- 
Nicolás

[Differential] [Commented On] D4416: Send desktopfilename as part of notifyByPopup hints

[Aleix Pol Gonzalez]

apol added a comment.


  Same was done with the transient hint, btw. Maybe it would make sense to add 
a comment pointing to the documentation this refers to?

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

To: davidedmundson, #plasma, apol
Cc: plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Accepted] D4416: Send desktopfilename as part of notifyByPopup hints

[Aleix Pol Gonzalez]

apol accepted this revision.
apol added a reviewer: apol.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

To: davidedmundson, #plasma, apol
Cc: plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

Phabricator differential is not good - WAS - Re: Phabricator: All repositories registered - upcoming workflow changes

[Albert Astals Cid]

El diumenge, 29 de gener de 2017, a les 8:32:21 CET, Ben Cooksley va escriure:
> Hi everyone,
> 
> We've just completed the registration of all mainline repositories
> (not including Websites or Sysadmin namespaced ones) on Phabricator.
> Thanks go to Luigi Toscano for providing significant assistance with
> this process.
> 
> From this point forward, communities should be moving away from
> Reviewboard to Phabricator for conducting code review. 

I just created first patch with the phabricator web interface. 

Found one minor and one major problem.

Minor problem:
 * You can't update the diff before creating a "Revision", so if you realize 
your diff was wrong, back luck, you either leave the diff floating in the 
limbo or you create the Revision and the update the diff, showing the world 
your mistake for no reason
https://phabricator.kde.org/D4422?vs=10881=10882


Major problem:
 * It doesn't show context
https://phabricator.kde.org/D4422

"Context not available." is terrible, how is one supposed to review without 
being able to read the rest of the code? 

This is a deal breaker for me.

Cheers,
  Albert

Re: Review Request 129849: KToolTipWidget: don't take ownership of the content widget

[Elvis Angelaccio]

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

(Updated Feb. 2, 2017, 11:16 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Feck.


Changes
---

Submitted with commit 26b1ec257ab38c56e69803e96de695af2773024c by Elvis 
Angelaccio to branch master.


Repository: kwidgetsaddons


Description
---

While the layout of the tooltip sets the tooltip as parent of the content 
widget, we don't really need to take ownership of it. We can just restore the 
old parent once we are done.
This prevents a double delete crash if someone (by accident) deletes first the 
tooltip and then the content.


Diffs
-

  autotests/ktooltipwidgettest.h 556d93edd7792736bb7b41761f2d8934395d2f3c 
  autotests/ktooltipwidgettest.cpp 89124c6b3f16b76a346a8c9c74ff2f9efe0c9e83 
  src/ktooltipwidget.h cde7e66af797c9888dec59ef50831a2260a2c238 
  src/ktooltipwidget.cpp 544eb74d005bb4c963c8cc6cd8b941c018cf463e 

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


Testing
---

Test case reproduces the crash, which is fixed by the patch.


Thanks,

Elvis Angelaccio

[Differential] [Updated] D4422: Fix KCompressionDevice to work with Qt >= 5.7

[Albert Astals Cid]

aacid updated the summary for this revision.
aacid updated the test plan for this revision.

REPOSITORY
  R243 KArchive

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

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

To: aacid
Cc: #frameworks

[Differential] [Updated, 16 lines] D4422: Fix KCompressionDevice to work with Qt >= 5.7

[Albert Astals Cid]

aacid updated this revision to Diff 10882.

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4422?vs=10881=10882

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

AFFECTED FILES
  src/kcompressiondevice.cpp

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

To: aacid
Cc: #frameworks

[Differential] [Request, 18 lines] D4422: Fix KCompressionDevice to work with Qt >= 5.7

[Albert Astals Cid]

aacid created this revision.
aacid set the repository for this revision to R243 KArchive.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REPOSITORY
  R243 KArchive

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

AFFECTED FILES
  CMakeLists.txt
  src/kcompressiondevice.cpp

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

To: aacid
Cc: #frameworks

[Differential] [Request, 6 lines] D4421: Reverse meaning of :split, :vsplit to match vi and Kate actions.

[Francis Herne]

flherne created this revision.
flherne added a reviewer: KTextEditor.
flherne set the repository for this revision to R39 KTextEditor.
Restricted Application added subscribers: Frameworks, kwrite-devel.
Restricted Application added a project: Frameworks.

REVISION SUMMARY
  Reverse meaning of :split, :vsplit to match vi and Kate actions.
  
  The previous behaviour of these commands was swapped, compared either to vi 
or to "Split Vertical" in Kate.
  
  :new and :vnew were fixed in 
https://phabricator.kde.org/R39:0b00782a90ec1d68b0fe0f3140620aeb6de4b132, but 
this pair was missed.
  
  Given that every use I can find has this confusing reverse pattern, the API 
is probably wrong. Too late now.
  
  Pointed out by head7 in https://phabricator.kde.org/D4250.

TEST PLAN
  Compiles, matches vi now.

REPOSITORY
  R39 KTextEditor

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

AFFECTED FILES
  src/vimode/appcommands.cpp

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

To: flherne, #ktexteditor
Cc: kwrite-devel, #frameworks

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/501/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 21:25:06 +
Build duration: 3 min 22 sec

CHANGE SET
Revision 2eb36c2014289570c9b116123c6d480faabe37a4 by kainz.a: (move 
applications-internet icons to preferences)
  change: add icons/preferences/32/applications-internet.svg
  change: add icons-dark/preferences/32/applications-internet.svg
  change: delete icons-dark/apps/32/applications-internet.svg
  change: delete icons/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 218/269 
(81%)CONDITIONAL 120/206 (58%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 176/212 (83%)CONDITIONAL 
106/180 (59%)

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/501/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 21:25:06 +
Build duration: 3 min 22 sec

CHANGE SET
Revision 2eb36c2014289570c9b116123c6d480faabe37a4 by kainz.a: (move 
applications-internet icons to preferences)
  change: delete icons-dark/apps/32/applications-internet.svg
  change: add icons-dark/preferences/32/applications-internet.svg
  change: add icons/preferences/32/applications-internet.svg
  change: delete icons/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 218/269 
(81%)CONDITIONAL 120/206 (58%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 176/212 (83%)CONDITIONAL 
106/180 (59%)

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/501/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 21:25:06 +
Build duration: 3 min 22 sec

CHANGE SET
Revision 2eb36c2014289570c9b116123c6d480faabe37a4 by kainz.a: (move 
applications-internet icons to preferences)
  change: delete icons-dark/apps/32/applications-internet.svg
  change: add icons-dark/preferences/32/applications-internet.svg
  change: add icons/preferences/32/applications-internet.svg
  change: delete icons/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 218/269 
(81%)CONDITIONAL 120/206 (58%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 176/212 (83%)CONDITIONAL 
106/180 (59%)

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/501/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 21:25:06 +
Build duration: 3 min 22 sec

CHANGE SET
Revision 2eb36c2014289570c9b116123c6d480faabe37a4 by kainz.a: (move 
applications-internet icons to preferences)
  change: add icons/preferences/32/applications-internet.svg
  change: add icons-dark/preferences/32/applications-internet.svg
  change: delete icons-dark/apps/32/applications-internet.svg
  change: delete icons/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 218/269 
(81%)CONDITIONAL 120/206 (58%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 176/212 (83%)CONDITIONAL 
106/180 (59%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 500 - 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/500/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 21:00:46 +
Build duration: 15 min

CHANGE SET
Revision f8a6ffaf7d94634c95bf4d629b1997152453398b by kainz.a: (add 
application-internet to categories)
  change: add icons-dark/apps/32/applications-internet.svg
  change: add icons/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 220/269 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 178/212 (84%)CONDITIONAL 
108/180 (60%)

Re: KConfig issues prevent compiling KDE applications under Windows

[Jaroslaw Staniek]

On 1 February 2017 at 14:34, David Faure  wrote:

> On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote:
> > Hello,
> >
> > KConfig used to work perfectly fine under Windows. I recently tried to
> > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8 using
> > Craft, but encountered an issue as explained in this bug report:
> >
> > https://bugs.kde.org/show_bug.cgi?id=
> ​​
> 375654 
> >
> > I talked with Craft maintainers (Hannah et al) and they told me this was
> an
> > issue from KConfig side, not Craft. Can someone please look into this and
> > fix it as it our release is dependent on this.
>
> KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class
> QMap KEntryKey,struct KEntry>::iterator __cdecl KEntryMap::findEntry(class
> QByteArray const &,class QByteArray const &,class QFlags KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite
> rator@?$QMap@UKEntryKey@@UKEntryAEBVQByteArray@@0V?
> $QFlags@W4SearchFlag@KEntryMap@Z)
> already defined in kconfigdata.cpp.obj
>
> Thanks MSVC for a very readable error message as always ;)
>
> One note though: this is a failure to link a unittest, your release isn't
> blocked, you can just disable the building of unittests in kconfig.
>
> The double definition can be explained, the unittest links to KF5ConfigCore
> and then also compiles in ../src/core/kconfigdata.cpp because that class
> is not
> exported.


Hi,
Apparently it is since eab822e20620 (Jan 15).
​The bug #​375654 does not seem to provide version info but the fix isn't
just released, right? CC'd Stephen Kelly.

I don't see much to blame MSVS for here, even the message is rather clear:
the binary being linked (not compiled) already contains the symbol.
I'd avoid hacks such as (kconfig/autotests/CMakeLists.txt):

set(kentrymaptest_SRCS kentrymaptest.cpp ../src/core/kconfigdata.cpp)

Now since eab822e20620 the class is exported and all the other symbols are
inline so the hack isn't needed. Anyone, feel free make a general fix.

PS: The topic isn't linker-dependent, just the Microsoft's linker
demonstrated consequences of the hack.
Going further for quality, exporting just for test is suboptimal so it's a
good practice to export only for tests this way by using special macros:

Calligra for many years: https://api.kde.org/bundled-ap
ps-api/calligra-apidocs/libs/main/html/komain__export_8h_source.html

KDb: https://cgit.kde.org/kdb.git/tree/src/config-kdb.h.cmake#n43

I'd recommend this not just for frameworks (or do we have this in ECM
already?).
Obviously CMake's generate_export_header() does not support it but IMHO it
would.
Then the extra cmake conditions would not be needed.

​So maybe that would be even better fix for KConfigData tests.​



> This is something we do in quite a number of other places too,
> always for autotests.
>
> kde-windows people, if you confirm there is no way to make this work
> (some linker flag maybe?), then I do see one solution: the one used by Qt
> (and
> konqueror), which is an export macro that only exports the class when
> compilation of autotests is enabled. See konqueror/src/konqprivate_expo
> rt.h
> for an example.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

[Differential] [Commented On] D4130: KConfigDialogManager: get change signal from metaObject or special property

[Friedrich W. H. Kossebau]

kossebau added a comment.


  If no-one objects or has further comments, I would commit this soon after 
5.31 release.

REPOSITORY
  R265 KConfigWidgets

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

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

To: kossebau, #frameworks
Cc: elvisangelaccio

[Differential] [Updated, 311 lines] D4130: KConfigDialogManager: get change signal from metaObject or special property

[Friedrich W. H. Kossebau]

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


  rebase to latest msater, also prepare for rather KF 5.32

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4130?vs=10285=10874

BRANCH
  readChangeSignalFromMetaObject

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

AFFECTED FILES
  autotests/kconfigdialog_unittest.cpp
  src/kconfigdialogmanager.cpp
  src/kconfigdialogmanager.h

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

To: kossebau, #frameworks
Cc: elvisangelaccio

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 499 - 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/499/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:53:21 +
Build duration: 3 min 31 sec

CHANGE SET
Revision be8c3e4c91851c0afe84eea2b38bfacf6dbd2415 by Harald Sitter: (remove 
duplicates from unscalable icons list)
  change: edit autotests/scalabletest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 220/269 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 178/212 (84%)CONDITIONAL 
108/180 (60%)

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/500/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:56:46 +
Build duration: 3 min 25 sec

CHANGE SET
Revision f8a6ffaf7d94634c95bf4d629b1997152453398b by kainz.a: (add 
application-internet to categories)
  change: add icons/apps/32/applications-internet.svg
  change: add icons-dark/apps/32/applications-internet.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 220/269 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 178/212 (84%)CONDITIONAL 
108/180 (60%)

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/499/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:53:21 +
Build duration: 2 min 58 sec

CHANGE SET
Revision be8c3e4c91851c0afe84eea2b38bfacf6dbd2415 by Harald Sitter: (remove 
duplicates from unscalable icons list)
  change: edit autotests/scalabletest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 220/269 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 178/212 (84%)CONDITIONAL 
108/180 (60%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 498 - 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/498/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:34:22 +
Build duration: 15 min

CHANGE SET
Revision 5023cd996313dfd3b0a4d45d7a5a38301735f023 by kainz.a: (move fcitx from 
apps to status)
  change: delete icons/apps/22/fcitx-sunpinyin.svg
  change: add icons/status/22/fcitx-shuangpin.svg
  change: delete icons-dark/apps/22/fcitx-pinyin-libpinyin.svg
  change: delete icons/apps/22/fcitx-shuangpin.svg
  change: add icons/status/22/fcitx-wubi.svg
  change: add icons/status/22/fcitx-pinyin.svg
  change: delete icons-dark/apps/22/fcitx-shuangpin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-shuangpin.svg
  change: add icons-dark/status/22/fcitx-shuangpin-libpinyin.svg
  change: add icons-dark/status/22/fcitx-pinyin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-pinyin.svg
  change: delete icons/apps/22/fcitx-shuangpin-libpinyin.svg
  change: delete icons/apps/22/fcitx-wubi.svg
  change: add icons-dark/status/22/fcitx-shuangpin.svg
  change: add icons-dark/status/22/fcitx-pinyin.svg
  change: delete icons-dark/apps/22/fcitx-sunpinyin.svg
  change: add icons-dark/status/22/fcitx-googlepinyin.svg
  change: delete icons/apps/22/fcitx-googlepinyin.svg
  change: add icons-dark/status/22/fcitx-wubi.svg
  change: add icons/status/22/fcitx-shuangpin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-googlepinyin.svg
  change: delete icons/apps/22/fcitx-pinyin-libpinyin.svg
  change: add icons/status/22/fcitx-pinyin-libpinyin.svg
  change: delete icons/apps/22/fcitx-pinyin.svg
  change: add icons-dark/status/22/fcitx-sunpinyin.svg
  change: add icons/status/22/fcitx-googlepinyin.svg
  change: delete icons-dark/apps/22/fcitx-wubi.svg
  change: add icons/status/22/fcitx-sunpinyin.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

[Differential] [Commented On] D4329: KMessageWidget: fix behaviour on overlapping calls of animatedShow/animatedHide

[Friedrich W. H. Kossebau]

kossebau added a comment.


  messagetest for me always ran with this result:
  
Totals: 4 passed, 0 failed, 0 skipped, 0 blacklisted, 3603ms
  
  Though I had to hack into KTextEditor to make it actually also call 
animatedShow & animatedHide(), to test if there is any effect ;)
  true -> false here in KTextEditor::ViewPrivate::postMessage(...):
  
m_floatTopMessageWidget = new KateMessageWidget(m_viewInternal, false);

REPOSITORY
  R236 KWidgetsAddons

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

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

To: kossebau, #frameworks, dhaumann
Cc: cfeck

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/498/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:33:36 +
Build duration: 2 min 36 sec

CHANGE SET
Revision 5023cd996313dfd3b0a4d45d7a5a38301735f023 by kainz.a: (move fcitx from 
apps to status)
  change: add icons/status/22/fcitx-wubi.svg
  change: add icons/status/22/fcitx-shuangpin.svg
  change: delete icons/apps/22/fcitx-sunpinyin.svg
  change: delete icons/apps/22/fcitx-pinyin-libpinyin.svg
  change: add icons/status/22/fcitx-pinyin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-wubi.svg
  change: delete icons-dark/apps/22/fcitx-pinyin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-shuangpin-libpinyin.svg
  change: delete icons-dark/apps/22/fcitx-sunpinyin.svg
  change: delete icons-dark/apps/22/fcitx-shuangpin.svg
  change: delete icons-dark/apps/22/fcitx-googlepinyin.svg
  change: delete icons/apps/22/fcitx-shuangpin-libpinyin.svg
  change: add icons-dark/status/22/fcitx-googlepinyin.svg
  change: add icons-dark/status/22/fcitx-sunpinyin.svg
  change: add icons-dark/status/22/fcitx-wubi.svg
  change: add icons/status/22/fcitx-sunpinyin.svg
  change: add icons/status/22/fcitx-googlepinyin.svg
  change: delete icons/apps/22/fcitx-shuangpin.svg
  change: add icons-dark/status/22/fcitx-shuangpin-libpinyin.svg
  change: add icons-dark/status/22/fcitx-pinyin-libpinyin.svg
  change: add icons-dark/status/22/fcitx-shuangpin.svg
  change: delete icons-dark/apps/22/fcitx-pinyin.svg
  change: add icons/status/22/fcitx-pinyin.svg
  change: add icons-dark/status/22/fcitx-pinyin.svg
  change: delete icons/apps/22/fcitx-googlepinyin.svg
  change: delete icons/apps/22/fcitx-pinyin.svg
  change: add icons/status/22/fcitx-shuangpin-libpinyin.svg
  change: delete icons/apps/22/fcitx-wubi.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 497 - 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/497/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:14:37 +
Build duration: 19 min

CHANGE SET
Revision 698a3ef974f33a09291b7819abdbe590868df4d2 by kainz.a: (remove steam 
tray icon (trademark))
  change: delete icons-dark/apps/22/steam_tray_mono.svg
  change: delete icons/apps/22/steam_tray_mono.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/497/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:14:20 +
Build duration: 19 min

CHANGE SET
Revision 698a3ef974f33a09291b7819abdbe590868df4d2 by kainz.a: (remove steam 
tray icon (trademark))
  change: delete icons-dark/apps/22/steam_tray_mono.svg
  change: delete icons/apps/22/steam_tray_mono.svg


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 496 - 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/496/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:09:45 +
Build duration: 3 min 11 sec

CHANGE SET
Revision fc8b18c37743c8ffb639f9840fa4f25a2b09a6a2 by kainz.a: (add scaled icons)
  change: add icons-dark/apps/48/korg-todo.svg
  change: edit icons/apps/48/kdeapp.svg
  change: add icons/apps/48/korg-todo.svg
  change: add icons/apps/48/homerun.svg
  change: add icons-dark/apps/48/kde.svg
  change: add icons/apps/48/kde.svg
  change: edit icons/index.theme
  change: add icons-dark/apps/48/homerun.svg
  change: edit icons-dark/index.theme


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/496/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 20:09:45 +
Build duration: 3 min 13 sec

CHANGE SET
Revision fc8b18c37743c8ffb639f9840fa4f25a2b09a6a2 by kainz.a: (add scaled icons)
  change: add icons-dark/apps/48/korg-todo.svg
  change: add icons/apps/48/homerun.svg
  change: add icons-dark/apps/48/homerun.svg
  change: edit icons/index.theme
  change: edit icons/apps/48/kdeapp.svg
  change: add icons-dark/apps/48/kde.svg
  change: add icons/apps/48/korg-todo.svg
  change: add icons/apps/48/kde.svg
  change: edit icons-dark/index.theme


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

Re: KConfig issues prevent compiling KDE applications under Windows

[David Faure]

On jeudi 2 février 2017 20:03:10 CET Albert Astals Cid wrote:
> El dijous, 2 de febrer de 2017, a les 12:46:14 CET, Milian Wolff va escriure:
> > On Mittwoch, 1. Februar 2017 14:34:37 CET David Faure wrote:
> > > On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote:
> > > > Hello,
> > > > 
> > > > KConfig used to work perfectly fine under Windows. I recently tried to
> > > > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8
> > > > using
> > > > Craft, but encountered an issue as explained in this bug report:
> > > > 
> > > > https://bugs.kde.org/show_bug.cgi?id=375654
> > > > 
> > > > I talked with Craft maintainers (Hannah et al) and they told me this
> > > > was
> > > > an
> > > > issue from KConfig side, not Craft. Can someone please look into this
> > > > and
> > > > fix it as it our release is dependent on this.
> > > 
> > > KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class
> > > QMap::iterator __cdecl
> > > KEntryMap::findEntry(class QByteArray const &,class QByteArray const
> > > &,class QFlags > > KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite
> > > rator@?$QMap@UKEntryKey@@UKEntryAEBVQByteArray@@0V?
> > > $QFlags@W4SearchFlag@KEntryMap@Z)
> > > already defined in kconfigdata.cpp.obj
> > > 
> > > Thanks MSVC for a very readable error message as always ;)
> > > 
> > > One note though: this is a failure to link a unittest, your release
> > > isn't
> > > blocked, you can just disable the building of unittests in kconfig.
> > > 
> > > The double definition can be explained, the unittest links to
> > > KF5ConfigCore
> > > and then also compiles in ../src/core/kconfigdata.cpp because that class
> > > is
> > > not exported. This is something we do in quite a number of other places
> > > too, always for autotests.
> > 
> > This is a violation of ODR and thus undefined behavior. Afaik even with
> > clang you can hit issues in such situations - I know I've seen this with
> > clang on KDevelop.
> > 
> > > kde-windows people, if you confirm there is no way to make this work
> > > (some linker flag maybe?), then I do see one solution: the one used by
> > > Qt
> > > (and konqueror), which is an export macro that only exports the class
> > > when
> > > compilation of autotests is enabled. See
> > > konqueror/src/konqprivate_export.h
> > > for an example.
> > 
> > That should be done, imo.
> 
> Does that mean that:
>  A) Distros don't build tests so the private files don't get exported
>  B) Distros export private files so they can build tests
>  C) Distros have to build things twice, one for running tests and one for
> installing?

To avoid any confusion, let's not talk about "exporting files", that's unclear.
A class is exported, a file is installed, the two things are orthogonal.

So to clarify, distros have the choice between:

1) building tests, in which case they would end up with a few more exported 
classes in the lib
(but the private headers are not installed, so no application can exploit this)

2) not building tests, in which case they are not affected by this.


In Qt there is indeed a slightly different system because there is the option 
to build 
only tests which don't require private symbols, and the option to export the 
necessary
private symbols (developer-build). I.e. the tests themselves use some #ifdef.
I'm not sure the small increase in the number of exports in case 1 above is 
worse
yet another cmake option and increase in the combinatory number of cases to 
check
(#ifdef = we should check both cases).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

[Differential] [Request, 4 lines] D4416: Send desktopfilename as part of notifyByPopup hints

[David Edmundson]

davidedmundson created this revision.
davidedmundson added a reviewer: Plasma.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.

REVISION SUMMARY
  It's one of the new hints added in the gnome-only version of the
  notification specification.
  
  Adding it will help our interopability there and it might prove more
  useful for Plasma in future than the current x-kde-appname.

TEST PLAN
  Ran dbus-monitor
  Emitted signal from konversation

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  src/notifybypopup.cpp

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

To: davidedmundson, #plasma
Cc: plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

Re: breeze-icons and the symlink business

[Gleb Popov]

On Thu, Feb 2, 2017 at 2:49 AM, Harald Sitter  wrote:

> hola
>
> breeze-icons uses lots of symlinks. Unfortunately, ever so often our
> icon designers make a mistake and create a bad symlink. To mitigate
> this I added a bunch of tests making sure everything is nice and
> dandy.
>
> In the mean parts of the build were changed to not tolerate broken
> symlinks. While I don't really have a problem with that in of itself,
> the code largely simply ignores the possibility of broken symlinks and
> fails with the most shitty error messages you could think of. Given
> our artists are not software engineers they are having a hard time
> figuring out what is going on. And TBH, I too had to stat files to get
> to the bottom of the errors. This is a fairly shit situation as on the
> one hand we want lovely icons and on the other hand the people working
> on the icons can't understand what needs fixing without having to find
> a developer they aren't too afraid of to talk to.
>
> This really needs fixing.
>
> Notably offenders I had a fight with today:
>
>
> # breeze-validate-svg (introduced by Jos)
>
> This is a bash script running xmllint.
>
> ## Problem 1: Sources
>
> The custom target sets `SOURCES ${SVGS}` this has no notable advantage
> other than making the svgs show up in an IDE, it does however mean
> that cmake will try to inspect them (as a build tool does when they
> get told something is a source) and then falls flat on the face when
> it encounters a broken symlink as it now can't determine the source
> type resulting in this lovely error
>
> ```
> 21:39:07 CMake Error at CMakeLists.txt:70 (add_custom_target):
> 21:39:07   Cannot find source file:
> 21:39:07
> 21:39:07 /home/jenkins/sources/breeze-icons/kf5-qt5/icons-dark/
> categories/32/applications-other.svg
> ```
>
> ## Problem 2: The code
>
> The bash code in of itself runs find with -exec on xmllint. Problem
> being that if the symlink is broken xmllint will (rightfully) complain
>
> ```
> warning: failed to load external entity
> "./icons-dark/categories/32/applications-other.svg"
> ```
>
> While that is much better than the earlier problem it's still plenty
> unobvious what the underlying cause for this is. Supposedly the script
> should skip bogus symlinks.
>
> ## Problem 3: Oh but really
>
> This isn't really related to the issue of bad symlink handling:
>
> - apparently this didn't get a review. why ever would this not get a
> review?
> - this should be a test and only run when testing is enabled
> - when xmllint is not present it should report this in some form or
> fashion during the test run so one knows linting is not done
> - it should record its complaints via ctest so jenkins can display them
> properly
> - I fail to appreciate the reason this needs to depend on bash (versus
> sh, or well, neither)
>
> ## Fix Suggestion
>
> - don't needlesly set SOURCE
> - don't pass bad paths to xmllint
> - deal with stuff in problem 3
>
>
> # RCC generation (introduced by Gleb, enabled by Jaroslaw)
>
> This is a bunch of cmake rigging and helper binaries to assemble the
> icons into an rcc.
>
> ## Problem
>
> `cmake -E copy_directory` is used to copy the src tree of the themes
> into the build dir from which the resource file gets assembled. I am
> guessing copy_directory does not preserver, but resolve symlinks
> because it greets us with the ever so opaque error:
>
> ```
> Error copying directory from
> "/home/me/src/git/breeze-icons/icons-dark" to
> "/home/me/src/git/breeze-icons/build/icon
> s-dark/res".
> ```
>
> ## Fix Suggestion
>
> This is slightly less trivial since the rcc/qrc helpers seem to depend
> on resolved symlinks, so I am guessing a way to deal with this would
> be to use cmake's `file(COPY...)` instead of copy_directory and then
> have another helper run through the directories to flatten out the
> symlinks (dropping broken symlinks).
>
>
> Kindly fix this to empower the artists to know what's going on again :(
> HS
>

This PR might be relevant: https://git.reviewboard.kde.org/r/128112/
I intended to use it on Windows only, but it well may be used on *nix too.

KArchive/KCompressionDevice regression with Qt >= 5.7

[Albert Astals Cid]

As shown by the tests i've just commited

https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/142/console
(ignore the bit in that page it says it is using 5.6, it is not).

KArchive broke with Qt 5.7 (they rewrote some parts if QIODevice) 

Anyone that knows the code around? Is it Qt being buggy or new Qt paths 
exercising buggy code in KArchive?

I had a look yesterday at 2am but between being late and being a bit sick-ish 
didn't get much out of it.

Cheers,
  Albert

Re: KConfig issues prevent compiling KDE applications under Windows

[Albert Astals Cid]

El dijous, 2 de febrer de 2017, a les 12:46:14 CET, Milian Wolff va escriure:
> On Mittwoch, 1. Februar 2017 14:34:37 CET David Faure wrote:
> > On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote:
> > > Hello,
> > > 
> > > KConfig used to work perfectly fine under Windows. I recently tried to
> > > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8 using
> > > Craft, but encountered an issue as explained in this bug report:
> > > 
> > > https://bugs.kde.org/show_bug.cgi?id=375654
> > > 
> > > I talked with Craft maintainers (Hannah et al) and they told me this was
> > > an
> > > issue from KConfig side, not Craft. Can someone please look into this
> > > and
> > > fix it as it our release is dependent on this.
> > 
> > KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class
> > QMap::iterator __cdecl
> > KEntryMap::findEntry(class QByteArray const &,class QByteArray const
> > &,class QFlags > KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite
> > rator@?$QMap@UKEntryKey@@UKEntryAEBVQByteArray@@0V?
> > $QFlags@W4SearchFlag@KEntryMap@Z)
> > already defined in kconfigdata.cpp.obj
> > 
> > Thanks MSVC for a very readable error message as always ;)
> > 
> > One note though: this is a failure to link a unittest, your release isn't
> > blocked, you can just disable the building of unittests in kconfig.
> > 
> > The double definition can be explained, the unittest links to
> > KF5ConfigCore
> > and then also compiles in ../src/core/kconfigdata.cpp because that class
> > is
> > not exported. This is something we do in quite a number of other places
> > too, always for autotests.
> 
> This is a violation of ODR and thus undefined behavior. Afaik even with
> clang you can hit issues in such situations - I know I've seen this with
> clang on KDevelop.
> 
> > kde-windows people, if you confirm there is no way to make this work
> > (some linker flag maybe?), then I do see one solution: the one used by Qt
> > (and konqueror), which is an export macro that only exports the class when
> > compilation of autotests is enabled. See
> > konqueror/src/konqprivate_export.h
> > for an example.
> 
> That should be done, imo.

Does that mean that:
 A) Distros don't build tests so the private files don't get exported
 B) Distros export private files so they can build tests
 C) Distros have to build things twice, one for running tests and one for 
installing?

Cheers,
  Albert

> 
> Bye

Jenkins-kde-ci: karchive master kf5-qt5 » Linux,gcc - Build # 142 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/karchive%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/142/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 18:48:12 +
Build duration: 4 min 7 sec

CHANGE SET
Revision e1f88ac81c5b548c17b1df6c1d52cebff7408656 by Albert Astals Cid: (Add 
test for read/seek/peek working)
  change: edit autotests/karchivetest.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 
test(s)Failed: TestSuite.karchivetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 31/35 (89%)CLASSES 31/35 (89%)LINE 4095/5029 
(81%)CONDITIONAL 2030/3658 (55%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1122/1128 
(99%)CONDITIONAL 724/1391 (52%)
src
FILES 22/26 (85%)CLASSES 22/26 (85%)LINE 2973/3901 
(76%)CONDITIONAL 1306/2267 (58%)

[Differential] [Commented On] D4307: [RFC] Introduce an adoption command in the wallpaper knsrc file

[Aleix Pol Gonzalez]

apol added a comment.


  Changes are in KNS now, can someone please review the patch?

REPOSITORY
  R120 Plasma Workspace

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

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

To: apol, #frameworks, whiting, leinir, mart
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Request, 621 lines] D4414: don't regenerate frames when setting every property

[Marco Martin]

mart created this revision.
mart added a reviewer: Plasma.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.

REVISION SUMMARY
  give frameSvg the concept of repaintBlocked(), that enables and
  disables the regeneration of the frame data when a property is set.
  the use case is when often, a lot of properties are set one after
  the other (such as prefix, enabled borders, size)
  collapse the formely similar, but a bit different logic of frame
  regeneration is a single function for better maintanability.
  QML FrameSvgItem sets repaintblocked when it starts and releases it just on 
oncomponentCompleted

TEST PLAN
  plasmashell still starts, autotests still work, all frames are rendered 
correctly
  the destruction of old frames is cutted by 50%. in the qml profiler
  the creation time of a framesvgitem slightly improved, on this machine from 
around 26 msecs to around 21, can still be improved, but at least the code is a 
bit simpler

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  mart/FrameSvgTransactions

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

AFFECTED FILES
  autotests/data/background.svgz
  autotests/framesvgtest.cpp
  autotests/framesvgtest.h
  src/declarativeimports/core/framesvgitem.cpp
  src/declarativeimports/core/framesvgitem.h
  src/plasma/framesvg.cpp
  src/plasma/framesvg.h
  src/plasma/private/framesvg_p.h

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

To: mart, #plasma
Cc: plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

Re: Phabricator: All repositories registered - upcoming workflow changes

[Harald Sitter]

On Thu, Feb 2, 2017 at 6:17 PM, Ben Cooksley  wrote:
> On Thu, Feb 2, 2017 at 11:51 PM, Harald Sitter  wrote:
>> On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley  wrote:
>>> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano  
>>> wrote:
 Il 02.02.2017 10:09 Ben Cooksley ha scritto:

> Hi all,
>
> As a starting point: keeping the software itself running is a
> non-starting option from my perspective. It's going to be shutdown.
> This is purely to reduce the amount of maintenance effort we have to
> expend in keeping our systems running.


 Sorry Ben, but this is not the solution. See below.

> There is an enormous amount of software and other systems deployed on
> our infrastructure, and the value of continuing to maintain software,
> including associated security updates, major upgrades to ensure we're
> able to continue running it on modern distributions, etc for something
> which is no longer in active use is questionable at best. Bitrot and
> decay is almost guaranteed to erode the value of it as a historical
> archive in the long run in any case.
>
> For those who dismiss decay as an issue - problems with previous
> Reviewboard upgrades not taking cleanly have resulted in some reviews
> being damaged, causing their diffs to become unavailable. These sorts
> of problems do happen.


 If it is a resource problem, it can be addressed elsewhere as well. The 
 e.V.
 can hire people.

> Whether some kind of read only archive is retained is another topic
> altogether.
>
> Reviewboard has a WebAPI which should be usable by anyone interested
> to extract all the information regarding reviews, including their
> comments and the diff itself. This could be used to create a static
> snapshot of each review.


 Here I disagree, I think it is exactly the same issue. Without a read only
 archive, easily accessibile like the current reviewboard (for which a 
 static
 copy will be the best solution), we need to keep the site up and it is not
 thinkable that anyone would go and extract single reviews. It should be
 available for all the content.
>>>
>>> The above point was giving an indication of how exactly someone with a
>>> vested interest in creating a read only archive would go about it.
>>> Whilst I haven't checked, I would imagine API exists to retrieve the
>>> list of reviews (although it's an incrementing number, with a large
>>> gap between the last number of SVN reviews and the first of the Git
>>> reviews)
>>>
>>> This isn't a task which has to be done by Sysadmin - the Reviewboard
>>> WebAPI is accessible (within reasonable usage of course) to anyone
>>> with an Identity account. To be honest it would be better that it be
>>> done by someone who works with the reviews, as they'll be more aware
>>> of the issues surrounding various forms of presentation (threading,
>>> etc) that needs to be taken care of.
>>
>> Come shutdown day, disable login and then dump the website with wget
>> or something alike. Someone who's complaining can write a script so
>> sysadmins don't have to spend time on this ...
>>
>> Here's your starting point
>> wget --mirror --convert-links --backup-converted --adjust-extension
>> --page-requisites https://git.reviewboard.kde.org
>>
>> Then use that to replace the php version. The builtin search won't
>> work but such is life.
>
> Reviewboard is a Python application :)

All the same modern magic to me :P

>>
>> http://i.imgur.com/A9z0RYJ.png
>
> Interesting, I would have assumed that due to all the AJAX it uses
> that a wget mirror wouldn't work...
> We've used that a few times to shutdown things like old Akademy sites,
> so if it works that's fine with me.

Seems to work just fine. The proof of concept I did was with
/etc/hosts setting git.reviewboard.kde.org to localhost for good
measure btw. So a dump should do nicely without much effort.

HS

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Thu, Feb 2, 2017 at 11:51 PM, Harald Sitter  wrote:
> On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley  wrote:
>> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano  
>> wrote:
>>> Il 02.02.2017 10:09 Ben Cooksley ha scritto:
>>>
 Hi all,

 As a starting point: keeping the software itself running is a
 non-starting option from my perspective. It's going to be shutdown.
 This is purely to reduce the amount of maintenance effort we have to
 expend in keeping our systems running.
>>>
>>>
>>> Sorry Ben, but this is not the solution. See below.
>>>
 There is an enormous amount of software and other systems deployed on
 our infrastructure, and the value of continuing to maintain software,
 including associated security updates, major upgrades to ensure we're
 able to continue running it on modern distributions, etc for something
 which is no longer in active use is questionable at best. Bitrot and
 decay is almost guaranteed to erode the value of it as a historical
 archive in the long run in any case.

 For those who dismiss decay as an issue - problems with previous
 Reviewboard upgrades not taking cleanly have resulted in some reviews
 being damaged, causing their diffs to become unavailable. These sorts
 of problems do happen.
>>>
>>>
>>> If it is a resource problem, it can be addressed elsewhere as well. The e.V.
>>> can hire people.
>>>
 Whether some kind of read only archive is retained is another topic
 altogether.

 Reviewboard has a WebAPI which should be usable by anyone interested
 to extract all the information regarding reviews, including their
 comments and the diff itself. This could be used to create a static
 snapshot of each review.
>>>
>>>
>>> Here I disagree, I think it is exactly the same issue. Without a read only
>>> archive, easily accessibile like the current reviewboard (for which a static
>>> copy will be the best solution), we need to keep the site up and it is not
>>> thinkable that anyone would go and extract single reviews. It should be
>>> available for all the content.
>>
>> The above point was giving an indication of how exactly someone with a
>> vested interest in creating a read only archive would go about it.
>> Whilst I haven't checked, I would imagine API exists to retrieve the
>> list of reviews (although it's an incrementing number, with a large
>> gap between the last number of SVN reviews and the first of the Git
>> reviews)
>>
>> This isn't a task which has to be done by Sysadmin - the Reviewboard
>> WebAPI is accessible (within reasonable usage of course) to anyone
>> with an Identity account. To be honest it would be better that it be
>> done by someone who works with the reviews, as they'll be more aware
>> of the issues surrounding various forms of presentation (threading,
>> etc) that needs to be taken care of.
>
> Come shutdown day, disable login and then dump the website with wget
> or something alike. Someone who's complaining can write a script so
> sysadmins don't have to spend time on this ...
>
> Here's your starting point
> wget --mirror --convert-links --backup-converted --adjust-extension
> --page-requisites https://git.reviewboard.kde.org
>
> Then use that to replace the php version. The builtin search won't
> work but such is life.

Reviewboard is a Python application :)

>
> http://i.imgur.com/A9z0RYJ.png

Interesting, I would have assumed that due to all the AJAX it uses
that a wget mirror wouldn't work...
We've used that a few times to shutdown things like old Akademy sites,
so if it works that's fine with me.

Cheers,
Ben

[Differential] [Closed] D4398: Don't generate appdata if it's marked as NoDisplay

[Aleix Pol Gonzalez]

This revision was automatically updated to reflect the committed changes.
Closed by commit R290:102f68a42760: Don't generate appdata if it's marked as 
NoDisplay (authored by apol).

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4398?vs=10827=10853

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

AFFECTED FILES
  KF5PackageMacros.cmake
  src/kpackagetool/kpackagetool.cpp

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

To: apol, #plasma, #frameworks, mart
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Closed] D4396: Specify NoDisplay type

[Aleix Pol Gonzalez]

This revision was automatically updated to reflect the committed changes.
Closed by commit R242:6659517bce2d: Specify NoDisplay type (authored by apol).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4396?vs=10825=10852

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

AFFECTED FILES
  src/plasma/data/servicetypes/plasma-applet.desktop

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

To: apol, #plasma, #frameworks, davidedmundson, mart
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Accepted] D4396: Specify NoDisplay type

[Marco Martin]

mart accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

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

To: apol, #plasma, #frameworks, davidedmundson, mart
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Accepted] D4398: Don't generate appdata if it's marked as NoDisplay

[Marco Martin]

mart accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R290 KPackage

BRANCH
  master

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

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

To: apol, #plasma, #frameworks, mart
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Request, 23 lines] D4405: [KFilePreviewGenerator] Add ignoreMaximumSize

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: dfaure, emmanuelp, hein.
broulik set the repository for this revision to R241 KIO.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  This allows a user of this class to set the ignoreMaximumSize flag in the 
PreviewJobs used.

TEST PLAN
  Dolphin has a logic where it will always ignore the maximum size for local 
files (isLocalFile or protocolClass == ":local"). This doesn't work in 
FolderView which uses this class to generate previews for its files.
  
  The question on the other hand is whether we should just adopt this policy 
globally in PreviewJob itself instead.

REPOSITORY
  R241 KIO

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

AFFECTED FILES
  src/filewidgets/kfilepreviewgenerator.cpp
  src/filewidgets/kfilepreviewgenerator.h

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

To: broulik, dfaure, emmanuelp, hein
Cc: #frameworks

[Differential] [Abandoned] D4201: Make it possible to lower KCrash to tier 1

[Aleix Pol Gonzalez]

apol abandoned this revision.

REPOSITORY
  R285 KCrash

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

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

To: apol, #frameworks, dfaure
Cc: shumski, anthonyfieroni, graesslin

[Differential] [Closed] D4357: Re-enable Log-to-File for KNotifications

[Christoph Feck]

cfeck closed this revision.
cfeck added a comment.


  Submitted, but was not closed automatically.
  
  
https://commits.kde.org/knotifications/cd83fadb9888ff344f7b89deda5b17ecbba94b1c

REPOSITORY
  R289 KNotifications

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

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

To: cfeck, mck182
Cc: #frameworks

[Differential] [Updated] D4329: KMessageWidget: fix behaviour on overlapping calls of animatedShow/animatedHide

[Dominik Haumann]

dhaumann added a comment.


  First of all a general note: Unfortunately, we have had quite some issues 
with getting the geometry right in KMessageWidget over the past few years. 
Essentially, the problem is that KMessageWidgets animates its show and hide 
events, and therefore caches its initial and its final geometry, as well as the 
pixmap to render to avoid stretching the KMessageWidget's contents. That said, 
doing this caching too early results in a final geometry that is wrong (we had 
this issue in Kate a lot).
  
  This may sound a bit off-topic, but the point is: it's easy to break things. 
If you in addition also run the unit test 'messagetest' of KTextEditor and if 
it passes, then I'm fine with this change. It looks reasonable after all :-)

REPOSITORY
  R236 KWidgetsAddons

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

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

To: kossebau, #frameworks, dhaumann
Cc: cfeck

Re: breeze-icons and the symlink business

[Harald Sitter]

On Thu, Feb 2, 2017 at 12:24 PM, Jaroslaw Staniek  wrote:
>
>
> On 2 February 2017 at 00:49, Harald Sitter  wrote:
>>
>> hola
>>
>> breeze-icons uses lots of symlinks. Unfortunately, ever so often our
>> icon designers make a mistake and create a bad symlink. To mitigate
>> this I added a bunch of tests making sure everything is nice and
>> dandy.
>>
>> In the mean parts of the build were changed to not tolerate broken
>> symlinks. While I don't really have a problem with that in of itself,
>> the code largely simply ignores the possibility of broken symlinks and
>> fails with the most shitty error messages you could think of. Given
>> our artists are not software engineers they are having a hard time
>> figuring out what is going on. And TBH, I too had to stat files to get
>> to the bottom of the errors. This is a fairly shit situation as on the
>> one hand we want lovely icons and on the other hand the people working
>> on the icons can't understand what needs fixing without having to find
>> a developer they aren't too afraid of to talk to.
>>
>> This really needs fixing.
>>
>> Notably offenders I had a fight with today:
>>
>>
>> # breeze-validate-svg (introduced by Jos)
>>
>> This is a bash script running xmllint.
>>
>> ## Problem 1: Sources
>>
>> The custom target sets `SOURCES ${SVGS}` this has no notable advantage
>> other than making the svgs show up in an IDE, it does however mean
>> that cmake will try to inspect them (as a build tool does when they
>> get told something is a source) and then falls flat on the face when
>> it encounters a broken symlink as it now can't determine the source
>> type resulting in this lovely error
>>
>> ```
>> 21:39:07 CMake Error at CMakeLists.txt:70 (add_custom_target):
>> 21:39:07   Cannot find source file:
>> 21:39:07
>> 21:39:07
>> /home/jenkins/sources/breeze-icons/kf5-qt5/icons-dark/categories/32/applications-other.svg
>> ```
>>
>> ## Problem 2: The code
>>
>> The bash code in of itself runs find with -exec on xmllint. Problem
>> being that if the symlink is broken xmllint will (rightfully) complain
>>
>> ```
>> warning: failed to load external entity
>> "./icons-dark/categories/32/applications-other.svg"
>> ```
>>
>> While that is much better than the earlier problem it's still plenty
>> unobvious what the underlying cause for this is. Supposedly the script
>> should skip bogus symlinks.
>>
>> ## Problem 3: Oh but really
>>
>> This isn't really related to the issue of bad symlink handling:
>>
>> - apparently this didn't get a review. why ever would this not get a
>> review?
>> - this should be a test and only run when testing is enabled
>> - when xmllint is not present it should report this in some form or
>> fashion during the test run so one knows linting is not done
>> - it should record its complaints via ctest so jenkins can display them
>> properly
>> - I fail to appreciate the reason this needs to depend on bash (versus
>> sh, or well, neither)
>>
>> ## Fix Suggestion
>>
>> - don't needlesly set SOURCE
>> - don't pass bad paths to xmllint
>> - deal with stuff in problem 3
>>
>>
>> # RCC generation (introduced by Gleb, enabled by Jaroslaw)
>>
>> This is a bunch of cmake rigging and helper binaries to assemble the
>> icons into an rcc.
>>
>> ## Problem
>>
>> `cmake -E copy_directory` is used to copy the src tree of the themes
>> into the build dir from which the resource file gets assembled. I am
>> guessing copy_directory does not preserver, but resolve symlinks
>> because it greets us with the ever so opaque error:
>>
>> ```
>> Error copying directory from
>> "/home/me/src/git/breeze-icons/icons-dark" to
>> "/home/me/src/git/breeze-icons/build/icon
>> s-dark/res".
>> ```
>>
>> ## Fix Suggestion
>>
>> This is slightly less trivial since the rcc/qrc helpers seem to depend
>> on resolved symlinks, so I am guessing a way to deal with this would
>> be to use cmake's `file(COPY...)` instead of copy_directory and then
>> have another helper run through the directories to flatten out the
>> symlinks (dropping broken symlinks).
>>
>
> Thanks for so detailed research, Harald.
> For the problem #3 I am wondering why the copying should be performed at all
> if a
>
> symlink is invalid. If I understand correctly, how about checking the
> symlinks first and if there are no issues, copying which will go OK?
> That's assuming the symlinks check is not a part of autotests but the actual
> build.

The reason it is an autotest right now is because failure in a test is
more structured and easier to read in jenkins. That said, if you don't
want to skip broken links during the copy we could move the symlink
check to build time at the cost of having it slightly harder to find
the output. It certainly beats the obscure errors we have right now.

Personally, I think

Re: KConfig issues prevent compiling KDE applications under Windows

[Milian Wolff]

On Mittwoch, 1. Februar 2017 14:34:37 CET David Faure wrote:
> On mardi 31 janvier 2017 07:58:15 CET Jasem Mutlaq wrote:
> > Hello,
> > 
> > KConfig used to work perfectly fine under Windows. I recently tried to
> > compile KStars under Windows 10 (64bit) with MSVC 2015 and Qt 5.8 using
> > Craft, but encountered an issue as explained in this bug report:
> > 
> > https://bugs.kde.org/show_bug.cgi?id=375654
> > 
> > I talked with Craft maintainers (Hannah et al) and they told me this was
> > an
> > issue from KConfig side, not Craft. Can someone please look into this and
> > fix it as it our release is dependent on this.
> 
> KF5ConfigCore.lib(KF5ConfigCore.dll) : error LNK2005: "public: class
> QMap::iterator __cdecl
> KEntryMap::findEntry(class QByteArray const &,class QByteArray const
> &,class QFlags KEntryMap::SearchFlag>)" (?findEntry@KEntryMap@@QEAA?AVite
> rator@?$QMap@UKEntryKey@@UKEntryAEBVQByteArray@@0V?
> $QFlags@W4SearchFlag@KEntryMap@Z)
> already defined in kconfigdata.cpp.obj
> 
> Thanks MSVC for a very readable error message as always ;)
> 
> One note though: this is a failure to link a unittest, your release isn't
> blocked, you can just disable the building of unittests in kconfig.
> 
> The double definition can be explained, the unittest links to KF5ConfigCore
> and then also compiles in ../src/core/kconfigdata.cpp because that class is
> not exported. This is something we do in quite a number of other places
> too, always for autotests.

This is a violation of ODR and thus undefined behavior. Afaik even with clang 
you can hit issues in such situations - I know I've seen this with clang on 
KDevelop.

> kde-windows people, if you confirm there is no way to make this work
> (some linker flag maybe?), then I do see one solution: the one used by Qt
> (and konqueror), which is an export macro that only exports the class when
> compilation of autotests is enabled. See konqueror/src/konqprivate_export.h
> for an example.

That should be done, imo.

Bye

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 410 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/410/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 11:04:57 +
Build duration: 5 min 11 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 274/343 (80%)CLASSES 274/343 (80%)LINE 29542/51606 
(57%)CONDITIONAL 16213/38743 (42%)

By packages
  
autotests
FILES 67/67 (100%)CLASSES 67/67 (100%)LINE 7918/8245 
(96%)CONDITIONAL 4430/8664 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 97/117 (83%)CLASSES 97/117 (83%)LINE 7881/14179 
(56%)CONDITIONAL 4327/9259 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 26/36 (72%)CLASSES 26/36 (72%)LINE 3449/7559 
(46%)CONDITIONAL 1281/4381 (29%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 447/849 (53%)CONDITIONAL 
330/749 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1763/3780 
(47%)CONDITIONAL 1261/3460 (36%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 621/782 (79%)CONDITIONAL 
607/839 (72%)
src.ioslaves.trash
FILES 8/10 (80%)CLASSES 8/10 (80%)LINE 705/1139 
(62%)CONDITIONAL 402/833 (48%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 242/727 (33%)CONDITIONAL 
150/546 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 21/29 (72%)CONDITIONAL 
16/26 (62%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 237/266 (89%)CONDITIONAL 
332/412 (81%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3639/11016 
(33%)CONDITIONAL 1747/7096 (25%)

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 410 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/410/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 11:04:57 +
Build duration: 5 min 11 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 274/343 (80%)CLASSES 274/343 (80%)LINE 29542/51606 
(57%)CONDITIONAL 16213/38743 (42%)

By packages
  
autotests
FILES 67/67 (100%)CLASSES 67/67 (100%)LINE 7918/8245 
(96%)CONDITIONAL 4430/8664 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 97/117 (83%)CLASSES 97/117 (83%)LINE 7881/14179 
(56%)CONDITIONAL 4327/9259 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 26/36 (72%)CLASSES 26/36 (72%)LINE 3449/7559 
(46%)CONDITIONAL 1281/4381 (29%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 447/849 (53%)CONDITIONAL 
330/749 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1763/3780 
(47%)CONDITIONAL 1261/3460 (36%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 621/782 (79%)CONDITIONAL 
607/839 (72%)
src.ioslaves.trash
FILES 8/10 (80%)CLASSES 8/10 (80%)LINE 705/1139 
(62%)CONDITIONAL 402/833 (48%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 242/727 (33%)CONDITIONAL 
150/546 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 21/29 (72%)CONDITIONAL 
16/26 (62%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 237/266 (89%)CONDITIONAL 
332/412 (81%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3639/11016 
(33%)CONDITIONAL 1747/7096 (25%)

Re: breeze-icons and the symlink business

[Jaroslaw Staniek]

On 2 February 2017 at 00:49, Harald Sitter  wrote:

> hola
>
> breeze-icons uses lots of symlinks. Unfortunately, ever so often our
> icon designers make a mistake and create a bad symlink. To mitigate
> this I added a bunch of tests making sure everything is nice and
> dandy.
>
> In the mean parts of the build were changed to not tolerate broken
> symlinks. While I don't really have a problem with that in of itself,
> the code largely simply ignores the possibility of broken symlinks and
> fails with the most shitty error messages you could think of. Given
> our artists are not software engineers they are having a hard time
> figuring out what is going on. And TBH, I too had to stat files to get
> to the bottom of the errors. This is a fairly shit situation as on the
> one hand we want lovely icons and on the other hand the people working
> on the icons can't understand what needs fixing without having to find
> a developer they aren't too afraid of to talk to.
>
> This really needs fixing.
>
> Notably offenders I had a fight with today:
>
>
> # breeze-validate-svg (introduced by Jos)
>
> This is a bash script running xmllint.
>
> ## Problem 1: Sources
>
> The custom target sets `SOURCES ${SVGS}` this has no notable advantage
> other than making the svgs show up in an IDE, it does however mean
> that cmake will try to inspect them (as a build tool does when they
> get told something is a source) and then falls flat on the face when
> it encounters a broken symlink as it now can't determine the source
> type resulting in this lovely error
>
> ```
> 21:39:07 CMake Error at CMakeLists.txt:70 (add_custom_target):
> 21:39:07   Cannot find source file:
> 21:39:07
> 21:39:07 /home/jenkins/sources/breeze-icons/kf5-qt5/icons-dark/
> categories/32/applications-other.svg
> ```
>
> ## Problem 2: The code
>
> The bash code in of itself runs find with -exec on xmllint. Problem
> being that if the symlink is broken xmllint will (rightfully) complain
>
> ```
> warning: failed to load external entity
> "./icons-dark/categories/32/applications-other.svg"
> ```
>
> While that is much better than the earlier problem it's still plenty
> unobvious what the underlying cause for this is. Supposedly the script
> should skip bogus symlinks.
>
> ## Problem 3: Oh but really
>
> This isn't really related to the issue of bad symlink handling:
>
> - apparently this didn't get a review. why ever would this not get a
> review?
> - this should be a test and only run when testing is enabled
> - when xmllint is not present it should report this in some form or
> fashion during the test run so one knows linting is not done
> - it should record its complaints via ctest so jenkins can display them
> properly
> - I fail to appreciate the reason this needs to depend on bash (versus
> sh, or well, neither)
>
> ## Fix Suggestion
>
> - don't needlesly set SOURCE
> - don't pass bad paths to xmllint
> - deal with stuff in problem 3
>
>
> # RCC generation (introduced by Gleb, enabled by Jaroslaw)
>
> This is a bunch of cmake rigging and helper binaries to assemble the
> icons into an rcc.
>
> ## Problem
>
> `cmake -E copy_directory` is used to copy the src tree of the themes
> into the build dir from which the resource file gets assembled. I am
> guessing copy_directory does not preserver, but resolve symlinks
> because it greets us with the ever so opaque error:
>
> ```
> Error copying directory from
> "/home/me/src/git/breeze-icons/icons-dark" to
> "/home/me/src/git/breeze-icons/build/icon
> s-dark/res".
> ```
>
> ## Fix Suggestion
>
> This is slightly less trivial since the rcc/qrc helpers seem to depend
> on resolved symlinks, so I am guessing a way to deal with this would
> be to use cmake's `file(COPY...)` instead of copy_directory and then
> have another helper run through the directories to flatten out the
> symlinks (dropping broken symlinks).
>
>
​Thanks for so detailed research, Harald.
For the problem #3 I am wondering why the copying should be performed at
all if a​

​symlink is invalid. If I understand correctly, how about checking the
symlinks first and if there are no issues, copying which will go OK?
That's assuming the symlinks check is not a part of autotests but the
actual build.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

Re: Phabricator: All repositories registered - upcoming workflow changes

[Harald Sitter]

On Thu, Feb 2, 2017 at 10:31 AM, Ben Cooksley  wrote:
> On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano  
> wrote:
>> Il 02.02.2017 10:09 Ben Cooksley ha scritto:
>>
>>> Hi all,
>>>
>>> As a starting point: keeping the software itself running is a
>>> non-starting option from my perspective. It's going to be shutdown.
>>> This is purely to reduce the amount of maintenance effort we have to
>>> expend in keeping our systems running.
>>
>>
>> Sorry Ben, but this is not the solution. See below.
>>
>>> There is an enormous amount of software and other systems deployed on
>>> our infrastructure, and the value of continuing to maintain software,
>>> including associated security updates, major upgrades to ensure we're
>>> able to continue running it on modern distributions, etc for something
>>> which is no longer in active use is questionable at best. Bitrot and
>>> decay is almost guaranteed to erode the value of it as a historical
>>> archive in the long run in any case.
>>>
>>> For those who dismiss decay as an issue - problems with previous
>>> Reviewboard upgrades not taking cleanly have resulted in some reviews
>>> being damaged, causing their diffs to become unavailable. These sorts
>>> of problems do happen.
>>
>>
>> If it is a resource problem, it can be addressed elsewhere as well. The e.V.
>> can hire people.
>>
>>> Whether some kind of read only archive is retained is another topic
>>> altogether.
>>>
>>> Reviewboard has a WebAPI which should be usable by anyone interested
>>> to extract all the information regarding reviews, including their
>>> comments and the diff itself. This could be used to create a static
>>> snapshot of each review.
>>
>>
>> Here I disagree, I think it is exactly the same issue. Without a read only
>> archive, easily accessibile like the current reviewboard (for which a static
>> copy will be the best solution), we need to keep the site up and it is not
>> thinkable that anyone would go and extract single reviews. It should be
>> available for all the content.
>
> The above point was giving an indication of how exactly someone with a
> vested interest in creating a read only archive would go about it.
> Whilst I haven't checked, I would imagine API exists to retrieve the
> list of reviews (although it's an incrementing number, with a large
> gap between the last number of SVN reviews and the first of the Git
> reviews)
>
> This isn't a task which has to be done by Sysadmin - the Reviewboard
> WebAPI is accessible (within reasonable usage of course) to anyone
> with an Identity account. To be honest it would be better that it be
> done by someone who works with the reviews, as they'll be more aware
> of the issues surrounding various forms of presentation (threading,
> etc) that needs to be taken care of.

Come shutdown day, disable login and then dump the website with wget
or something alike. Someone who's complaining can write a script so
sysadmins don't have to spend time on this ...

Here's your starting point
wget --mirror --convert-links --backup-converted --adjust-extension
--page-requisites https://git.reviewboard.kde.org

Then use that to replace the php version. The builtin search won't
work but such is life.

http://i.imgur.com/A9z0RYJ.png

Jenkins-kde-ci: kross master kf5-qt5 » Linux,gcc - Build # 394 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kross%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/394/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:58:41 +
Build duration: 1 min 10 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 2/13 (15%)CLASSES 2/13 (15%)LINE 132/947 
(14%)CONDITIONAL 66/564 (12%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 56/56 (100%)CONDITIONAL 
33/50 (66%)
src.core
FILES 1/12 (8%)CLASSES 1/12 (8%)LINE 76/891 (9%)CONDITIONAL 
33/514 (6%)

Jenkins-kde-ci: kross master kf5-qt5 » Linux,gcc - Build # 394 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kross%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/394/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:58:41 +
Build duration: 1 min 10 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 2/13 (15%)CLASSES 2/13 (15%)LINE 132/947 
(14%)CONDITIONAL 66/564 (12%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 56/56 (100%)CONDITIONAL 
33/50 (66%)
src.core
FILES 1/12 (8%)CLASSES 1/12 (8%)LINE 76/891 (9%)CONDITIONAL 
33/514 (6%)

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

Could this be of any help?
https://www.cloudpipes.com/integrations/phabricator/reviewboard
A paying service, but if the integration allows migration of existing 
ReviewBoard stuff into Phabricator a well-timed 2-month trial (or multiple 
thereof ;)) might suffice?

There's also this:
https://secure.phabricator.com/T3179


On Thursday February 2 2017 22:09:34 Ben Cooksley wrote:

>For those who dismiss decay as an issue - problems with previous
>Reviewboard upgrades not taking cleanly have resulted in some reviews
>being damaged, causing their diffs to become unavailable. These sorts
>of problems do happen.

Yes, I bet they do, and I bet there are ways to prevent them from happening.
Bitrot should not be an issue with the ready availability of ZFS (on Linux or 
BSD, FreeNAS etc) and btrfs, and 

>Reviewboard has a WebAPI which should be usable by anyone interested
>to extract all the information regarding reviews, including their
>comments and the diff itself. This could be used to create a static
>snapshot of each review.

Is it just me or does this convey a suggestion that projects that would like to 
be able to use review procedures the way Francis described better run their own 
service if they want reliability and not have to cope with essentially random 
transitions that discard entire histories?

R

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 409 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/409/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:37:16 +
Build duration: 18 min

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 
53 test(s)Failed: TestSuite.kiofilewidgets-kfilewidgettest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 274/343 (80%)CLASSES 274/343 (80%)LINE 29560/51606 
(57%)CONDITIONAL 16224/38743 (42%)

By packages
  
autotests
FILES 67/67 (100%)CLASSES 67/67 (100%)LINE 7918/8245 
(96%)CONDITIONAL 4428/8664 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 97/117 (83%)CLASSES 97/117 (83%)LINE 7900/14179 
(56%)CONDITIONAL 4344/9259 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 26/36 (72%)CLASSES 26/36 (72%)LINE 3451/7559 
(46%)CONDITIONAL 1278/4381 (29%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 447/849 (53%)CONDITIONAL 
330/749 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1755/3780 
(46%)CONDITIONAL 1252/3460 (36%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 621/782 (79%)CONDITIONAL 
607/839 (72%)
src.ioslaves.trash
FILES 8/10 (80%)CLASSES 8/10 (80%)LINE 715/1139 
(63%)CONDITIONAL 411/833 (49%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 372/594 (63%)CONDITIONAL 
276/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 242/727 (33%)CONDITIONAL 
150/546 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 21/29 (72%)CONDITIONAL 
16/26 (62%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 237/266 (89%)CONDITIONAL 
332/412 (81%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3639/11016 
(33%)CONDITIONAL 1748/7096 (25%)

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 226 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/226/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:39:37 +
Build duration: 1 min 55 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.kservicetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5483/8008 
(68%)CONDITIONAL 2970/6178 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1464/1554 
(94%)CONDITIONAL 893/1792 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1766/3045 
(58%)CONDITIONAL 764/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2037/2796 
(73%)CONDITIONAL 1228/2066 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

[Differential] [Commented On] D4247: KIconEngine: Center icon in requested rect

[David Rosca]

drosca added a comment.


  Ping

REPOSITORY
  R302 KIconThemes

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

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

To: drosca, #frameworks

Jenkins-kde-ci: kservice master kf5-qt5 » Linux,gcc - Build # 231 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/231/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:39:13 +
Build duration: 1 min 57 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.kservicetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5483/8008 
(68%)CONDITIONAL 2971/6178 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1464/1554 
(94%)CONDITIONAL 895/1792 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1766/3045 
(58%)CONDITIONAL 763/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2037/2796 
(73%)CONDITIONAL 1228/2066 (59%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Thu, Feb 2, 2017 at 10:23 PM, Luigi Toscano  wrote:
> Il 02.02.2017 10:09 Ben Cooksley ha scritto:
>
>> Hi all,
>>
>> As a starting point: keeping the software itself running is a
>> non-starting option from my perspective. It's going to be shutdown.
>> This is purely to reduce the amount of maintenance effort we have to
>> expend in keeping our systems running.
>
>
> Sorry Ben, but this is not the solution. See below.
>
>> There is an enormous amount of software and other systems deployed on
>> our infrastructure, and the value of continuing to maintain software,
>> including associated security updates, major upgrades to ensure we're
>> able to continue running it on modern distributions, etc for something
>> which is no longer in active use is questionable at best. Bitrot and
>> decay is almost guaranteed to erode the value of it as a historical
>> archive in the long run in any case.
>>
>> For those who dismiss decay as an issue - problems with previous
>> Reviewboard upgrades not taking cleanly have resulted in some reviews
>> being damaged, causing their diffs to become unavailable. These sorts
>> of problems do happen.
>
>
> If it is a resource problem, it can be addressed elsewhere as well. The e.V.
> can hire people.
>
>> Whether some kind of read only archive is retained is another topic
>> altogether.
>>
>> Reviewboard has a WebAPI which should be usable by anyone interested
>> to extract all the information regarding reviews, including their
>> comments and the diff itself. This could be used to create a static
>> snapshot of each review.
>
>
> Here I disagree, I think it is exactly the same issue. Without a read only
> archive, easily accessibile like the current reviewboard (for which a static
> copy will be the best solution), we need to keep the site up and it is not
> thinkable that anyone would go and extract single reviews. It should be
> available for all the content.

The above point was giving an indication of how exactly someone with a
vested interest in creating a read only archive would go about it.
Whilst I haven't checked, I would imagine API exists to retrieve the
list of reviews (although it's an incrementing number, with a large
gap between the last number of SVN reviews and the first of the Git
reviews)

This isn't a task which has to be done by Sysadmin - the Reviewboard
WebAPI is accessible (within reasonable usage of course) to anyone
with an Identity account. To be honest it would be better that it be
done by someone who works with the reviews, as they'll be more aware
of the issues surrounding various forms of presentation (threading,
etc) that needs to be taken care of.

>
> --
> Luigi
>
>
> Con Open 4 Giga a 9 euro/4 sett navighi veloce, chiami e invii SMS dal tuo
> smartphone verso tutti i fissi e mobili in Italia. Passa a Tiscali Mobile!
> http://casa.tiscali.it/mobile/
>
>

Regards,
Ben

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 495 - 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/495/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:15:20 +
Build duration: 3 min 24 sec

CHANGE SET
Revision 38fcfc70aa987b2642b00571da76083ec9358bc4 by scripty: (Upgrade Qt5 
version requirement to 5.6.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/495/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:15:20 +
Build duration: 3 min 24 sec

CHANGE SET
Revision 38fcfc70aa987b2642b00571da76083ec9358bc4 by scripty: (Upgrade Qt5 
version requirement to 5.6.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 219/268 
(82%)CONDITIONAL 122/206 (59%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 177/211 (84%)CONDITIONAL 
108/180 (60%)

Re: Phabricator: All repositories registered - upcoming workflow changes

[Luigi Toscano]

Il 02.02.2017 10:09 Ben Cooksley ha scritto:


Hi all,

As a starting point: keeping the software itself running is a
non-starting option from my perspective. It's going to be shutdown.
This is purely to reduce the amount of maintenance effort we have to
expend in keeping our systems running.


Sorry Ben, but this is not the solution. See below.


There is an enormous amount of software and other systems deployed on
our infrastructure, and the value of continuing to maintain software,
including associated security updates, major upgrades to ensure we're
able to continue running it on modern distributions, etc for 
something

which is no longer in active use is questionable at best. Bitrot and
decay is almost guaranteed to erode the value of it as a historical
archive in the long run in any case.

For those who dismiss decay as an issue - problems with previous
Reviewboard upgrades not taking cleanly have resulted in some reviews
being damaged, causing their diffs to become unavailable. These sorts
of problems do happen.


If it is a resource problem, it can be addressed elsewhere as well. The 
e.V. can hire people.



Whether some kind of read only archive is retained is another topic
altogether.

Reviewboard has a WebAPI which should be usable by anyone interested
to extract all the information regarding reviews, including their
comments and the diff itself. This could be used to create a static
snapshot of each review.


Here I disagree, I think it is exactly the same issue. Without a read 
only archive, easily accessibile like the current reviewboard (for which 
a static copy will be the best solution), we need to keep the site up 
and it is not thinkable that anyone would go and extract single reviews. 
It should be available for all the content.


--
Luigi


Con Open 4 Giga a 9 euro/4 sett navighi veloce, chiami e invii SMS dal 
tuo smartphone verso tutti i fissi e mobili in Italia. Passa a Tiscali 
Mobile! http://casa.tiscali.it/mobile/

Jenkins-kde-ci: bluez-qt master stable-kf5-qt5 » Linux,gcc - Build # 127 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/bluez-qt%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/127/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 02 Feb 2017 09:14:15 +
Build duration: 2 min 39 sec

CHANGE SET
Revision 89e72d2e7e56172483c6f39856581b36d8a90495 by scripty: (Upgrade Qt5 
version requirement to 5.6.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.bluezqt-qmltests

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 65/86 (76%)CLASSES 65/86 (76%)LINE 2845/4099 
(69%)CONDITIONAL 1721/4158 (41%)

By packages
  
autotests
FILES 18/18 (100%)CLASSES 18/18 (100%)LINE 1327/1368 
(97%)CONDITIONAL 1239/2872 (43%)
src
FILES 37/54 (69%)CLASSES 37/54 (69%)LINE 1179/2299 
(51%)CONDITIONAL 459/1228 (37%)
src.imports
FILES 10/14 (71%)CLASSES 10/14 (71%)LINE 339/432 
(78%)CONDITIONAL 23/58 (40%)

Re: Raising the requirement to Qt 5.6 ?

[David Faure]

On mercredi 1 février 2017 23:04:18 CET Albert Astals Cid wrote:
> El dimecres, 1 de febrer de 2017, a les 14:16:35 CET, David Faure va 
escriure:
> > On mardi 31 janvier 2017 01:25:58 CET Aleix Pol wrote:
> > > On Tue, Jan 31, 2017 at 12:59 AM, Albert Astals Cid  
wrote:
> > > > Now that Qt 5.8 is out, should we increase requirement to Qt 5.6 as
> > > > the
> > > > rules say?
> > > 
> > > +1
> > > Let's!
> > 
> > Yes, the good thing about generic rules is that we can apply them without
> > having to re-negociate ;-)
> 
> So does anyone actually have a script to do this?

Oh, right, I do (of course) :-)

Running it now (and I'll commit the script in release-tools)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi all,

As a starting point: keeping the software itself running is a
non-starting option from my perspective. It's going to be shutdown.
This is purely to reduce the amount of maintenance effort we have to
expend in keeping our systems running.

There is an enormous amount of software and other systems deployed on
our infrastructure, and the value of continuing to maintain software,
including associated security updates, major upgrades to ensure we're
able to continue running it on modern distributions, etc for something
which is no longer in active use is questionable at best. Bitrot and
decay is almost guaranteed to erode the value of it as a historical
archive in the long run in any case.

For those who dismiss decay as an issue - problems with previous
Reviewboard upgrades not taking cleanly have resulted in some reviews
being damaged, causing their diffs to become unavailable. These sorts
of problems do happen.

Whether some kind of read only archive is retained is another topic altogether.

Reviewboard has a WebAPI which should be usable by anyone interested
to extract all the information regarding reviews, including their
comments and the diff itself. This could be used to create a static
snapshot of each review.

Regards,
Ben