> On Oct. 5, 2014, 9:43 a.m., Ben Cooksley wrote: > > As this is needed to restore the functionality of Dr Konqi, can someone > > familiar with the codebase please review it so we can get this in? > > Ian Wadham wrote: > Perhaps I am the person most familiar with the codebase of Dr Konqi, > having worked on it for a few months now. > > So, if nobody else steps forward within the next 24 hours, I will do my > own "Ship It" and commit to KDE 4 kde-runtime master in time for Thursday's > close of the KDE 4.14.2 bugfix release. > > If KDE core developers want the Dr Konqi bugs fixed in KF5, they will > have to forward-port this change and my earlier changes themselves. I cannot > do that. I work on Apple OS X and we do not have KF5 and Qt 5 building there > yet. > > I do not propose to address Thomas's comments. I have more important > things to do. > > Albert Astals Cid wrote: > With my release team hat: > - Sure commit to master if you can't find someone else to review and you > *know* your code is right and you're going to fix it when/if it break > - No, don't commit to KDE/4.14 this is a huuuuuuuuuuuuuge change and I > don't feel like it is guaranteed to go in, you can be a good guy and review > https://git.reviewboard.kde.org/r/120376/ since it seems that one fixes the > immediate problems people are having, no? (you say you're the one that knows > the code more yet have not reviewed it, why?) > - Your obsession to not contribute to KF5 based versions will byte you > again when you decide to move to KF5, you should really rethink it. Because > we do have KF5 and Qt5 building on MacOsX according to at least one of the > members of the MacOSX team, no?
I wouldn not phrase it an "obsession to not to contribute to KF5". ;) In fact, it has been pointed out multiple times on KDE-MAC, in pm as well as in various RRs, that the "MacOSX team" at the moment mainly tries to get KDE4 into a working state, which is why Ian wants to push this forward. And yes, we have KF5 on Qt5 in a state where my OSX/CI(/Jenkins) systems are able to build and install many projects successfully. BUT, unfortunately, this does NOT mean that I am able to RUN every of these apps successfully, as the OSX/CI system's specifics (being that all frameworks, libs and apps live in their own install roots) in conjunction with a (still missing) working QStandardPaths patch lead to the problem that most of the apps can't find their config and data files at runtime at this point in time. :( As I am *alone* on KF5, I haven't managed to proceed with the QStandardPaths issue, since many other things kept me far too busy (like the inclusion of new projects on OSX/CI, dealing with Jenkins master [also for Linux], tending project dependencies, creating a KDE4.13 branch on our macports-kde git repo, testing KDE4 applications, etc...). Eventually I conclude herewith that the "MacOSX team": - does contribute directly to Qt5/KF5 big time - althought it is only me ATM, - does indirectly contribute to Qt5/KF5, as many RRs can be modified easily for inclusion into KF5, as it has happened already for e.g. https://git.reviewboard.kde.org/r/119847/ and https://git.reviewboard.kde.org/r/119848/ - believes that 1st priority should be to get KDE4 in good shape on OSX, which is why Nicolas wants to release KDE 4.13.3 this week and will proceed with 4.14.x right afterwards, - needs decent user feedback with valuable backtraces which is why a non-dysfunctional DrKonqi is required on all OSX versions, hence this RR. - Marko ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67946 ----------------------------------------------------------- On Oct. 5, 2014, 6: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, 6: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 > >
