> 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... :-( > > Albert Astals Cid 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 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: It would be a help if I could know how to do that point-by-point commenting with sidebars email-style. I can find nothing about it in RB Markdown Reference... Re https://git.reviewboard.kde.org/r/120376: the patch looks good to me, but I have not downloaded it and tested it myself and would want to do that before "shipping" and committing it. I am not convinced that "token" is OK as a parameter name in some places, as opposed to "Bugzilla_token". The Bugzilla doco seems to say the latter, but it is a bit vague in places... Also that patch would conflict with mine. So a bit of footsying around with git (locally) might be needed. I do not think I will have time tomorrow (Wednesday my time: Tues UTC 20:00 to Wed UTC 07:00), so maybe Thursday. This where being 11 hours ahead of UTC can be an advantage... ;-) Re introducing new issues, I have centralised the main changes precisely to avoid that. Of course, that has involved relocating a fair few snippets of code, which raises the line-count of the patch-file. The main addition to the code is quite large, but not very complex compared to some things in KGoldrunner or Palapeli.. :-) Would I have to commit to both master and KDE/4.14 branch? I have lost track of how you are doing KDE 4 releases now. The fix will be in the kde-runtime repo. Thanks for adding the people. Re "my way": I hope Thomas will know what I mean. He has seen that there is a rather bad bug to be fixed here. That is what I was commenting on. I guess it gets down to form vs. function, style vs. substance and perception vs. reality. I am a firm believer in the second of the two alternatives in each of the three cases. - Ian ----------------------------------------------------------- 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 > >