Re: Moving repositories in the module structure
On Fri, Oct 3, 2014 at 11:33 AM, Víctor Blázquez victor.blazq...@kde.org wrote: I'm sorry for doing the move that fast, I should have realized it was sent only to plasma-devel No worries - in virtually all cases it is fine to process requests when we receive them. Víctor Blázquez Thanks, Ben On Fri, Oct 3, 2014 at 12:04 AM, Aleix Pol aleix...@kde.org wrote: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-de...@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Aleix
Re: Moving repositories in the module structure
On Fri, Oct 3, 2014 at 2:28 PM, Aleix Pol aleix...@kde.org wrote: On Fri, Oct 3, 2014 at 1:52 AM, Albert Astals Cid aa...@kde.org wrote: El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-de...@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. I don't think it is necessary to revert the changes at the moment. Maybe you should explain the changes so people is aware of them :) Cheers, Albert Aleix Changes: - kde-gtk-config was moved from extragear/base to kde/workspace. - muon was moved from extragear/sysadmin to kde/workspace. That is, only projects.kde.org structure change. The reasoning is that this way they will be released together with Plasma Workspace. As they've been used they don't really make sense outside Plasma (especially the first) and we want to make sure that distros know these components are designed to work together with Plasma. I didn't notify kde-core-devel because it didn't occur to me that the community would have an opinion regarding whether it's me who releases the packages or Jonathan (who has been doing the Plasma packages). Who is doing the releasing doesn't matter as such. It is the move in location which matters here - various parts of our infrastructure rely on these locations. Translations for instance. Also, while this was only a Extragear to semi-SC module called kde/workspace move, such moves still probably need announcement so those interesting in reviewing the code, etc. can do so. Cheers! Aleix Thanks, Ben
Re: Moving repositories in the module structure
I'm sorry for doing the move that fast, I should have realized it was sent only to plasma-devel Víctor Blázquez On Fri, Oct 3, 2014 at 12:04 AM, Aleix Pol aleix...@kde.org wrote: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-de...@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Aleix
Re: Fwd: PVS-Studio KDE analysis
On 10/02/2014 04:45 PM, Ben Cooksley wrote: Okay, can you confirm whether we're allowed to publish this publicly or not? Thanks, Ben Svyatoslav said yes, we're allowed to do this. -- Best regards, Boris Egorov
Re: Review Request 120195: [OS X] make sure the appropriate menu items get put in the Application menu's About and Preferences items
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120195/#review67915 --- shell/mainwindow_p.cpp https://git.reviewboard.kde.org/r/120195/#comment47343 Extra debug left? - Pino Toscano On Set. 25, 2014, 2:06 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120195/ --- (Updated Set. 25, 2014, 2:06 p.m.) Review request for KDE Software on Mac OS X, KDevelop and Qt KDE. Repository: kdevplatform Description --- This is a complement to https://git.reviewboard.kde.org/r/120149/ OS X has a so-called Application menu, sitting in the MenuBar between the Apple (?) menu and the File menu, that has items (actions) such as About and Preferences, which are meant to play the respective roles for the application. Qt4 for Mac uses `QAction::text()` based heuristics to decide which items get `PreferencesRole`, `AboutRole` etc. roles and thus are put in the Application menu. This works fine for applications that create the standard menu actions via KStandardAction. Applications that do not adhere to that scheme, or that create menu actions with matching names *before* the standard actions will end up having the wrong actions in the Application menu. For KDevelop, this means that the About menu item will invoke `About KDevelop Platform` and the Preferences item `Configure selection` (normally in the Project menu). The former misinterpretation isn't a huge deal, but launching a project's configure/cmake procedure (without any kind of confirmation asked) when you think you'll be opening a settings panel is more than just annoying. The patch is simple: set the incriminated actions' `menuRole` to `NoRole` when they are created, on OS X. This prevents them from being put in the Application menu even when the patches from the above RR are not installed (though in that latter case the Preferences menu will probably invoke another unintended action). Diffs - shell/mainwindow_p.cpp b50c444 Diff: https://git.reviewboard.kde.org/r/120195/diff/ Testing --- On OS X 10.6.8 with KDE/MacPorts 4.12.5 and kdelibs git/master with all MacPorts and my patches applied. Other platforms will not be affected by this patch. I have not yet looked into how this plays out on Qt5/KF5. The patch presented here should have the same effect if menu roles function the same way as in Qt4. If Qt5 uses comparable heuristics and `KAction` made the transition to KF5, the other kdelibs patches should port over easily. Thanks, René J.V. Bertin
Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120363/#review67927 --- See also bug 334174 - Marko Käning On Sept. 25, 2014, 3:32 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120363/ --- (Updated Sept. 25, 2014, 3:32 p.m.) Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- Applications can be defined in their CMake file as being `NOGUI`, but until now this has had very limited effect. Especially on OS X, those applications can still construct a minimal GUI and thus have visual presence in the Dock and application switcher (and have a menubar as well). This patch proposes to define a preprocessor token, `KDE_WITHOUT_GUI`, for those targets, and uses that token to set the default value for the `GUIenabled` option of the `KApplication` and `KUniqueApplication` classes. This could potentially be combined on OS X with the CoreFoundation call that turns a running application into an agent (see https://git.reviewboard.kde.org/r/120354). Diffs - cmake/modules/KDE4Macros.cmake 073d726 kdeui/kernel/kapplication.h fa2ab26 kdeui/kernel/kapplication.cpp b093034 kdeui/kernel/kuniqueapplication.h e05dcd7 Diff: https://git.reviewboard.kde.org/r/120363/diff/ Testing --- On OS X 10.6.8 with kdelibs 4.14.1 (git/kde4.14), rebuilt kdelibs, kde-workspace, kde-runtime, kde-baseapps, kdepim-runtime and nepomuk-core. If the documentation I read is correct, the `GUIenabled` switch has no effect on Linux, so this patch shouldn't have any either on that OS. Thanks, René J.V. Bertin
SDDM-KCM In Review
Hey all, I want to merge SDDM-KCM [1] into Plasma for 5.2. It's in kdereview now starting the mandatory review period. It's a config module for configuring SDDM, the Display Manager. Mostly themes and autologin, plus some misc options. The final destination will be workspace. Application history: - I wrote a KCM for LightDM in Playground - This was forked and changed to work on SDDM in Github - We switched to SDDM as the recommended DM for Plasma - We want a KCM to configure it - It's easier (for translations especially) if we put the KCM back our repos - Upstream are happy for this to happen [1] David [1] https://projects.kde.org/projects/kdereview/sddm-kcm [2] https://github.com/sddm/sddm-kcm/issues/14
Re: Review Request 120195: [OS X] make sure the appropriate menu items get put in the Application menu's About and Preferences items
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120195/ --- (Updated Oct. 4, 2014, 11:20 p.m.) Status -- This change has been marked as submitted. Review request for KDE Software on Mac OS X, KDevelop and Qt KDE. Repository: kdevplatform Description --- This is a complement to https://git.reviewboard.kde.org/r/120149/ OS X has a so-called Application menu, sitting in the MenuBar between the Apple (?) menu and the File menu, that has items (actions) such as About and Preferences, which are meant to play the respective roles for the application. Qt4 for Mac uses `QAction::text()` based heuristics to decide which items get `PreferencesRole`, `AboutRole` etc. roles and thus are put in the Application menu. This works fine for applications that create the standard menu actions via KStandardAction. Applications that do not adhere to that scheme, or that create menu actions with matching names *before* the standard actions will end up having the wrong actions in the Application menu. For KDevelop, this means that the About menu item will invoke `About KDevelop Platform` and the Preferences item `Configure selection` (normally in the Project menu). The former misinterpretation isn't a huge deal, but launching a project's configure/cmake procedure (without any kind of confirmation asked) when you think you'll be opening a settings panel is more than just annoying. The patch is simple: set the incriminated actions' `menuRole` to `NoRole` when they are created, on OS X. This prevents them from being put in the Application menu even when the patches from the above RR are not installed (though in that latter case the Preferences menu will probably invoke another unintended action). Diffs - shell/mainwindow_p.cpp b50c444 Diff: https://git.reviewboard.kde.org/r/120195/diff/ Testing --- On OS X 10.6.8 with KDE/MacPorts 4.12.5 and kdelibs git/master with all MacPorts and my patches applied. Other platforms will not be affected by this patch. I have not yet looked into how this plays out on Qt5/KF5. The patch presented here should have the same effect if menu roles function the same way as in Qt4. If Qt5 uses comparable heuristics and `KAction` made the transition to KF5, the other kdelibs patches should port over easily. Thanks, René J.V. Bertin
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67943 --- drkonqi/bugzillalib.cpp https://git.reviewboard.kde.org/r/120431/#comment47358 Perhaps use kWarning() or kDebug() instead? drkonqi/bugzillalib.cpp https://git.reviewboard.kde.org/r/120431/#comment47359 Same issue wrt fprintf vs. kDebug/kWarning. - Ben Cooksley On Oct. 3, 2014, 7:52 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 3, 2014, 7:52 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. Bugs: 337742 http://bugs.kde.org/show_bug.cgi?id=337742 Repository: kde-runtime Description --- When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security method used by Bugzilla changed from cookies to tokens that had to be supplied as parameters with every secure remote-procedure call. Further changes to security methods have been announced by Bugzilla and are documented for unstable 4.5.x versions of Bugzilla software. Tokens will be deprecated and then discontinued. When this happens, Dr Konqi will need to supply a user-login name and a password with every secure remote-procedure call. Furthermore, the traditional User.login call presently used by Dr Konqi will be deprecated and discontinued. This patch fixes the tokens problem, which has given rise to several bug reports https://bugs.kde.org/show_bug.cgi?id=337742 and duplicates. It also provides for automatic switching to passwords-only security as and when the Bugzilla version changes again. This uses a general data-driven approach which can be easily updated, ahead of time, next time Bugzilla announces a change that affects Dr Konqi, whether it be in security methods or some other feature. NOTES: 1. This patch is intended to be forward-portable to Frameworks/KF5, but I work on Apple OS X, where it is not yet possible to run Frameworks/KF5 and do the porting and testing. So could someone else please do it? 2. Another Review Request https://git.reviewboard.kde.org/r/120376/ addresses the tokens issue only, but it should be reviewed and shipped as a matter of urgency, both in KDE 4 and Frameworks, the next bug-fixing release for KDE 4.14 being due for tagging on Thursday, 9 October. That will leave more time for this review (120431) of my more long-term and more general patch. 3. The passwords-only part of my patch is currently storing the password in clear. Suggestions re encryption are welcomed --- or the code could be changed to make use of KWalletD mandatory (but that might not be fully portable to all platforms). 4. When the Bugzilla call User.login is discontinued, some re-sequencing of the flow of KAssistantDialog pages will be needed. I have not attempted to do that at this stage. Probably the entry of the user name and password should be delayed until the report has been accepted by the Dr Konqi logic and it is just about to be sent to bugs.kde.org or attached to an existing bug report. REFERENCES: http://www.bugzilla.org/docs/ http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.5.x (future) API doco re security http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.4.5 (current) API doco re security http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html#login User.login will be DEPRECATED in 4.5.x Diffs - drkonqi/bugzillalib.h 570169b drkonqi/bugzillalib.cpp f74753c drkonqi/reportassistantpages_bugzilla.h b7af5b8 drkonqi/reportassistantpages_bugzilla.cpp 22183f0 Diff: https://git.reviewboard.kde.org/r/120431/diff/ Testing --- Used the bugstest.kde.org database and KDE 4 master on KDE/kde-runtime repository. Tested a range of version numbers (see commented-out test data) against a range of 5 or 6 hypothetical and real Bugzilla versions at which things could or will change. This was to test the basic version-checking and feature-choosing algorithm. Tested submitting both full reports and attached reports, using both the token method and the passwords-only method. Also tested with KWalletD supplying the username and password on Dr Konqi's login dialog. Thanks, Ian Wadham
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 5, 2014, 4:27 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. Changes --- Changed fprintf() to kWarning() in two places. Bugs: 337742 http://bugs.kde.org/show_bug.cgi?id=337742 Repository: kde-runtime Description --- When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security method used by Bugzilla changed from cookies to tokens that had to be supplied as parameters with every secure remote-procedure call. Further changes to security methods have been announced by Bugzilla and are documented for unstable 4.5.x versions of Bugzilla software. Tokens will be deprecated and then discontinued. When this happens, Dr Konqi will need to supply a user-login name and a password with every secure remote-procedure call. Furthermore, the traditional User.login call presently used by Dr Konqi will be deprecated and discontinued. This patch fixes the tokens problem, which has given rise to several bug reports https://bugs.kde.org/show_bug.cgi?id=337742 and duplicates. It also provides for automatic switching to passwords-only security as and when the Bugzilla version changes again. This uses a general data-driven approach which can be easily updated, ahead of time, next time Bugzilla announces a change that affects Dr Konqi, whether it be in security methods or some other feature. NOTES: 1. This patch is intended to be forward-portable to Frameworks/KF5, but I work on Apple OS X, where it is not yet possible to run Frameworks/KF5 and do the porting and testing. So could someone else please do it? 2. Another Review Request https://git.reviewboard.kde.org/r/120376/ addresses the tokens issue only, but it should be reviewed and shipped as a matter of urgency, both in KDE 4 and Frameworks, the next bug-fixing release for KDE 4.14 being due for tagging on Thursday, 9 October. That will leave more time for this review (120431) of my more long-term and more general patch. 3. The passwords-only part of my patch is currently storing the password in clear. Suggestions re encryption are welcomed --- or the code could be changed to make use of KWalletD mandatory (but that might not be fully portable to all platforms). 4. When the Bugzilla call User.login is discontinued, some re-sequencing of the flow of KAssistantDialog pages will be needed. I have not attempted to do that at this stage. Probably the entry of the user name and password should be delayed until the report has been accepted by the Dr Konqi logic and it is just about to be sent to bugs.kde.org or attached to an existing bug report. REFERENCES: http://www.bugzilla.org/docs/ http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.5.x (future) API doco re security http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.4.5 (current) API doco re security http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html#login User.login will be DEPRECATED in 4.5.x Diffs (updated) - drkonqi/bugzillalib.h 570169b drkonqi/bugzillalib.cpp f74753c drkonqi/reportassistantpages_bugzilla.h b7af5b8 drkonqi/reportassistantpages_bugzilla.cpp 22183f0 Diff: https://git.reviewboard.kde.org/r/120431/diff/ Testing --- Used the bugstest.kde.org database and KDE 4 master on KDE/kde-runtime repository. Tested a range of version numbers (see commented-out test data) against a range of 5 or 6 hypothetical and real Bugzilla versions at which things could or will change. This was to test the basic version-checking and feature-choosing algorithm. Tested submitting both full reports and attached reports, using both the token method and the passwords-only method. Also tested with KWalletD supplying the username and password on Dr Konqi's login dialog. Thanks, Ian Wadham
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
On Oct. 5, 2014, 2:06 a.m., Ben Cooksley wrote: drkonqi/bugzillalib.cpp, line 161 https://git.reviewboard.kde.org/r/120431/diff/3/?file=316392#file316392line161 Perhaps use kWarning() or kDebug() instead? Done. On Oct. 5, 2014, 2:06 a.m., Ben Cooksley wrote: drkonqi/bugzillalib.cpp, line 182 https://git.reviewboard.kde.org/r/120431/diff/3/?file=316392#file316392line182 Same issue wrt fprintf vs. kDebug/kWarning. Done. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67943 --- On Oct. 5, 2014, 4:27 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 5, 2014, 4:27 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. Bugs: 337742 http://bugs.kde.org/show_bug.cgi?id=337742 Repository: kde-runtime Description --- When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security method used by Bugzilla changed from cookies to tokens that had to be supplied as parameters with every secure remote-procedure call. Further changes to security methods have been announced by Bugzilla and are documented for unstable 4.5.x versions of Bugzilla software. Tokens will be deprecated and then discontinued. When this happens, Dr Konqi will need to supply a user-login name and a password with every secure remote-procedure call. Furthermore, the traditional User.login call presently used by Dr Konqi will be deprecated and discontinued. This patch fixes the tokens problem, which has given rise to several bug reports https://bugs.kde.org/show_bug.cgi?id=337742 and duplicates. It also provides for automatic switching to passwords-only security as and when the Bugzilla version changes again. This uses a general data-driven approach which can be easily updated, ahead of time, next time Bugzilla announces a change that affects Dr Konqi, whether it be in security methods or some other feature. NOTES: 1. This patch is intended to be forward-portable to Frameworks/KF5, but I work on Apple OS X, where it is not yet possible to run Frameworks/KF5 and do the porting and testing. So could someone else please do it? 2. Another Review Request https://git.reviewboard.kde.org/r/120376/ addresses the tokens issue only, but it should be reviewed and shipped as a matter of urgency, both in KDE 4 and Frameworks, the next bug-fixing release for KDE 4.14 being due for tagging on Thursday, 9 October. That will leave more time for this review (120431) of my more long-term and more general patch. 3. The passwords-only part of my patch is currently storing the password in clear. Suggestions re encryption are welcomed --- or the code could be changed to make use of KWalletD mandatory (but that might not be fully portable to all platforms). 4. When the Bugzilla call User.login is discontinued, some re-sequencing of the flow of KAssistantDialog pages will be needed. I have not attempted to do that at this stage. Probably the entry of the user name and password should be delayed until the report has been accepted by the Dr Konqi logic and it is just about to be sent to bugs.kde.org or attached to an existing bug report. REFERENCES: http://www.bugzilla.org/docs/ http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.5.x (future) API doco re security http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html#LOGGING_IN Bugzilla 4.4.5 (current) API doco re security http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html#login User.login will be DEPRECATED in 4.5.x Diffs - drkonqi/bugzillalib.h 570169b drkonqi/bugzillalib.cpp f74753c drkonqi/reportassistantpages_bugzilla.h b7af5b8 drkonqi/reportassistantpages_bugzilla.cpp 22183f0 Diff: https://git.reviewboard.kde.org/r/120431/diff/ Testing --- Used the bugstest.kde.org database and KDE 4 master on KDE/kde-runtime repository. Tested a range of version numbers (see commented-out test data) against a range of 5 or 6 hypothetical and real Bugzilla versions at which things could or will change. This was to test the basic version-checking and feature-choosing algorithm. Tested submitting both full reports and attached reports, using both the token method and the passwords-only method. Also tested with KWalletD supplying the username and password on Dr Konqi's login dialog. Thanks, Ian Wadham
