> On oct. 5, 2014, 7: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? > > Marko Käning wrote: > 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. > > Thomas Lübking wrote: > Screw OSX ;-) > > Afaiu DrKonqui is dysfunctional due to bugzilla server changes atm. (bug > #337742) what means either this or review > https://git.reviewboard.kde.org/r/120376/ more or less *has* to go into KDE > SC4 - regardless on whether it's required for exotic OS' or not. > > @Ian, please attach Jekyll Wu, George Kiagiadakis, Matthias Fuchs and > Dario Andres Rodriguez, they've been the main submitters to bugzillalib. > > Ian Wadham wrote: > Feel free to cancel anything I may commit, Albert, but you could be doing > both yourself and KDE software (4 and 5) a disservice. Bug > https://bugs.kde.org/show_bug.cgi?id=337742 will remain... > > I only said "perhaps" in my statement about the codebase, hoping someone > more knowledgeable would step up. > > If you will read the Description of this review (Note 2) and the dialog > in https://git.reviewboard.kde.org/r/120376/ you will find that I have > already had some input to the other review and given it some thought. > > Last week I was expecting a core developer who knows Dr Konqi to review > both patches, but nobody did. This week I have a course to prepare, for > presentation tomorrow, so I have no time, and KDE 4.14.2 closes on Thursday. > I do not even know whether Frédéric has commit privileges. > > One swallow does not make a summer. Only Marko Kaening can build KF5 and > Qt5, on his personal setup, and he is having great difficulties getting > applications to run - even such a simple one as Bovo. There is also a > technical difficulty on MacPorts in providing Qt4 and Qt5 libraries > simultaneously. The MacPorts Qt port developer is working on it. It seems > that KF5 and Qt5 will not be generally available on Apple OS X for several > weeks or months. We are currently concentrating on getting a reliable release > of KDE 4.13 into production on MacPorts... > > Re my attitude to KF5. I have offered the current patch to anyone who > wants to take it into KF5. As you know, I am very old and have already spent > 10 or more years as a KDE developer. I decided, early this year, to retire > from KDE development. KF5 was the clincher. I have no desire to engage in any > more library-induced "porting" of applications. I consider it boring, > counter-productive and quite contrary to my personal and professional > philosophy, which is to make library and operating environment changes as > inconspicuous as possible to application writers and end-users, thus > maximizing *their* productivity. > > I say this with my (pre-retirement) core-developer, system architect and > release-team hat on. > > Ian Wadham wrote: > @Thomas, I could only get Dario Andres and Jekyll Wu in the space allowed > by ReviewBoard. Too bad. > > Glad you are starting to see things my way, except for the comment about > OSX... :-) I really am finding some serious problems in KDE 4's core code, > mostly affecting OSX only, but some reaching out into KDE4/Linux&Windows or > even KF5... :-(
> Feel free to cancel anything I may commit, Albert, but you could be doing > both yourself and KDE software (4 and 5) a disservice. Bug > https://bugs.kde.org/show_bug.cgi?id=337742 will remain... I thought you said that the other patch would fix the immediate issue? If so that other patch which is much simpler is what should go to the stable branches, no? > I only said "perhaps" in my statement about the codebase, hoping someone more > knowledgeable would step up. Ok :/ > If you will read the Description of this review (Note 2) and the dialog in > https://git.reviewboard.kde.org/r/120376/ you will find that I have already > had some input to the other review and given it some thought. Sorry for complaining you had not commented when you actually had :/ Totally my fault :( > Last week I was expecting a core developer who knows Dr Konqi to review both > patches, but nobody did. This week I have a course to prepare, for > presentation tomorrow, so I have no time, and KDE 4.14.2 closes on Thursday. > I do not even know whether Frédéric has commit privileges. I'll ask again because I may not be understanding the whole picture. Does https://git.reviewboard.kde.org/r/120376 fix the immediate issue people is seeing? If it does in my opinion that is what should go to 4.14, your more future-proof solution but also more complex and thus prone to introduce new issues should go to master for release December. > One swallow does not make a summer. Only Marko Kaening can build KF5 and Qt5, > on his personal setup, and he is having great difficulties getting > applications to run - even such a simple one as Bovo. There is also a > technical difficulty on MacPorts in providing Qt4 and Qt5 libraries > simultaneously. The MacPorts Qt port developer is working on it. It seems > that KF5 and Qt5 will not be generally available on Apple OS X for several > weeks or months. We are currently concentrating on getting a reliable release > of KDE 4.13 into production on MacPorts... Ok, I may have misunderstood how good was the state of KF5 on Mac. > @Thomas, I could only get Dario Andres and Jekyll Wu in the space allowed by > ReviewBoard. Too bad. I added the other two people in there for you. > Glad you are starting to see things my way, except for the comment about > OSX... :-) I really am finding some serious problems in KDE 4's core code, > mostly affecting OSX only, but some reaching out into KDE4/Linux&Windows or > even KF5... :-( I am not sure what is "your way" here, can you please ellaborate? - Albert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67946 ----------------------------------------------------------- On oct. 7, 2014, 7:42 a.m., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120431/ > ----------------------------------------------------------- > > (Updated oct. 7, 2014, 7:42 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime, Ben Cooksley, Darío > Andrés Rodríguez, George Kiagiadakis, Jekyll Wu, and Matthias Fuchs. > > > 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 > >
