Re: Information regarding upcoming Gitlab Migration
Um, guys… Google is your friend... I am a former KDE Games developer. I play KPatience quite a lot, as well as other games to keep my brain active, especially during COVID-19 lockdown. Recently I thought I could see where the answer lay to three bugs in the solver(s), two in the Forty Eight variant and one, very recently reported, in the Klondike variant. So I thought I would have a look at the source code to see if my hypotheses might be correct and maybe work out a patch. My first problem was to track down where the repos that I need are and how to clone read-only copies. I didn’t even know what websites they are on any more and KPatience is actually called kpat in the code (which I remembered). However I can google “source code KDE KPatience” and the pat repository comes up as the first hit, presumably because “KPatience” is used in the repository’s description. Again “… card games” got the repo as hit 2 and “… solitaire” (the American term for such games) got it as the first hit. I have also found that several of the tricky cases mentioned earlier in this thread can be resolved with Google search terms beginning “source code KDE xxx”. For example, seeing xxx as “Plasma Mobile” get the repo as hit 2. And just using “go” as xxx finds the Kigo repository as hit 3. Even a search with xxx = “loderunner” finds the KGoldRunner repository as hit 1, even though Loderunner is not mentioned in the repository’s description. I wonder how far down repositories Google indexing goes. Even using xxx = “lode runner” (2 words), as suggested by Google, finds the KGoldrunner Handbook, though not the repository. Still, a smart newbie might guess the name used for that type of game in KDE and refine his source code search accordingly. Even after I found the kpat repository, I could not understand where the souce code was getting the card decks it uses. I knew from memory that they are in some library somewhere, but there is no libkdecards. Googling with xxx = something like “library cards” found the cards as a sub-directory of the libkdegames repository. So my suggestion is to keep whatever categories you like, including multiple categories as required, as long as the category names are in plain English, not KDE jargon. In addition, please continue to pepper repository descriptions with search terms (words) that are easy for laymen and non-core KDE developers to find. Another possibility is to construct (automatically) a text-file “catalog” with one line for each of the 1000+ repositories, containing (at least) the repo name and description, but maybe other keywords. Then people could just “grep” and “sort” it to find what they wanted. My 2 cents, Ian Wadham. > On 28 Apr 2020, at 2:46 pm, Bhushan Shah wrote: > > Hi Olivier, > > On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote: >>> Because in order to search for something, you need to know it exists. >>> >>> If you are just casually browsing, then the search can't help you. >> >> I don't think people casually browse our repos. What use case is more likely >> to happen and do we want to support? > > We don't really want to discard use-cases just because it does not suit > our workflow. That is not how we are going to gain new contributors, we > should value each contribution, be it drive-by contribution, or focused > contribution towards one single project. > >> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia >> section. After carefully reading the code of two applications and three libs >> he starts contributing to Elisa. >> >> Use case 2 : While using her Ubuntu installation of Elisa / while reading on >> reddit about Elisa, Jerry decides to try to contribute to this project/fix >> this bug that itches her and searches for it in KDE's forge. > > Let me add a some more usecases, some of which I've been dealing with in > project I maintain. > > Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma > Mobile applications source code > > Use case 4 : Tom is a student in Germany and is interested in > contributing to wikitolearn, and he asks where can I find code of the > wikitolearn? > > Suggestion offered by sysadmin team does not cater to one single > use-case, but offers a way to provide a solution to all 4 usecases. For > Plasma Mobile team or Wikitolearn team it would be much easier to refer > contributors to the https://invent.kde.org/plasma-mobile or > https://invent.kde.org/wikitolearn then tell them to go to > https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma > Mobile. > >> On the other hand, I think the discussion about spotting open merge requests >> (in a derived thread from this one) should be answered, being by relevant >> tags, subg
Re: Input from OS X developers wanted
Hi Kevin, Luca and Alex, On 14/09/2015, at 1:56 AM, Kevin Funk wrote: > On Sunday, September 13, 2015 12:28:30 PM Ian Wadham wrote: >> For most of last year and some of this year, a few of us tried hard to make >> KDE 4 apps run better on OS X, but we were crying out for help from KDE >> developers all the time, particularly with regard to the >> kdeinit/klauncher/kded/kio complex which underlies so much of the software >> from the KDE Community and which functions badly, if at all, in an OS X >> environment. > > Right, kdeinit/klauncher/kded/kio is an issue when porting apps, but it got > *a > lot* better in KF5 already (inter-dependencies between those modules have > been > relaxed, KIO got cleaned up a lot). So I heard. That's why I was trying to build KF5, from source code (in a kdesrc-build environment). I wanted to insert some log messages and figure out what invokes what and when and why, in that complex, and what the end effect is. It appears that the Apple branches in it have never been tested and some of them did/do not work. Ditto for KCrash and Dr Konqi, which is why there were no crash reports to Bugzilla from Apple, but I have (partially) fixed them now and someone else forward-ported them to KF5. Unfortunately, the internal doco for kdeinit/klauncher/kded/kio is slender to non-existent and the density of comments in the code is very low, otherwise I could have just read the source code. I tried that and got lost, even though I had quite a deal of experience in developing and supporting operating systems and real-time before I retired in 1997. > In fact, if you did follow the KF5 mailing list a bit; on Windows it's now > possible to just run KDevelop *without* ever invoking kdeinit/klauncher/kded. > Just a few patches needed in KF5 libraries -- all upstreamed already. This > also helped the OSX world. Well no, I don't follow the Frameworks/KF5 mailing list. Why would I? And how would I find the time? I am already on 3 Apple lists and 4 KDE ones, and have been, at one time or another, on at least 4 more KDE lists. This is a prevalent problem in the KDE world, IMHO. Many things you need to know, as a developer, are on yet another mailing list, IRC area or blog. Whatever happenend to Techbase? >> A few months ago I spent WEEKS trying to KF5 and Qt 5 to build on OS X and >> finally gave up. > > What's the problem with that? There were *dozens* of problems, beginning with building Qt 5... > Did you ask for help? Of course I asked for help --- and got it, both from Qt support and from one or two friendly KDE developers who happened to have Apple hardware or virtual setups, but there was something about my setup that defeated everyone. Also the time the endless builds were taking was exacting a toll, both on myself and my wife. We are both in our 70s. > Clearly, and people out > there are using it (https://github.com/haraldF/homebrew-kf5) And here is the crux of the situation vis a vis KDE Community and Apple. Harald is an ex-KDE developer with more than a passing knowledge of KDE Core development, which no doubt you also have, Kevin. I think it is true to say that almost every major platform and distro has one or more ex- or active KDE developers who are familiar with KDE core development. The KDE Community depends on this serendipity to get its software field-tested and distributed properly. Macports on Apple OS X has no such person, not even part-time. All we have is a KDE Games programmer (me) and some guys who are self-taught in KDE and Qt (as am I, actually). I think if we had (or had ever had) a KDE expert, even for a few hours a week, we would be getting a lot further ahead than we are now. Any volunteers? Harald and Homebrew might as well be on the Moon. You know how it is with small groups in the FOSS world… :-) … they just do not talk to each other. Also Homebrew and Macports are AFIAW *not* co-installable on Apple OS X. They are like two different distros. >> I think work on Qt5/KF5 on OS X is currently blocked by the >> QStandardPaths problem and has been for a while. > > Then, please join efforts and help in resolving *this* issue. We in the "KDE > on Windows" world also just worked-around the issue by patching Qt. I think we also will have to patch Qt. I have been a witness and contributor to discussion of the QStandardPaths issue on Apple OS X from the very first. Luca please note… :-) > The QStandardPaths issue is not the end of the world, either, though… No, on Apple OS X it just needs a few guys with complementary knowledge and skills to bite the bullet and DO something, rather than engage in endless philosophising. There is something seriously at odds between what Apple (the company) expects an app, utility or library to do and what KF5 (and KDE 4) actually do. For instance, on the iOS operating syst
Re: Moving KDots to KDE Review
Hi Minh, On 06/04/2015, at 11:30 PM, Minh Ngo wrote: Here is the patch. Checked with clang 3.5.0, qt 4.8.6, KDE Development Platform 4.14.6 Thanks very much for the patch, Minh. I tried it, but unfortunately the same errors persisted. In file included from /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.cpp:26: /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.hpp:78:10: error: explicit specialization of non-template struct 'hash' struct hashKDots::Point ^ ~~ /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.cpp:123:19: error: expected ';' after top level declarator std::size_t hashKDots::Point::operator()(const KDots::Point s) const ^ ; 2 errors generated. I have not had time to investigate further in the last two days. Maybe tomorrow. Possibly the Clang compiler is picking up the wrong stdlib from somewhere or maybe Clang does not like the mix of namespace and template features in this particular code. Can it be paraphrased and simplified in some way? It is similar to the final coding example in http://en.cppreference.com/w/cpp/utility/hash, so it ought to compile OK, but it is not exactly the same. I might try modifying point.hpp to be textually and syntactically more like the example, without changing semantics. Another possibility is for me to try MacPorts' (Open Source) Clang, rather than Apple's, but I use Apple's Clang successfully for all other code. Or I might be able to revert to MacPorts' gcc. Cheers, Ian W.
Re: Moving KDots to KDE Review
Hi MInh, On 06/04/2015, at 12:37 AM, Minh Ngo wrote: Thanks, but it should not be. You seem to have skipped https://techbase.kde.org/Policies/Application_Lifecycle#Stage_1:_The_start … :-) i.e. I do not think anybody in the KDE Games group has seen your code or, more importantly, played the game. I certainly have not yet played it. Where was KDots before? It was in the playground before for several years in the kde/games section, so possibly I haven't skip it. If anything is still missed, please clarify it explicitly :). I didn't use the mail list often, but I remember that I mentioned about my project few years ago in the kde-games mail list. My apologies, I completely missed seeing KDots in Playground and I must have missed your email somehow too. I wonder, did anybody else from KDE Games try out KDots while it was in Playground? In the past we have used Playground to develop games beyond the first draft. That way we all get a chance to try out a new game before it gets set in concrete. This is something like the usability review that should be a precursor of KDE Review in other apps. Also, other games authors get a chance to discuss the game and suggest ideas or help out in some way. I supposed before that the KDEReview stage is the time where people from let's say KDEGames can review the application and give some feedback about them. Anyway, if KDEReview is still not a right place for the project I suppose it should be easy to revert the transfer (because I just requested sysadmins several days ago) and move it back to the Playground. If there aren't anybody tried the game before please do it now if you would like :). You have done the right thing all along, except perhaps jumping up and down on the KDE Games list and getting some feedback. You might as well leave KDots in KDE Review for now, but I think it might take longer than the usual 3 weeks to get a review done. Oh for the days when we had 15-20 people working on KDE Games! I have cloned KDots, but right now I cannot compile it. One problem is that Frameworks/KF5 will not compile on my Apple OS X setup. So I am using your last KDE 4 tagged version (tag v0.5.3). But there is something that the Clang compiler does not like in the files point.hpp and point.cpp. I will ask around on kde-mac and MacPorts lists in the next few days. FWIW, the error messages are:- In file included from /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.cpp:26: /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.hpp:78:10: error: explicit specialization of non-template struct 'hash' struct hashKDots::Point ^ ~~ /kdedev/kde4m/kdesrc/kde/kdegames/kdots/point.cpp:123:19: error: expected ';' after top level declarator std::size_t hashKDots::Point::operator()(const KDots::Point s) const ^ ; 2 errors generated. Hash is defined as struct in the std lib, so I changed class to struct, but that did not help, as you can see. Cheers, Ian W.
Re: Moving KDots to KDE Review
Hello Minh, This should go to the KDE Games list, not kde-core-devel. Please reply on kde-games-devel _only_, where I am also a member. On 04/04/2015, at 4:12 AM, Minh Ngo wrote: Hi folks, I would like to move my project [1] to KDE Reviews and receive some feedback to make it become a part of the KDEGames project in prospect. According to the wiki article [2] I have to contact with sysadmins and post this message in this mail list. KDots is a prototype of the game of dots. The purpose of the Dots game is to catch your opponent's dots by placing your dots on the game board where the lines cross. Currently it has been ported to the KDE Framworks 5. It supports several game modes and I have created a small user documentation to fit requirements. If you are a responsible person for this thing, could you please give some feedback regarding to the project? Cheers, Minh [1]: http://quickgit.kde.org/?p=kdots.git [2]: https://techbase.kde.org/Policies/Application_Lifecycle#Stage_2:_Stable I am not sure where your repository is exactly (in the KDE Projects tree), but it probably needs to be in Playground for a while before KDE Review. We can talk about this further when you are on the KDE Games list. First impressions. The documentation is indeed small and way short of the standard required for a KDE Game, so the doco definitely needs work. Also, I cannot tell from it how to play this game nor which game of dots this is. I found one or two games called dots by Googling, but none resembling the game in your screenshot. We also already have a KDE Game called KSquares, sometimes known as Dots and Boxes, see http://en.wikipedia.org/wiki/Dots_and_Boxes. So please could you provide a fuller description of the game --- or a link to such a description? Looking forward to hearing more, All the best, Ian W.
Re: [KDE/Mac] Multiplatform frameworks
Hi Jeremy, On 02/03/2015, at 11:42 PM, Jeremy Whiting wrote: I read that KDEInstallDirs documentation [2], and it seems it's a bit outdated Well, it is part of the official documentation for ECM, in api.kde.org, so it *ought* to be up-to-date, but there is no date or version number AFAICS. What makes you think it is outdated? or at least not complete. Heh, heh. It could be better written and explain things more, I agree… :-) If I change just -DKDE_INSTALL_DATADIR but nothing else here. kdesrc-build is installing data (stuff that went under $prefix/share) in ~/Library/Application Support but nothing else so far. For example .desktop files for applications are currently in /usr/local/share/applications and kservice5 stuff is still in /usr/local/share/kservices5. Now after rereading that page it seems I changed the DATA_INSTALL_DIR but not the DATAROOTDIR, and since I set it to an absolute path it's installing those files correctly. I guess ultimately we would need/want to change all those paths on OS X. In my test here I've simply added -DKDE_INSTALL_DATADIR=/Users/jeremy/Library/Application Support to the cmake options in my ~/.kdesrc-buildrc If there's somewhere where default cmake arguments are set per platform maybe that would be better to use and we can figure out the best places for all of these various paths one at a time. I guess if you use -DKDE_INSTALL_FULL_DATAROOTDIR=… all the shared data directories will follow the appname directories like Bo Peep's sheep. BTW the names in square brackets in [2], such as DATA_INSTALL_DIR, are supposed to be deprecated, but I see some recently-ported KF5 apps are still using them in CMakeLists.txt. Should they be using KDE_INSTALL_DATADIR, KDE_INSTALL_KXMLGUI5DIR, etc.? Cheers, Ian W. [1] https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp [2] http://api.kde.org/ecm/kde-module/KDEInstallDirs.html
Re: [KDE/Mac] Multiplatform frameworks
Hi Jeremy, My apologies for going back to basics. Some things you said earlier made me think we are not on the same page, but I now see that we are. On 02/03/2015, at 3:15 AM, Jeremy Whiting wrote: The example code you've given does already use prefixes. I'll explain below. On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham iandw...@gmail.com wrote: /snip Note that the code could have said '(QStandardPaths::DataLocation, arenas, '. So no way for a kf5 suffix to get in there. Maybe it comes from $XDG_DATA_DIRS (?). Correct, DataLocation (newly clarified as AppDataLocation) is where the application stores it's own files, so it's Application Support/appname In this case granatier (or whatever QApplication::setApplicationName is given in main.cpp. Also, there would be several shared data folders in GenericDataLocation, alongside the DataLocation folders for the apps. See [2] for details. These would fit in quite well with standard paths on Apple OS X set to: ~/Library/Application Support/subdir, /Library/Application Support/subdir always supposing we really *want* to be good Apple citizens. They would not look at all good if they were directly under Application Support/, because they are not apps. I'm not sure what you mean here, are you referring to kf5 frameworks, kdoctools uses kf5/kdoctools/ prefix beneath this to keep it's data separated from others, Other kf5 frameworks do the same. If they didn't we would have a ton of data in $prefix/share on linux which is also discouraged. I am talking about regular apps, not Frameworks, but I am glad that Frameworks' doctools is inserting the kf5/ subdir. If I were to build Granatier in KF5/Qt5, using standard QSP paths on OS X, I would expect to find /Library/Application Support/granatier/ containing all the data specific to Granatier (arenas, etc.). But also I expect /Library/Application Support/kxmlgui5/, containing granatierui.rc (?), and /Library/Application Support/applications/ containing granatier.desktop (?). Maybe there would be other subdirs, see [2], depending on whether Granatier shares other data with other apps or libraries or whether it uses shared resources such as /Library/Application Support/icons (?) (which I assume it does). If I have understood [2] correctly (BTW there seems to be a misprint under KXMLGUI5DIR), it seems to me that kxmlgui5/, applications/ and icons/, *whatever* they contain, would be out-of-place [3] in /Library/Application Support/ because they are not apps. And even the application subdirs (granatier, etc.) run the risk of name-clashes with other software from sources other than KDE. That is why I proposed a special subdir if we go the Apple and (unaltered) QStandardPaths 5.4 way. Cheers, Ian W. [1] https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp [2] http://api.kde.org/ecm/kde-module/KDEInstallDirs.html [3] Out-of-place ... like feathers on a dog… :-)
Re: [KDE/Mac] Multiplatform frameworks
Hi René, On 01/03/2015, at 8:17 PM, René J.V. Bertin wrote: On Sunday March 01 2015 17:37:35 Ian Wadham wrote: Let me kick off by saying that I am not necessarily in favour of doing what the Romans do… ;-) Heh, I got that! :) Yeah, but I am keeping an open mind… And I do not like directory names with a space in them either, but that is just an annoying detail... I *hope* it's just a detail… I think I saw a ReviewBoard item where the path had to be encoded, so the space became %20 (or some such). Are you expecting anything worse? Modifying Q(Core)Application's constructor might not work in all cases (e.g. QSP) because there may be processes that do not use Q(Core)Application, even if they use Qt. I am thinking of klauncher5, etc. OTOH, you could just do extra patches for those processes... Yeah, I know I wrote Q(Core)Application, and later on I realised I should have referred to the QSP ctor. But it seems it doesn't have one, it's just a class with static methods, right? Which would still allow us to add an additional argument with a configurable default value where required… Yes, that is some strange puppy: a private constructor, but no implementation and no instantiation anywhere. And QSP has no data-state ATM, static or otherwise, except what is on the stack. It reminded of a bongle Stefan Majewski came up with a few years ago on libkdegames. See [1], [2] and [3] for the ReviewBoard entry and the latest code (ported to KF5). This technique gets you in the door way ahead of the crowd, even ahead of main()… :-) Oh, and I found out today that some GUI apps (maybe all) may have to reference QSP ahead of creating a QApplication, otherwise there is a risk of them losing the local data and config files they used to have in KDE 4, see: http://lists.kde.org/?l=kde-games-develm=142523428426539w=2 There are migration methods for copying the files from their KDE 4 locations to their KF5 locations, but they seem not to be working in some situations. The jury is still out on this. I've started to look at how the ApplicationAttributes (AA_*) feature works. That's just a static member value of a private QApplication subclass, which is initialised outside of a function. That would only work to define a default at Qt's compile time, and not at the client compile time like I am after. Still, one might think of a solution in which that additional argument to the QSP functions is set to use whatever the AA_QSP_FLAVOUR attribute dictates in stock Qt, and can take other values to override that attribute. That's similar to the approach Qt follows for QAction menuRoles (cf. TextHeuristicsRole). /snip Cheers, Ian W. [1] https://svn.reviewboard.kde.org/r/6810/ [2] https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/chooserastergraphicssystem.cpp [3] https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/diff/CMakeLists.txt?rev=748aa8c8f0e262b1edb7a3166a08528b620bf7bcrev_to=3c7d109436ab58550a662687c04a42e6e4aec7f0
Re: [KDE/Mac] Multiplatform frameworks
Hi René, On 28/02/2015, at 8:15 PM, René J.V. Bertin wrote: On Saturday February 28 2015 18:12:40 Ian Wadham wrote: One problem is that these are NOT exactly like ~/.local/share, /usr/local/share, ~/.local/share/APPNAME and /usr/local/share/APPNAME on Linux. ... A bundle identifier is something like org.kde.appname. Actually, on my system I find: Tara:~ls /Library/Application\ Support/ Adobe/ Macromedia/ProApps/ iLife/ Apple/ Microsoft/ Script Editor/ iLifeMediaBrowser/ CrashReporter/ Mozilla/ avbdeviced/iLifeSlideshow/ GarageBand/Oracle/iDVD/ iPhoto/ All are either names of organisations or names of apps from Apple. ... Another problem is that the /Library/Application Support directory is not really geared towards apps that share data-files with other apps. Subdirs of GenericDataDir such as doc/, kservices5/, icons/, kxmlgui5/ , mime/ and dbus-1/ would look out-of-place, since they are not apps. Also the sheer number of KDE apps would tend to crowd out names of other organisation and apps. One way to solve both problems is somehow to inject an organisation-id, such as KDE/ or org.kde/ into QStandardPaths, so that the generic data paths would become something like: I think that's about the ONLY solution. How else are applications going to find shared data? Esprit d'escalier. We could change GenericDataDir in QStandardPaths to be: ~/Library/Application Support/Qt5, /Library/Application Support/Qt5 That would work for ALL applications that use Qt5 and QSP, regardless of origin, and would be a more correct usage of Apple OS X by the Qt 5 libraries. Crowding out isn't the biggest issue, BTW IMHO, it's the risk that we end up overwriting or otherwise interfering with stuff that's not ours but happens to be in the way. I was thinking the same. I come from an environment where everything had to be uniquified: large databases with thousands of application programs. And we already have the example, in Open Source and Macports, of ECM being an ambiguous acronym… ;-) Cheers, Ian W.
Re: [KDE/Mac] Multiplatform frameworks
Hi René, Let me kick off by saying that I am not necessarily in favour of doing what the Romans do… ;-) And I do not like directory names with a space in them either, but that is just an annoying detail... I just wanted to follow up on Jeremy's experiments at the start of this thread (and subsequently) and see whether it is really feasible to go the Apple and QStandardPaths way and what the long-term consequences might be. I think it *is* feasible as long as QSP adds a subdir to */Application Support/, which I think it should do anyway if it to be a true Apple citizen… On 28/02/2015, at 8:15 PM, René J.V. Bertin wrote: On Saturday February 28 2015 18:12:40 Ian Wadham wrote: One problem is that these are NOT exactly like ~/.local/share, /usr/local/share, ~/.local/share/APPNAME and /usr/local/share/APPNAME on Linux. ... A bundle identifier is something like org.kde.appname. Actually, on my system I find: Tara:~ls /Library/Application\ Support/ Adobe/ Macromedia/ProApps/ iLife/ Apple/ Microsoft/ Script Editor/ iLifeMediaBrowser/ CrashReporter/ Mozilla/ avbdeviced/iLifeSlideshow/ GarageBand/Oracle/iDVD/ iPhoto/ All are either names of organisations or names of apps from Apple. ... Another problem is that the /Library/Application Support directory is not really geared towards apps that share data-files with other apps. Subdirs of GenericDataDir such as doc/, kservices5/, icons/, kxmlgui5/ , mime/ and dbus-1/ would look out-of-place, since they are not apps. Also the sheer number of KDE apps would tend to crowd out names of other organisation and apps. One way to solve both problems is somehow to inject an organisation-id, such as KDE/ or org.kde/ into QStandardPaths, so that the generic data paths would become something like: I think that's about the ONLY solution. How else are applications going to find shared data? Crowding out isn't the biggest issue, BTW IMHO, it's the risk that we end up overwriting or otherwise interfering with stuff that's not ours but happens to be in the way. But I do not know how or when this could be done. Clearly, we cannot hard-wire that into the QSP code, because there are other apps that use Qt but do not come from the KDE Community. It would be easy enough to put it into ECM modules when building KF5 or Frameworks software, but then how would that info be given to QSP within *every* KF5 executable, GUI or not-GUI, before the first call to QSP? Exactly: it'd put us in the same place we're now, whipping up a patch that does basically the same thing even if the exact strings (paths) are closer to the MacOS Roman thing (hehe, thanks Ian :)) Ideas welcome… :-) My idea is still that we need a patch that adds a runtime selection between Maccy and Linuxy QSPs, controlled through an AA_* flag (cf. Icons in menus) or an argument to Q(Core)Application's ctor. The initial setting of that switch would be controlled through a preprocessor macro, which we could set somewhere in the CMake scripts but that could of course be overridden if needed. Multiple levels of control each with a default, I think that gives the flexibility we need and also the compliance with Digia's requirements (App Store rules...) Example: KDE4's GUIEnabled argument to the KApplication ctor. It's not used the same way on all platforms, and it may not have the same default on all platforms either. On OS X it has a function, so I patched the build system and headers to link it to the CMake NOGUI token used when defining an executable. With my mods, setting that token causes a preprocessor macro to be set. The default value of GUIEnabled depends on that preproc. macro: when set, the GUIEnabled defaults to False, otherwise to True. The result is that applications defined with NOGUI will now be built such that they start as non-gui applications without changing a line in their code, unless they already happened to specify GUIEnabled themselves. I think that's what we want, regardless of where we decide to store stuff. But for that I really think we have to prefer function over form. Apple's guidelines are just that, guidelines. Macros generated at build-time and used in source code are fine and are actually how KStandardDirs works its magic. See [1]. Modifying Q(Core)Application's constructor might not work in all cases (e.g. QSP) because there may be processes that do not use Q(Core)Application, even if they use Qt. I am thinking of klauncher5, etc. OTOH, you could just do extra patches for those processes... Another possibility (an Apple way… ;-) ), is to use Custom Keys in .plist files [2]. On a per app basis, you can insert values in Info.plist, using an Info.plist.template file in your CMake build (as you well know, René, but I am telling others). On an all
Re: [KDE/Mac] Multiplatform frameworks
Hi Jeremy, On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote: On Sat, Feb 28, 2015 at 4:51 AM, René J.V. rjvber...@gmail.com wrote: On Saturday February 28 2015 22:00:07 Ian Wadham wrote: We could change GenericDataDir in QStandardPaths to be: ~/Library/Application Support/Qt5, /Library/Application Support/Qt5 That would work for ALL applications that use Qt5 and QSP, regardless of origin, and would be a more correct usage of Apple OS X by the Qt 5 libraries. Then data will all be under ~/Library/Application Support/Qt5/appname ? that's a bit cleaner, Errrmm, not all, unless there has been a change in KDE Community designs/policy… App data would be INSTALLED under /Library/Application Support/Qt5/appname (no ~) and would be read-only. The ~ version is used by apps when they *execute*, either for the user of the app to override one of the read-only files (e.g. appnameui.rc) or to save personal data for that app (e.g. statistics in the KPat game). but why would Qt/KDE applications need to use a namespace like that when apple's own applications don't? Ahem! Why do American web addresses not have a country code? It is a matter of first in, best dressed, as we say in Australia. Anyway, as René says, it really is best to keep Open Source files quite separate from Apple files, to avoid any possibility of cross-contamination, name duplication or even actual deletion or overwriting. That is why MacPorts uses /opt/local for utilities and libraries, rather than /usr/local. Here I see ~/Library/Application Support/kf5 for all frameworks as it is, I don't think any frameworks or applications are using GenericDataLocation directly, they all use a subfolder of it, otherwise we would see application data files in /usr/share on linux which isn't recommended either. What I see is source-code of apps that have been ported to KF5, such as, in Granatier [1]. 49 m_soundExplode = new KgSound(QStandardPaths::locate (QStandardPaths::DataLocation, sounds/explode.wav)); 102const QStringList dirs = QStandardPaths::locateAll (QStandardPaths::GenericDataLocation, granatier/arenas, QStandardPaths::LocateDirectory); This has been ported and tested on Linux and Linux CI (at least) and there it is (AFAIK) using plain, unaltered QStandardPaths. So there should be no kf5/ subfolder there, unless it comes from $XDG_DATA_DIRS. The first lines of code will find the explosion sound, either in /usr/local/share/granatier, where it has been installed, OR in ~/.local/share/granatier, if the user has their own explosion sound. The *order* of paths in QSP ensures that the latter is picked up first, if it exists. It will not be found in /usr/share, because it has not been installed there. The second bit of code finds all folders that contain Granatier arenas (board layouts containing bombs, etc.). These could be installed or provided by the user (or GHNS?). Note that the code could have said '(QStandardPaths::DataLocation, arenas, '. So no way for a kf5 suffix to get in there. Maybe it comes from $XDG_DATA_DIRS (?). Also, there would be several shared data folders in GenericDataLocation, alongside the DataLocation folders for the apps. See [2] for details. These would fit in quite well with standard paths on Apple OS X set to: ~/Library/Application Support/subdir, /Library/Application Support/subdir always supposing we really *want* to be good Apple citizens. They would not look at all good if they were directly under Application Support/, because they are not apps. Cheers, Ian W. [1] https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp [2] http://api.kde.org/ecm/kde-module/KDEInstallDirs.html
Re: [KDE/Mac] Multiplatform frameworks
Hello Ralf, On 28/02/2015, at 7:32 PM, Ralf Habacker wrote: Am 28.02.2015 um 08:12 schrieb Ian Wadham: But I do not know how or when this could be done. Clearly, we cannot hard-wire that into the QSP code, because there are other apps that use Qt but do not come from the KDE Community. It would be easy enough to put it into ECM modules when building KF5 or Frameworks software, but then how would that info be given to QSP within *every* KF5 executable, GUI or not-GUI, before the first call to QSP? Qt has a concept of overriding hard coded paths built in qt by using a file named qt.conf, see http://doc.qt.io/qt-5/qt-conf.html. It just lacks support for QStandardPaths to be usable for KF5. Thanks, Ralf, a useful suggestion and something to be kept in mind for other things we may need to patch in Qt 5 on Apple OS X. Cheers, Ian W.
Re: [KDE/Mac] Multiplatform frameworks
Hi Jeremy, On 27/02/2015, at 2:03 PM, Jeremy Whiting wrote: Yeah, obviously to share with all users installing data files into /Library/Application Support/ is better, I just didn't do that in my test since my user doesn't own that folder and I didn't want to install with sudo for a test. On Thu, Feb 26, 2015 at 7:26 PM, Aleix Pol aleix...@kde.org wrote: On Thu, Feb 26, 2015 at 10:45 AM, René J.V. rjvber...@gmail.com wrote: On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote: QStandardPaths there that worked pretty well. In discussion with the Qt developers I began to think that we maybe should be installing our data files in the places that QStandardPaths expect to find them, rather than get QStandardPaths to find files in linuxy paths. Even if that were the easy way out, I don't think it's the proper solution if not only because OS X and MS Windows are multi-user machines and are maybe more often used like that than Linux desktop installs. Installing stuff in $HOME/Library/Application Support is thus not an option (besides, there's that obnoxious space in the filename that's bound to cause issues). IIRC, the solution is using /Library instead, although my OS X knowledge is rusty. Aleix Where to begin? Firstly, when dealing with KDE apps (by which I mean applications coming from the KDE Community), there are three storage requirements for application data-files: a) Writeable, specific to the app and one user only b) Read-only, specific to the app and shareable between users (e.g. game data) c) Read-only and shareable among KDE apps and users (e.g. icons, mime types) On Apple OS X, QStandardPaths offers us two GenericDataLocations: ~/Library/Application Support, /Library/Application Support and three AppDataLocations (formerly called DataLocations): ~/Library/Application Support/APPNAME, /Library/Application Support/APPNAME, APPDIR/../Resources One problem is that these are NOT exactly like ~/.local/share, /usr/local/share, ~/.local/share/APPNAME and /usr/local/share/APPNAME on Linux. On Linux, APPNAME is the bare, unqualified name of the app (e.g. kmymoney), so we can safely append the appname to GenericDataLocation or ask QSP for DataLocation and get the same result both times. Both these practices are recommended in the porting notes for KStandardDirs and I have seen occurrences of both in a ported app. If we want to be good citizens on the Apple platform (when in Rome, etc.), here is what Apple's documentation says about how to use Application Support directories (see [1]): Use this directory to store all app data files except those associated with the user’s documents. All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company. A bundle identifier is something like org.kde.appname. Actually, on my system I find: Tara:~ls /Library/Application\ Support/ Adobe/ Macromedia/ProApps/ iLife/ Apple/ Microsoft/ Script Editor/ iLifeMediaBrowser/ CrashReporter/ Mozilla/ avbdeviced/iLifeSlideshow/ GarageBand/Oracle/iDVD/ iPhoto/ All are either names of organisations or names of apps from Apple. In ~/Library/Application Support, you see much of the same. There are some occurrences of bundle identifier and a few apps that use appname without the organization prefix, but that is naughty, except for Apple apps (iPhoto, etc.). Another problem is that the /Library/Application Support directory is not really geared towards apps that share data-files with other apps. Subdirs of GenericDataDir such as doc/, kservices5/, icons/, kxmlgui5/ , mime/ and dbus-1/ would look out-of-place, since they are not apps. Also the sheer number of KDE apps would tend to crowd out names of other organisation and apps. One way to solve both problems is somehow to inject an organisation-id, such as KDE/ or org.kde/ into QStandardPaths, so that the generic data paths would become something like: ~/Library/Application Support/KDE, /Library/Application Support/KDE Then the subdir could contain the same sub-structure as the share directory does in Linux. But I do not know how or when this could be done. Clearly, we cannot hard-wire that into the QSP code, because there are other apps that use Qt but do not come from the KDE Community. It would be easy enough to put it into ECM modules when building KF5 or Frameworks software, but then how would that info be given to QSP within *every* KF5 executable, GUI or not-GUI, before the first call to QSP? Ideas welcome… :-) Cheers, Ian W. [1] https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
Re: [Infrastructure] Identity account security
Hi Ben, On 23/02/2015, at 9:13 AM, Ben Cooksley wrote: Due to a series of unfortunate incidents it has become all to clear that unknown parties appear to be getting hold of people's Identity credentials. These are subsequently used by spammers to relay spam messages through postbox.kde.org. As a result sysadmin has now restricted authentication to people who have explicitly requested it. If you need to use postbox.kde.org to send your mail and are now being denied access, please file a sysadmin ticket and we'll add you to the list. Something weird is happening here. I have not used postbox.kde.org before, but I clicked on the above link out of curiosity. What I got was a page headed as follows: Apache2 Ubuntu Default Page It works! This is the default welcome page used to test the correct operation of the Apache2 server after installation on Ubuntu systems. It is based on the equivalent page on Debian… The weird thing is that I am using Firefox on Apple OS X 10.7.5 (Lion) and I have no Apache installed nor running... Even if you have never used this service, this serves as a timely reminder to please be careful with your Identity credentials. Even those using Linux / FreeBSD / etc can still be compromised by malicious browser addons or applications running in Wine and other emulators. Hostile applications on your mobile device are also a potential vector for this. Cheers, Ian W.
Re: Holes in KDE (fork of Changes in Git Infra thread)
On 10/01/2015, at 8:49 PM, Luca Beltrame wrote: For reference, I'm one of the KDE Community Forum adminstrators (aka the green guys). In reply to what Ian Wadham wrote: So what CAN I do? This needs major re-phrasing --- hopefully as positives rather than negatives. This comes from the upstream software we use - phpBB. I admit it's written in a not-so-friendly way, but there's little we can do at this point: mainly because we try (reasonably) to avoid modifying the upstream software too much, because that has a maintenance cost (and we already are short on skilled people and we already have some modifications to the forum software wrt upstream). I have one. Otherwise, I would have to register a new KDE Identity in order to reply, for example, to a maintainer wanted post(?) Yes, the forum requires a valid KDE Identity login. more. Another possible turnoff. Speaking for myself, I almost invariably click away from sites that want you to register, unless I am really, really interested. Unfortunately, this is unavoidable as forums as large as KDE's attract a whole load of bots, spammers, and other ad-spewers. Even with registration enabled (and checks to external services to prevent obvious spammers) we have to kill several spam posts per day. Also IMO registration is to keep a minimal barrier of entry to prevent flames and other unwanted behavior (granted, the forums behave exceptionally well - few times we've had to poke people to behave). Hopefully this clears things up. Yes, it does. I understand. I guess I could add a rider paragraph to anything I post, to reassure newbies to persevere with the way the site does things and to say that they will not sign their life away or receive endless emails and ads by getting a KDE Identity. KDE really does need new recruits --- badly. Cheers, Ian W.
Re: Holes in KDE (fork of Changes in Git Infra thread)
Hello Valorie, On 10/01/2015, at 1:56 PM, Valorie Zimmerman wrote: Comment often heard: we've lost $person / we're missing people to maintain/lead/do $project. This is understandable, and to be expected in a large, mature project such as KDE. However, in #kde and #kde-devel IRC channels we have new people almost daily trying to find some way to get involved with KDE. In an effort to bring the solution and the problem together, at Akademy we brainstormed and came up with the Mission forum [1]. What that forum needs is postings! When you as a devel are thinking about giving up maintainership, please write a Maintainer Wanted post. When fixing bugs, and seeing a valuable bit of code which needs porting, please write that up and put it on the forum. Of course we always need ideas for possible GSoC projects, and the forum is a good place to post and develop those ideas. Naturally they will eventually have to be moved to our GSoC docs, but they can be discussed and refined on the forum. Great idea! I think you should get it posted on kde-announce or somewhere where *everyone* in the KDE Community will see it, not just kde-core-devel. But ahem! Here is an immediate turnoff for newbies (or old Bs like me… :-)). https://forum.kde.org/viewforum.php?f=291 says (in part): Forum rules • You cannot post new topics in this forum • You cannot reply to topics in this forum • You cannot edit your posts in this forum • You cannot delete your posts in this forum So what CAN I do? This needs major re-phrasing --- hopefully as positives rather than negatives. Being a rebellious old B, I clicked the New Topic button anyway… :-) Then I was greeted with an invitation to log in with my KDE Identity. Luckily, I have one. Otherwise, I would have to register a new KDE Identity in order to reply, for example, to a maintainer wanted post(?) Do you want the KDE Identity service to accumulate newbies and casual enquirers? Also the registration requirement might make a newbie think he/she had to JOIN KDE (right now), when he/she is just following up an initial interest and wants to know more. Another possible turnoff. Speaking for myself, I almost invariably click away from sites that want you to register, unless I am really, really interested. Needed documentation, internationalization, translation, artwork, promo, and web work are also suitable. If you have written a help wanted blog or ML post in the past, dig it out and post it on the forum. I know devels often don't like forums, but guess who does like them? Beginners and people who are using search engines. We need these people to join our community and start helping out. That will happen when we ask in a public place, which is the forum. Maybe I sounded negative above, but I really would like to *use* a forum like this. I have five well-documented KDE Games to hand over to new maintainers and I am getting older every day… :-( All the best, Ian W. 1. https://forum.kde.org/viewforum.php?f=291
Re: Plasma 5.2 bits for kdereview
Hello Vishesh, On 10/01/2015, at 3:18 AM, Vishesh Handa wrote: On Thu, Jan 8, 2015 at 11:52 AM, Ian Wadham iandw...@gmail.com wrote: On 08/01/2015, at 9:40 PM, Vishesh Handa wrote: On Thu, Jan 8, 2015 at 7:39 AM, Ian Wadham iandw...@gmail.com wrote: - I don't think Windows has anything like Baloo or KWallet Side note: Windows has really good search capabilities. I have not seen or heard of them, and I go to a PC Users' Group regularly. Which version of Windows? Maybe 8? I know windows 7 has it. I've only mostly looked at it from the technical documentation - http://msdn.microsoft.com/en-us/library/bb787584(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/cc678933(v=vs.85).aspx Plus the NTFS file system has a the USN Journal which would allow you to know what has changed since last run. That directly caters to file indexers. Also, they have really good file change notification systems. Unlike Linux. Thank you very much for the information… :-) I will bring it up with our local PC Users Group. Cheers, Ian W.
Re: Plasma 5.2 bits for kdereview
Hello Vishesh, On Thu, Jan 8, 2015 at 11:54 AM, Kåre Särs kare.s...@iki.fi wrote: Is there something stopping Baloo from becoming a thin wrapper around the native solutions when used on those platforms? (Except man power ;) On 10/01/2015, at 7:01 AM, Vishesh Handa wrote: On Fri, Jan 9, 2015 at 5:12 PM, Vishesh Handa m...@vhanda.in wrote: Yup. Mostly man power, and that I don't care and/or have access to the other platforms. Minor correction: It's more about not having the motivation. Less about access. I actually do own a mac. We have a growing number of contributors on the KDE-Mac list kde-...@kde.org. If one of them is interested in writing a wrapper for Spotlight/Baloo, would you be able to help in a purely advisory role? We could CC you, if you do not wish to join the KDE-Mac list. Cheers, Ian W.
Re: Review Request 121930: [OS X] improvements to KSharedData
On Jan. 8, 2015, 6:12 p.m., Milian Wolff wrote: personally, I also think that if you tested and it works, and Allan has no objections, that you can go ahead and push this. but please don't comment out code, just remove it. René J.V. Bertin wrote: OK, will do. I'll give it a bit more testing, though. Mutex locking without timeouts could lead to deadlocks, and maybe that's why the feature was disabled on OS X (maybe someone even ran into such a deadlock). I just did a build-and-test using KGoldrunner, a highly-animated game that requires KSharedDataCache for SVG graphics pixmaps, rendered at various sizes. Everything worked perfectly. There was plenty of kDebug log output from KSharedDataCache, but nowhere did I see any error messages, such as those which used to occur in https://bugs.kde.org/show_bug.cgi?id=307652. I also tested with no cache-files present initially and with theme-changes and fast resizes of the main window while the demo was running. Resizes cause pixmaps of new sizes to be added to the cache, or retrieved if the required size is already there. This is quite a tough test of KSharedDataCache performance, but I do not think it would be prone to deadlocks. I tried two KGr demo windows running at once, but there is a feature in KGr that automatically pauses whichever window is not in focus. Real-time performance was very good throughout all tests. So ship away, René! - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121930/#review73521 --- On Jan. 8, 2015, 5:09 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121930/ --- (Updated Jan. 8, 2015, 5:09 p.m.) Review request for KDE Software on Mac OS X, kdelibs and Allen Winter. Repository: kdelibs Description --- This patch improves KSharedData on 2 points: - It enables `KSDC_THREAD_PROCESS_SHARED_SUPPORTED` on OS X because even if the OS cannot do timeouts on mutex locking, it does have Posix mutexes (pthreads). I don't know why this was deactivated explicitly on OS X (do you remember, Allan?), but haven't seen issues with KSDC_THREAD_PROCESS_SHARED_SUPPORTED - for now. - OS X doesn't have `posix_fallocate()`, but an emulation of this function is available in the Mozilla code (reference found on StackOverflow). The code seems to be license-compatible, so I removed the code for non-OS X platforms, and include it in `kshareddatacache_p.h`. Again, this seems to work. Diffs - kdecore/util/kshareddatacache_p.h 931de4d kdecore/util/posix_fallocate_mac.h PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121930/diff/ Testing --- On OS X 10.9.5 with kdelibs 4.14.4 and KDE PIM 4.13.3 (I use KMail as my default MUA). Thanks, René J.V. Bertin
Re: Plasma 5.2 bits for kdereview
On 08/01/2015, at 9:40 PM, Vishesh Handa wrote: On Thu, Jan 8, 2015 at 7:39 AM, Ian Wadham iandw...@gmail.com wrote: - I don't think Windows has anything like Baloo or KWallet, but Apple OS X certainly has, and has had for years. We, on the KDE-Mac list, are starting to integrate KWallet and Apple's Keychain app, but Baloo is still an unknown quantity, esp. re how hard-wired it is into KDE apps. Side note: Windows has really good search capabilities. I have not seen or heard of them, and I go to a PC Users' Group regularly. Which version of Windows? Maybe 8? They actually have many more features than Mac's spotlight, but they lack the marketing and usability of spotlight. Baloo would be a bad fit on both windows and mac. I am sad to hear that. It would be nice if apps from KDE could keep indexing terms in the same place as Spotlight. Cheers, Ian W.
Re: Changes to our Git infrastructure
Hello Jan, On 06/01/2015, at 10:48 PM, Jan Kundrát wrote: On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote: a) I do not know anything about Dr K, but I will try and find someone who does. b) Unfortunately there is nobody available any more who knows anything about Dr K, but I (or another suggested guy) will try to help. How about we take this offline via email or IRC and then you can walk us through the problem you are trying to fix, its significance and impact and how you are going about fixing it… This has a risk of splitting the discussion about a patch into multiple independent streams where people will have hard time keeping track of all the results, IMHO. No, the review would be suspended while a) or b) occurred. If b) occurs, the operative words are offline via email or IRC (or face-to-face if possible). When both parties have reached an understanding of the problem and the issues involved, the formal review can resume. The polishing (fixing nitpicks, etc.) should come *after* the stone is cut. That's a good suggestion. Thanks. Going straight to that mode is inappropriate because it conveys the message, The problem you are trying to fix is unimportant to us. Would it work for you if there was a bot which pointed out these issues to the patch author? That might be even worse, like joining a telephone queue… And what about Krazy? That way it would be obvious which part of the review is random nitpicking which is indeed not important when one considers the general direction of the patch, and in addition it would come from a machine so there won't be any bad feelings about people not appreciating the contributor's work. No amount of new technology, neither Gerritt nor the energy of cats confined in a bag, can help. There are management solutions to technical problems, but there are no technical solutions to management problems, as a colleague of mine used to say. Agreed. So the actual problem is lack of skilled maintainers who just aren't around. I agree that tooling cannot fix it -- the tooling can only help by a bit by making their job easier. If the maintainer is simply not here, then you cannot get a proper review, sure. This is an interesting discussion, and I think that there is no problem for it happening in parallel to the current talk about reshaping the git infrastructure -- but maybe in another ML thread. Thank you, Jan. I am really glad you find it interesting. but the problem is that there's completely unmaintained code where nobody feels qualified to sign off patches. Exactly. And there are simple, technology-free solutions to that problem, if anybody is interested. What are these solutions? A quote from DOT: https://dot.kde.org/2014/06/03/ian-wadham-venerable-kde-programmer Q. You've gotten the applications into good shape, and are ready to hand them off. What type of person would you like to see take over? What will they get out of working on these applications? A. I would like to see KDE set up a maintenance group and standards for maintainability of code. Programs that reach a reasonably good standard could then be maintained interchangeably by members of the group. The group could be continually changing. Nobody can stay interested in such work for long. Also the group and its stock of programs would be a good source of Junior Jobs and a place for newbies to start. It would need to have some experienced members, or ready access to such people, because some bugs are too hard for trainees to solve. This is not a new idea. It is roughly what has been happening everywhere I have worked since about 1967, when the burden of people quitting jobs and leaving behind unmaintainable, half-finished messes became intolerable for most organizations. Albert's Gardening group is a good start in this direction. Re maintainability: KDE Community code is usually not good in this regard, IMHO. As a result, I was not at all confident about my understanding of Dr Konqi and how to patch it. Luckily Bugzilla had quite good documentation, so *what* to do was fairly clear. Nevertheless, I completely missed the side-effects (re cookies) inherent in XML RPC and kio_http. Those side-effects are not even visible on my platform, only on Linux. a) There is no encouragement for the reviewer to build and TEST the patch, independently of the reviewee. My personal opinion is that people should not be approving patches unless they tested them, or unless they have sufficient reason to believe that the change is OK (such as a trivial change with an associated unit test pre-approved by a CI run). How can we motivate people to test these changes without discouraging them from doing reviews at all? Mainly by example and praise, I would say. Plus maybe a small checklist when clicking Ship It. c) Patching encourages incremental, evolutionary
Re: Changes to our Git infrastructure
On 05/01/2015, at 10:45 AM, Cornelius Schumacher wrote: On Sunday 04 January 2015 13:38:09 Jeff Mitchell wrote: I do agree that we want the barrier to entry to be as low as possible. As is often the case, I think that may conflict somewhat with what some of the more/very experienced developers might find to be most useful to them personally. Finding the best balance is a difficult task. That's true, and that's exactly the reason why we should consciously decide what our target is. It might be perfectly valid to focus on current contributors and go with something like a gerrit-based solution, but if we want to focus on new people there might be better solutions. And what about *current* developers who are NOT more or very experienced? What is the cost to them (and the KDE Community) of having to learn new tools, not to mention new libraries and porting to new libraries? Speaking for myself, I find this a huge turnoff in the KDE world and am now planning to retire from KDE as soon as I can. But then I am 76 and git is my 10th source-code control system since 1965-66, so I have little interest in mastering it. I have also found ReviewBoard utterly counter-productive this year, either because one writes an entry and nobody reviews it, or nobody understands it, or because one gets nitpicked about syntax and white space when one is really looking for helpful advice about how better to solve the problem at hand. I think I must have lost a month or two on ReviewBoard during the year, with very little helpful advice gained. So how will a new tool change that? As we used to say when I was working, New technology is the answer, but what is the question? Are the reviewers going to change their style? Nevertheless, it is refreshing to see Jeff and Ben conducting what looks like a proper requirements analysis. Good on you! I wonder also how many people have just tiptoed quietly away from the KDE Community rather than speak out about frustrations they may have been feeling. Where *did* all those people go in the last few years? And why? All the best, Ian W.
Re: Dr Konqi still misbehaving - advice needed
Hi Thomas and others, On 30/11/2014, at 10:19 AM, Thomas Lübking wrote: On Samstag, 29. November 2014 22:13:30 CEST, Ian Wadham wrote: IOW, can I offer that as a workaround until we can release your fix? Or does BKO leave stale cookies in the jar? Had a stale cookie there, might have been added by rekonq or konqueror (i usually used qupzilla lately) After kicking that (kcmshell4 cookies) the token login worked as well. DrKonqi added another cookie (Bugzilla_login_request_cookie), but that is no harm (did a third invalid bug report) Logging in with konqueror adds a second cookie (Bugzilla_login) which expires 2038 and is among the ones I deleted before. I strongly believe that this will break it again, but won't risk to spam another bug for that purpose. Sum up: --- a) Password login works with 4.4.6 (at least bugs.kde.org version) and is robust against stale cookies in kcookiejar b) getting rid of bugs.kde.org cookies fixes token security, but c) web login via kio_http (or anything making use of kcookiejar) will (most likely) re-add a bad cookie = Since telling users to delete bugs.kde.org cookies on bugreporting is no viable solution, I'd propose to either go for passwod logins or unleash the cookie monster on all cookied from the bugzilla domain. (KCookieJar has a promising eatCookie* function set, but I'd have to look up how to access the global cookie jar. I have committed a fix to kde-runtime/drkonqi on the master branch, based on Thomas' idea of going straight to passwords-only security. See attachment [1]. This should fix https://bugs.kde.org/show_bug.cgi?id=337742 I tested it as much as I could on Apple OS X and it can certainly send bug reports and attachments to bugstest.kde.org, whether there are cookies for that site in KCookieJar or not. However, all of that is true if I go back to token-based security in Dr K on Apple OS X. This may be because the various KDE background processes, such as kdeinit4, kded4 and friends, do not work as intended on Apple OS X --- or I have set them up wrong. So could someone please do before-and-after tests of patch [1] on KDE 4 and Linux, using the bugstest.kde.org database? i.e. a) No patch [1], no cookies for bugs test.kde.org --- Dr K should succeed. b) No patch [1], cookies added --- Dr K should fail. c) Patch [1] added, cookies still present --- Dr K should succeed. See attachment [2] for a patch to set up Dr K to use the test database (cloned about 3 months ago). It should contain most of the accounts and data of the live bugs.kde.org database, but will send no embarrassing emails… Thanks in advance, Ian W. [1] DrKonqiSecurity_5.patch Description: Binary data [2] DrK_bugstest.patch Description: Binary data
Re: Problems with infrastructure
Hello Jan, On 22/12/2014, at 12:01 AM, Jan Kundrát wrote: On Friday, 19 December 2014 22:16:36 CEST, Scarlett Clark wrote: Jenkins is compatible and works with Gerrit, so I don't understand why another CI is being considered. Because when I started this effort this spring, build.kde.org appeared to be on life support. I also wanted to expand the number of tools I understand, and make sure that I can evaluate various CI tools without a baggage of having to stick with a particular CI solution just because we've always done it that way. That's why I started looking at various tools, and the whole stack which the OpenStack infrastructure team have built [1] looked extremely compelling (note: they still use Jenkins). The killer feature for me was their support for testing everything, where each and every commit that is going to land in a repository is checked to make sure it doesn't introduce any regressions. Not on a per-push basis, but on a per-commit basis. This is something which has bitten me in the past where I occasionally introduced commit series which contained occasional breakage in the middle, only to be corrected in a subsequent commit. That was bad because it breaks `git bisect` when one starts looking for errors discovered in future, by unrelated testing. etc. Well, it's Christmas, the season of goodwill. So, Jan, how does all this explanation help Scarlett? Does she have a mentor? Is anybody helping her? Does anybody wonder why people keep drifting away from the KDE community, as Scarlett appears to be about to do? Read again what Scarlett has to say. I do not think her main message was to ask why another CI is being considered. She feels discarded by it all. All the best, Ian W.
Re: Problems with infrastructure
On 23/12/2014, at 8:24 PM, Ben Cooksley wrote: On Tue, Dec 23, 2014 at 10:19 PM, Ian Wadham iandw...@gmail.com wrote: Hello Jan, On 22/12/2014, at 12:01 AM, Jan Kundrát wrote: On Friday, 19 December 2014 22:16:36 CEST, Scarlett Clark wrote: Jenkins is compatible and works with Gerrit, so I don't understand why another CI is being considered. Because when I started this effort this spring, build.kde.org appeared to be on life support. I also wanted to expand the number of tools I understand, and make sure that I can evaluate various CI tools without a baggage of having to stick with a particular CI solution just because we've always done it that way. That's why I started looking at various tools, and the whole stack which the OpenStack infrastructure team have built [1] looked extremely compelling (note: they still use Jenkins). The killer feature for me was their support for testing everything, where each and every commit that is going to land in a repository is checked to make sure it doesn't introduce any regressions. Not on a per-push basis, but on a per-commit basis. This is something which has bitten me in the past where I occasionally introduced commit series which contained occasional breakage in the middle, only to be corrected in a subsequent commit. That was bad because it breaks `git bisect` when one starts looking for errors discovered in future, by unrelated testing. etc. Well, it's Christmas, the season of goodwill. So, Jan, how does all this explanation help Scarlett? Does she have a mentor? Is anybody helping her? Just to answer this point: yes, I am her mentor and are guiding her through the matters related to our Jenkins CI system. Thanks, Ben, I am glad to know she is in good hands… :-) Merry Christmas, Ian W.
Re: Dr Konqi still misbehaving - advice needed
On 01/12/2014, at 8:43 AM, Thomas Lübking wrote: On Sonntag, 30. November 2014 15:37:22 CEST, Andrea Iacovitti wrote: If i understand well the problem and the goal is to disable the use of cookies, may be it could be achieved by using kio METADATA (see doc file kdelibs/kio/DESIGN.metadata). E.g. job-addMetaData(cookies, none) should disable the use of cookies for that job. Cool, didn't know that =) Unfortunately DrKonqi currently uses sync static KIO::NetAccess::upload(), so the patch would require to move to KIO::copy() and either turn the entire thing async (and disable the UI ;-) or add a custom nested eventloop. And I think it does whatever it does from inside KXmlRpc::Client, a kdelibs4 class (frozen). I assume we've to pick the least invasive solution (make 4,4,6 use password security) - for SC4, at least. Agreed. Also a solution that can be released, given current KDE SC 4 release policies. When/if Dr K is redesigned/reorganised for KF5, David Faure has suggested using QtWebKit and QNetworkAccessManager. See the DrKonqi placement thread. Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
On 01/12/2014, at 10:26 AM, Albert Astals Cid wrote: El Dilluns, 1 de desembre de 2014, a les 09:56:40, Ian Wadham va escriure: On 01/12/2014, at 8:43 AM, Thomas Lübking wrote: On Sonntag, 30. November 2014 15:37:22 CEST, Andrea Iacovitti wrote: If i understand well the problem and the goal is to disable the use of cookies, may be it could be achieved by using kio METADATA (see doc file kdelibs/kio/DESIGN.metadata). E.g. job-addMetaData(cookies, none) should disable the use of cookies for that job. Cool, didn't know that =) Unfortunately DrKonqi currently uses sync static KIO::NetAccess::upload(), so the patch would require to move to KIO::copy() and either turn the entire thing async (and disable the UI ;-) or add a custom nested eventloop. And I think it does whatever it does from inside KXmlRpc::Client, a kdelibs4 class (frozen). I don't see any KXmlRpc in kdelibs, can you point me where is it? KXmlRpc is a namespace and KXmlRpc::Client is one of its classes. http://api.kde.org/4.x-api/kdepimlibs-apidocs/kxmlrpcclient/html/classKXmlRpc_1_1Client.html Oh, it's in kdepimlibs. My mistake… :-( Besides it being frozen doesn't mean bugs can not get fixed, you know that. I can fix master, but AFAIK there is not going to be a KDE 4.14.4, so if I fix something in a KDE 4 library, when can it be released? If I fix Dr Konqi, maybe it can be released, as an application, in KDE Applications 14.12.1, but I would like to be sure of that. Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
On 01/12/2014, at 10:56 AM, Thomas Lübking wrote: On Montag, 1. Dezember 2014 00:45:29 CEST, Nicolás Alvarez wrote: 2014-11-30 20:26 GMT-03:00 Albert Astals Cid aa...@kde.org: El Dilluns, 1 de desembre de 2014, a les 09:56:40, Ian Wadham va escriure: ... IIRC it's actually part of kdepimlibs. It is - and NetAccess is actually just used to save the report (locally) DrKonqi makes use of KXmlRpc::Client which itself creates a KXmlRpc::Query which then finally creates a transfer job. So unless there's a way to globally deactivate cookies (process, not job), KIO metadata is pretty much out of reach :-( As I feared. Anyway, Thomas, your fix of going direct to passwords-only security on Bugzilla, instead of token security, is simple, direct and effective. I like it. Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
On 01/12/2014, at 12:02 AM, Thomas Lübking wrote: On Sonntag, 30. November 2014 06:26:19 CEST, Ian Wadham wrote: Lastly, how and when is a new KDE 4 kde-runtime patch likely to be released? Wednesday, December 10, 2014: KDE Applications 14.12 Final Tag I hope, this one's correct: https://techbase.kde.org/Schedules/Applications/14.12_Release_Schedule You are supposed to use bugstest.kde.org, by changing 2 lines in drkonqi/drkonqi_globals.h… And how many bugstest.kde.org cookies are there in my cookie jar? :-P All you need to do is log in to bugstest.kde.org… :-) Ben revived it not so long ago, at my request, and it seems to contain all accounts and reports as of that time. AND, most importantly, it does not send any emails to anybody… :-) Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
Hi Thomas,
On 29/11/2014, at 11:56 PM, Thomas Lübking wrote:
On Samstag, 29. November 2014 11:35:31 CEST, Ben Cooksley wrote:
Blahblahblah ;-)
Reproducible here.
Great!!!
Bugzilla version is 4.4.6, drkonqi uses token security.
I need to log into bugs.kde.org (w/ my password ;-)
And finally hit the 410 error.
Aha, so my hunch was correct… :-) Also, as additional evidence, there was a
new crash reported on BKO yesterday which seemed to be successfully reported.
I am awaiting confirmation - https://bugs.kde.org/show_bug.cgi?id=341351#c2
A little i to dot: if you log OUT from the bugs.kde.org website, does Dr Konqi
then go back to working OK, without the 410 error?
IOW, can I offer that as a workaround until we can release your fix? Or does
BKO
leave stale cookies in the jar? They can be tricky to remove in some
browsers...
Altering the conditions to make bugzilla require password security for 4.4.6
- if (currentVersion = KDE_MAKE_VERSION(4, 5, 0)) {
+ if (currentVersion = KDE_MAKE_VERSION(4, 4, 6)) {
Thanks, Thomas. This is a neat solution and avoids having to mess with
kio_http. Nice!
fixes it for me (ie. the bug is nicely reported and probably some konsole
dev now hates me ;-)
You mean you added a spurious report to the live BKO DB? Tsk, tsk… :-)
All the best, Ian W.
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 10:20 p.m., Pino Toscano wrote: drkonqi/backtracegenerator.cpp, line 97 https://git.reviewboard.kde.org/r/121286/diff/3/?file=331098#file331098line97 Still hardcodes the debugger name; I'm not a drkonqui developer, so I cannot tell you exactly what to do -- surely, not hardcoding a particular debugger behaviour will be better anyway. a) I think codeName() would be the appropriate method (see drkonqi/debugger.h). The name() method gives you the translated name, possibly in non-Latin characters. b) FWIW there are at least two other places in this patch where lldb is used, but gdb and kdbgwin are also already used at those places... :-) So what is wrong with continuing the tradition? c) Would adding something to the file drkonqi_globals.h be of any use? d) I agree that adding a config file entry just for this case and an extra method in debugger.* to access it would be an overkill. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71100 --- On Nov. 29, 2014, 10:03 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 10:03 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10
Re: Dr Konqi still misbehaving - advice needed
Hi Thomas, Thank you very much for your help. On 30/11/2014, at 10:19 AM, Thomas Lübking wrote: On Samstag, 29. November 2014 22:13:30 CEST, Ian Wadham wrote: IOW, can I offer that as a workaround until we can release your fix? Or does BKO leave stale cookies in the jar? Had a stale cookie there, might have been added by rekonq or konqueror (i usually used qupzilla lately) After kicking that (kcmshell4 cookies) the token login worked as well. DrKonqi added another cookie (Bugzilla_login_request_cookie), but that is no harm (did a third invalid bug report) Logging in with konqueror adds a second cookie (Bugzilla_login) which expires 2038 and is among the ones I deleted before. I strongly believe that this will break it again, but won't risk to spam another bug for that purpose. Sum up: --- a) Password login works with 4.4.6 (at least bugs.kde.org version) and is robust against stale cookies in kcookiejar b) getting rid of bugs.kde.org cookies fixes token security, but c) web login via kio_http (or anything making use of kcookiejar) will (most likely) re-add a bad cookie = Since telling users to delete bugs.kde.org cookies on bugreporting is no viable solution, I'd propose to either go for passwod logins or unleash the cookie monster on all cookied from the bugzilla domain. (KCookieJar has a promising eatCookie* function set, but I'd have to look up how to access the global cookie jar. I have posted a short bulletin about this on https://bugs.kde.org/show_bug.cgi?id=337742#c54 I will polish up your fix and commit a patch to KDE 4 kde-runtime master. Do I need to do a reviewboard on that? I hope not… :-( I will also pass on the good word to Hrvoje, to amend his KF5 patch. * Lastly, how and when is a new KDE 4 kde-runtime patch likely to be released? Albert? * You mean you added a spurious report to the live BKO DB? Tsk, tsk… :-) One? Three! - By now ;-) But I promised to do no more, so please don't make me a liar =) You are supposed to use bugstest.kde.org, by changing 2 lines in drkonqi/drkonqi_globals.h… Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
Hi Ben, On 27/11/2014, at 8:05 AM, Ben Cooksley wrote: On Wed, Nov 26, 2014 at 8:40 PM, Ian Wadham iandw...@gmail.com wrote: On 26/11/2014, at 12:49 PM, Ian Wadham wrote: So far the log shows that my patch is definitely there, in the distribution, but Bugzilla still returns a 410 error, even though it has been given a token (as required for version 4.4.6 of Bugzilla software). I have a feeling that KDE software behind Dr Konqi, on Linux, is still sending cookies to bugs.kde.org via kio_http and maybe that confilcts with the later sending of the token in the XML message-data. See attached log extract. I would not have a clue how to tackle that potential issue. It does not happen (for me) on Apple OS X, because KCookieJar is not working for me and anyway my cookies are kept by Apple OS X in Safari or Firefox. Could the user who encountered this problem logout of Bugzilla in Konqueror, then try to reproduce the issue perhaps? 1. I could do that, but I think it would be quicker and more efficient if someone from the list here could set up a test on bugstest.kde.org and reproduce the problem in Linux, as you originally suggested. The bug would probably be reproducible in KF5, with Hrvoje's patch, if developers are really allergic to KDE 4… :-) Note that to change database names, you have to edit Dr K source and re-compile, so then we could easily insert further logs and patches as the investigation progresses. In my experience, getting users to do that kind of stuff is unreliable and time consuming, and anyway we surely do not want false or redundant crash reports going into the live Bugzilla database. 2. Should I attach the compressed log, which I sent you, to an email on this list? It is 11-12 Kb of bzip2. There are lots of other strange messages in it, besides the ones about cookies, also some warnings I cannot interprete. I took a look at the Bugzilla codebase and can't see anything immediately wrong which would cause a proper call to be blocked simply because cookies were present. Bang goes that hypothesis(?), I think this is going to be a hard one to crack... Cheers, Ian W.
Dr Konqi still misbehaving - advice needed
Hi guys, You may remember the recent fracas with Dr Konqi suddenly refusing to submit crash reports, because Bugzilla software (bugs.kde.org) had changed to a new version that no longer recognised cookies. The problem was fixed by me and the patch was released in KDE 4.14.2 and 4.14.3. It has also been forward-ported to KF5/Frameworks by Hrvoje Senjan. But now the problem is reappearing in the field… See: https://bugs.kde.org/show_bug.cgi?id=337742#c30 This should have been fixed, see: https://git.reviewboard.kde.org/r/120431/ and also https://git.reviewboard.kde.org/r/120876/ Germano Massullo, who wrote Comment 30 re the bug, is able to reproduce a crash in Gwenview, which then fails to get added by Dr Konqi to an existing bug report. The error message from Bugzilla is the same as it was before and Germano sends a screenshot of that, among Comments 30 to 38. The only thing I cannot get is the log/stderr output of Dr Konqi, which might tell me what the heck is going on. It occurs to me that Dr K is being started via kdeinit4 in Germano's case, rather than by forking and execing, and so its log/stderr output is going somewhere else, not to Germano's stderr. So my immediate and most urgent question is how can I get Germano to recover that log output from Dr Konqi? He is using Fedora 20, KDE 4.14.3. Cheers, Ian W. PS. I work on Apple OS X and my recollection of where Linux puts such output is hazy. I have re-visited and re-tested my fixes, using Apple OS X, and they are still working fine.
Re: Dr Konqi still misbehaving - advice needed
Hi Thomas, On 26/11/2014, at 10:19 AM, Thomas Lübking wrote: On Montag, 24. November 2014 04:08:53 CEST, Ian Wadham wrote: So my immediate and most urgent question is how can I get Germano to recover that log output from Dr Konqi? He is using Fedora 20, KDE 4.14.3. kdebugdialog --fullmode That's nice. I did not know about that option. filter for drkonqi and pass everything to a file like eg. /tmp/drkonqi.dbg Otherwise (if activated!) it should end up in either ~/.xsession-errors or the systemd journal (journalctl). Kevin Kofler wrote to the https://bugs.kde.org/show_bug.cgi?id=337742 thread and pointed out ~/.xsession-errors to us. And Germano has just now sent me a debug log from Dr Konqi. So far the log shows that my patch is definitely there, in the distribution, but Bugzilla still returns a 410 error, even though it has been given a token (as required for version 4.4.6 of Bugzilla software). I think I am going to need some serious help on this problem. Any volunteers? Also, can anyone explain why my first mail on this thread was held up in moderation? I am subscribed to the list, though I had not posted for a few weeks. AFAIK, the only thing I did wrong was to accidentally click on kde-core-devel-requ...@kde.org when I first sent the message. Maybe that branded me as a potential spammer… :-( Cheers, Ian W.
Re: Dr Konqi still misbehaving - advice needed
On 26/11/2014, at 12:49 PM, Ian Wadham wrote: So far the log shows that my patch is definitely there, in the distribution, but Bugzilla still returns a 410 error, even though it has been given a token (as required for version 4.4.6 of Bugzilla software). I have a feeling that KDE software behind Dr Konqi, on Linux, is still sending cookies to bugs.kde.org via kio_http and maybe that confilcts with the later sending of the token in the XML message-data. See attached log extract. I would not have a clue how to tackle that potential issue. It does not happen (for me) on Apple OS X, because KCookieJar is not working for me and anyway my cookies are kept by Apple OS X in Safari or Firefox. Cheers, Ian W. LogExtract Description: Binary data
Re: Review Request 120931: [OS X] improvements to KWindowSystem
On Nov. 15, 2014, 2:43 p.m., Thomas Lübking wrote: kdeui/windowmanagement/kwindowsystem_mac.cpp, line 556 https://git.reviewboard.kde.org/r/120931/diff/2/?file=328516#file328516line556 Does this *really* cut it on OSX? The function is not supposed to be an extra superfluous wrapper around QWidget, but typically used to control windows IN ANOTHER PROCESS. This raises the question whether that's possible on OSX at all. If not, testing for an in-process window (search toplevels only?) is ok, but the failure should cause a big fat warning to the developer that this code isn't portable. René J.V. Bertin wrote: It works for in-process windows, obviously, but no it won't work for windows from another process. I highly doubt that one could meddle with those, and as I must have written in the comments somewhere, you cannot convert the WId to a pointer to an actual window object if it's not owned by ourselves. What exactly are you proposing concerning that big fat warning? Do you know of code that uses this kind of functionality cross-process, apart from kwin and maybe a couple of goodies that aren't relevent outside of a Plasma workspace? Thomas Lübking wrote: Well, how does the OSX docker etc. raise/activate a window? Does this imply that activating won't work either for other PID windows? (The comments actually seem to suggest so) In case: why mess with the cocoa API itfp? You could just as well wrap around Qt (w/ a //TODO or similar) What exactly are you proposing concerning that big fat warning? qWarning(BlahFooBar does not work on OSX, please fix your stuff); if (m_DebugClient) abort(); m_DebugClient could be set in a header inline, depending on whether QT_DEBUG is defined (or QT_NO_DEBUG is not defined) René J.V. Bertin wrote: The OS X Dock is a case apart. It's system software, and probably interacts with the window manager. But I should rephrase, maybe: it won't work means there's no documented way to achieve raising and the like across process boundaries. As long as you don't want to or cannot use AppleScript, and in this case we cannot because we cannot use the WId. I do think that the Cocoa API gives a bit more functionality than wrapping Qt calls would, but I can have another look at that. Thomas Lübking wrote: Are you or another OS_X hacker maybe in touch with more regular Cocoa API devs (forum, mailing list personal contact)? I find it hard to believe that there's no access to windows on Cocoa (but on apple script) - wouldn't eg growl allow you to activate the sender window? René J.V. Bertin wrote: Growl is a notification framework, and indeed it doesn't seem it can do anything else but sending messages and displaying them. But I've spoken a little bit too soon. There *is* actually a potential way to tell another application to raise a specific window. In ObjC, invoking a class instance's member function is called sending a message to that instance ... and those messages *can* be used for IPC. See http://stackoverflow.com/questions/7448068/in-cocoa-or-generally-in-objective-c-is-there-a-way-to-send-a-message-to-objec . It's a feature I've never used so I tend to forget about it, and the question remains if we can actually use this without a substantial rewrite. And the big question remains: how to glean the required information from a WId. The documentation suggests that a WId is actually an `NSWindow*` on OS X, but from what I've seen this is no (no longer) correct. René J.V. Bertin wrote: I've had a look at using distributed objects in ObjC. That could be the solution we're looking for, given certain conditions: - WId values must be unique across processes during a session and not potentially identical in multiple processes at the same time like they could be if they are pointers (like the documentation suggests). - Because the KWindowSystem API only provides a WId to work on, we can only check the system for published distributed objects registered under, for instance, the hex. representation of that WId (which is why they must be unique) - As a consequence, each time a window is opened we must create a dedicated NSConnection object registered with the WId's representation, so KDE's windowing layer must be adapted to do that. I don't know yet whether this is actually possible, nor how large an overhead this would introduce. A more elegant (?) solution would create a single NSConnection object for some kind of application interface that can respond to queries like [give me the NSWindow* for this WId] and register that through kded. And of course kded would need to have a reverse interface to a dictionary mapping WIds to registered applications because of point 2 above. Sounds like a
Re: Review Request 120931: [OS X] improvements to KWindowSystem
a fun little project to get right, but somehow I doubt it stands much chance to be accepted for KDE4. And my main question remains: just how many applications try to do things with windows that are not their own? Martin Gräßlin wrote: And my main question remains: just how many applications try to do things with windows that are not their own? That is the main purpose of KWindowSystem. For doing things with your own window one wouldn't need KWindowSystem, but could just QWidget/QWindow. Ian Wadham wrote: @René: Do the results of http://lxr.kde.org/ident?_i=KWindowSystem_remember=1 mean anything to you? René J.V. Bertin wrote: Hi Ian, Interesting, I wasn't aware of that site. Yes, the result mean something to me - you have probably heard of digiKam too for instance. What this doesn't answer without going over all those hits is to what extent the KWindowSystem calls are actually used to control windows from other applications. I'm pretty sure digiKam doesn't, for instance. I think it's relatively safe to say that we'd have noticed where window level control was missing - we sure did for DrKonqi and KWalletd ... Thomas Lübking wrote: Looking across some files: largely virtual desktop assignment, setting window types not (been) supported by Qt, forcing to be the active window, obtain KWindowInfo on oneself. Amarok at least once checks whether it is the active window (winId() != KWindowSystem::activeWindow()) Indeed there's a lot of abuse here, where kwindowsystem is invoked w/o any need. @Martin, do you think it would make sense to add an (preproc controlled) mechanism where one does export AM_I_ABUSING_KWINDOWSYSTEM=1 what would lead to an abort if one operates on a local window and to control sth. that QWindow just provides as well? Could be a macro: WARN_ON_ABUSE(Use QWindow::requestActivate() or QWidget::activateWindow() instead) I see too that KMessageBox and KFileDialog have *WId variants of their main methods --- with warnings to use them only when necessary. FWIW KMessageBox implements its normal methods (based on parent-widgets) by finding the parent's WId and then calling the *WId variant to avoid code duplication (see line 444 of kmessagebox.cpp). Also there is a strong warning in http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKWindowSystem.html#a7a04fd62d97ed3104e02bfa3ffa19ad5, Detailed Description section, about using this class on OS X. Otherwise I am baffled by all this low-level access to the window system. Even KWordQuiz in KDE Edu has an instance of it. Maybe René should just ban applications doing things with windows that are not their own on OS X and see if anything breaks... - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120931/#review70399 --- On Nov. 14, 2014, 11:04 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120931/ --- (Updated Nov. 14, 2014, 11:04 p.m.) Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- This is an attempt to improve the Mac-specific implementation of the `KWindowSystem` class. For convenience and future-proofness (and also because I like the language) I converted `kwindowsystem_mac.cpp` to ObjC++, i.e. `kwindowsystem_mac.mm`, and added the AppKit framework in the CMakeFile. Much of the code in this file is hardly better than gentle hacking, but that probably concerns the functions that are of least interest on a platform where KDE doesn't do session management. I should probably update the not yet implemented debug statements (to unsupported), and I might have another look at kwindowinfo_mac.cpp too. Diffs - kdeui/CMakeLists.txt 1454790 kdeui/tests/kwindowtest.cpp b4012d7 kdeui/windowmanagement/kwindowsystem_mac.cpp 4200237 kdeui/windowmanagement/kwindowsystem_mac_p.h PRE-CREATION kdeui/windowmanagement/kwindowsystem_macobjc.mm PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120931/diff/ Testing --- On OS X 10.6.8, mostly with the updated kwindowtest utility (which calls KWindowSystem functions when clicking the Open button in its toolbar). Also tested on Mac OS X 10.9.4 rebuilding kdelibs from scratch. Thanks, René J.V. Bertin
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
On Oct. 28, 2014, 11:05 p.m., Hrvoje Senjan wrote: forward port, for interested ones - https://git.reviewboard.kde.org/r/120876/ Thank you, Hrvoje, you are a gentleman and a scholar... and I am happy to have been able to help... :-) - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review69367 --- On Oct. 9, 2014, 11:30 p.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 9, 2014, 11:30 p.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
Re: Review Request 120376: drKonqi Fix Bug 337742 - Unable to send report: error code 410 from Bugzilla
On Sept. 26, 2014, 11:54 a.m., Ian Wadham wrote: Hi Frédéric, As announced on KDE Core devel, in http://lists.kde.org/?l=kde-core-develm=141016488132293w=2 about 3 weeks ago, I also am working on Dr Konqi. I am about to publish a general patch, which is aimed at the present problem posed by the change to tokens in Bugzilla https://bugs.kde.org/show_bug.cgi?id=337742, but also intends to avoid such problems in future and to be forward-portable to KF5. My approach is to check the version number of the Bugzilla software and to switch to whichever security method is appropriate for that version: cookies, tokens or passwords-only. Of course, my patch will implement tokens for the time being, but the idea is to switch automatically to passwords-only when the time comes, without any new release of KDE software being necessary. See http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN in the documentation for Bugzilla 4.5.5 (the next version), as opposed to 4.4.5 (the current version). Bugzilla 4.5.5 allows tokens, but I believe they will be discontinued at some stage, though I cannot put my finger on where I have seen that discussion. This should avoid users having to experience further bugs in Dr Konqi's connection to bugs.kde.org. My patch is also intended to be extendable, so that Dr Konqi can be updated and re-released, ahead of time, if any further feature change is announced by Bugzilla and could adversely affect Dr Konqi. Frédéric Sheedy wrote: Great, good news! My patch was only a quick fix to what you are doing. Ian Wadham wrote: I did not mean that you should drop what you are doing and discard this review and patch completely... :-) Instead, we should work together and each be aware of what the other is doing. Please revive your patch and this review. From what I can tell, the patch (after review and shipping) will be good immediately and at least until the version after Bugzilla 4.5.x. Also, your patch has some improvements to the testing, which is important. And I think we need to get a fix into the closing versions of KDE 4 ASAP (next deadline Thursday, 9 October). My fixes will be more long-term and I am running short of days to work on them, due to other commitments, and anyway they may take a while to review... So please revive your review and patch, Frédéric. One immediate comment: I found that I could retrieve the token by using the tag token, but I could not use token in the args map. I had to use Bugzilla_token. I have no idea why that is. I am using an Apple OS X platform, but that should not make a difference to a web dialog. Ian Wadham wrote: Frédéric, please have a look at review https://git.reviewboard.kde.org/r/120431/ particularly the comments of the last 24 hours. Somebody is going to have to commit a patch for Dr Konqi before Albert Astals Cid starts tagging KDE 4.14.2 on Thursday night. It will be either your patch, my patch or a simplified version of my patch. If the consensus is to use your patch in KDE 4.14.2 for now, I would like to give it a test on Thursday (Australian time, UTC + 11 hours). I am otherwise engaged today (Wednesday). All being well, I could commit your patch, but do you have commit rights yourself? Frédéric Sheedy wrote: Hi Ian, I do have an account to commit the patch. Let me know of the consensus! Ian Wadham wrote: As you may have seen on https://git.reviewboard.kde.org/r/120431/ the consensus was in favour of a simplified patch, which I edited, tested and later committed on Thursday. It is regrettable that neither of our patches received a review from a KDE core developer who is familiar with the Dr Konqi code. Had that happened, things could have proceeded in a more orderly fashion and I am sure that your patch could have been shipped immediately, to fix bug 337742, and mine could have been refined and shipped within the KDE 4.14.3 or 14.12 timeframe. Frédéric, I think it is important that your fixes for the Dr Konqi test processes should go into KDE 4.14.3 or 14.12 and also into KF5. Thank you very much for your help. Frédéric Sheedy wrote: Hi Ian, thanks for the answer! As my fixes for Dr Konqui are not for the end users, should I commit it without a review? If nobody objects, I would say yes, but I am no authority. However, it seems rather hard to get a review of changes to Dr Konqi and we are just talking about some small changes to file drkonqi/tests/bugzillalibtest/bugzillalibtest.cpp. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120376/#review67481 --- On Oct
Re: Review Request 120376: drKonqi Fix Bug 337742 - Unable to send report: error code 410 from Bugzilla
On Sept. 26, 2014, 11:54 a.m., Ian Wadham wrote: Hi Frédéric, As announced on KDE Core devel, in http://lists.kde.org/?l=kde-core-develm=141016488132293w=2 about 3 weeks ago, I also am working on Dr Konqi. I am about to publish a general patch, which is aimed at the present problem posed by the change to tokens in Bugzilla https://bugs.kde.org/show_bug.cgi?id=337742, but also intends to avoid such problems in future and to be forward-portable to KF5. My approach is to check the version number of the Bugzilla software and to switch to whichever security method is appropriate for that version: cookies, tokens or passwords-only. Of course, my patch will implement tokens for the time being, but the idea is to switch automatically to passwords-only when the time comes, without any new release of KDE software being necessary. See http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN in the documentation for Bugzilla 4.5.5 (the next version), as opposed to 4.4.5 (the current version). Bugzilla 4.5.5 allows tokens, but I believe they will be discontinued at some stage, though I cannot put my finger on where I have seen that discussion. This should avoid users having to experience further bugs in Dr Konqi's connection to bugs.kde.org. My patch is also intended to be extendable, so that Dr Konqi can be updated and re-released, ahead of time, if any further feature change is announced by Bugzilla and could adversely affect Dr Konqi. Frédéric Sheedy wrote: Great, good news! My patch was only a quick fix to what you are doing. Ian Wadham wrote: I did not mean that you should drop what you are doing and discard this review and patch completely... :-) Instead, we should work together and each be aware of what the other is doing. Please revive your patch and this review. From what I can tell, the patch (after review and shipping) will be good immediately and at least until the version after Bugzilla 4.5.x. Also, your patch has some improvements to the testing, which is important. And I think we need to get a fix into the closing versions of KDE 4 ASAP (next deadline Thursday, 9 October). My fixes will be more long-term and I am running short of days to work on them, due to other commitments, and anyway they may take a while to review... So please revive your review and patch, Frédéric. One immediate comment: I found that I could retrieve the token by using the tag token, but I could not use token in the args map. I had to use Bugzilla_token. I have no idea why that is. I am using an Apple OS X platform, but that should not make a difference to a web dialog. Ian Wadham wrote: Frédéric, please have a look at review https://git.reviewboard.kde.org/r/120431/ particularly the comments of the last 24 hours. Somebody is going to have to commit a patch for Dr Konqi before Albert Astals Cid starts tagging KDE 4.14.2 on Thursday night. It will be either your patch, my patch or a simplified version of my patch. If the consensus is to use your patch in KDE 4.14.2 for now, I would like to give it a test on Thursday (Australian time, UTC + 11 hours). I am otherwise engaged today (Wednesday). All being well, I could commit your patch, but do you have commit rights yourself? Frédéric Sheedy wrote: Hi Ian, I do have an account to commit the patch. Let me know of the consensus! Ian Wadham wrote: As you may have seen on https://git.reviewboard.kde.org/r/120431/ the consensus was in favour of a simplified patch, which I edited, tested and later committed on Thursday. It is regrettable that neither of our patches received a review from a KDE core developer who is familiar with the Dr Konqi code. Had that happened, things could have proceeded in a more orderly fashion and I am sure that your patch could have been shipped immediately, to fix bug 337742, and mine could have been refined and shipped within the KDE 4.14.3 or 14.12 timeframe. Frédéric, I think it is important that your fixes for the Dr Konqi test processes should go into KDE 4.14.3 or 14.12 and also into KF5. Thank you very much for your help. Frédéric Sheedy wrote: Hi Ian, thanks for the answer! As my fixes for Dr Konqui are not for the end users, should I commit it without a review? Ian Wadham wrote: If nobody objects, I would say yes, but I am no authority. However, it seems rather hard to get a review of changes to Dr Konqi and we are just talking about some small changes to file drkonqi/tests/bugzillalibtest/bugzillalibtest.cpp. Albert Astals Cid wrote: Are we speaking of commiting just the test changes? Or also the other changes? I understand the other changes are no longer needed? @Albert: Yes. No. Yes. As far as I am concerned, just
Re: Review Request 120376: drKonqi Fix Bug 337742 - Unable to send report: error code 410 from Bugzilla
On Sept. 26, 2014, 11:54 a.m., Ian Wadham wrote: Hi Frédéric, As announced on KDE Core devel, in http://lists.kde.org/?l=kde-core-develm=141016488132293w=2 about 3 weeks ago, I also am working on Dr Konqi. I am about to publish a general patch, which is aimed at the present problem posed by the change to tokens in Bugzilla https://bugs.kde.org/show_bug.cgi?id=337742, but also intends to avoid such problems in future and to be forward-portable to KF5. My approach is to check the version number of the Bugzilla software and to switch to whichever security method is appropriate for that version: cookies, tokens or passwords-only. Of course, my patch will implement tokens for the time being, but the idea is to switch automatically to passwords-only when the time comes, without any new release of KDE software being necessary. See http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN in the documentation for Bugzilla 4.5.5 (the next version), as opposed to 4.4.5 (the current version). Bugzilla 4.5.5 allows tokens, but I believe they will be discontinued at some stage, though I cannot put my finger on where I have seen that discussion. This should avoid users having to experience further bugs in Dr Konqi's connection to bugs.kde.org. My patch is also intended to be extendable, so that Dr Konqi can be updated and re-released, ahead of time, if any further feature change is announced by Bugzilla and could adversely affect Dr Konqi. Frédéric Sheedy wrote: Great, good news! My patch was only a quick fix to what you are doing. Ian Wadham wrote: I did not mean that you should drop what you are doing and discard this review and patch completely... :-) Instead, we should work together and each be aware of what the other is doing. Please revive your patch and this review. From what I can tell, the patch (after review and shipping) will be good immediately and at least until the version after Bugzilla 4.5.x. Also, your patch has some improvements to the testing, which is important. And I think we need to get a fix into the closing versions of KDE 4 ASAP (next deadline Thursday, 9 October). My fixes will be more long-term and I am running short of days to work on them, due to other commitments, and anyway they may take a while to review... So please revive your review and patch, Frédéric. One immediate comment: I found that I could retrieve the token by using the tag token, but I could not use token in the args map. I had to use Bugzilla_token. I have no idea why that is. I am using an Apple OS X platform, but that should not make a difference to a web dialog. Ian Wadham wrote: Frédéric, please have a look at review https://git.reviewboard.kde.org/r/120431/ particularly the comments of the last 24 hours. Somebody is going to have to commit a patch for Dr Konqi before Albert Astals Cid starts tagging KDE 4.14.2 on Thursday night. It will be either your patch, my patch or a simplified version of my patch. If the consensus is to use your patch in KDE 4.14.2 for now, I would like to give it a test on Thursday (Australian time, UTC + 11 hours). I am otherwise engaged today (Wednesday). All being well, I could commit your patch, but do you have commit rights yourself? Frédéric Sheedy wrote: Hi Ian, I do have an account to commit the patch. Let me know of the consensus! As you may have seen on https://git.reviewboard.kde.org/r/120431/ the consensus was in favour of a simplified patch, which I edited, tested and later committed on Thursday. It is regrettable that neither of our patches received a review from a KDE core developer who is familiar with the Dr Konqi code. Had that happened, things could have proceeded in a more orderly fashion and I am sure that your patch could have been shipped immediately, to fix bug 337742, and mine could have been refined and shipped within the KDE 4.14.3 or 14.12 timeframe. Frédéric, I think it is important that your fixes for the Dr Konqi test processes should go into KDE 4.14.3 or 14.12 and also into KF5. Thank you very much for your help. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120376/#review67481 --- On Oct. 8, 2014, 1:49 a.m., Frédéric Sheedy wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120376/ --- (Updated Oct. 8, 2014, 1:49 a.m.) Review request for KDE Runtime and Ian Wadham. Bugs: 337742 http://bugs.kde.org/show_bug.cgi?id=337742 Repository: kde-runtime
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/#review68183 --- A simplified patch for Dr Konqi went in for review about 20 hours ago. There are now about 4 hours till the KDE 4.14.2 deadline and there has been no feedback re the new patch, but it does follow previous reviewers' suggestions. So I propose to commit this code and thus fix https://bugs.kde.org/show_bug.cgi?id=337742 and also protect Dr Konqi from token-based security being discontinued in the future in Bugzilla software. - Ian Wadham On Oct. 9, 2014, 12:06 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 9, 2014, 12:06 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
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote: My 2¢ Bugzilla will require an update anyway and that means at some point it'll be (then silently) broken in KDE SC4 again and somebody has to step up and fix it with another patch. In the meantime we've diverging codebases for KDE 4 5 - meh. I agree with Albert that this patch looks a bit scaringly complex (at least compared to Frédéric's patch), but believe that the complexity can be vastly reduced and like a forward compatible and 4+5 common patch better. Albert Astals Cid wrote: You have a point here, if it's possible that Frédéric's patch gets broken in the timeframe we still have users around using kde-runtime4 then that would be a good reason to use this patch. I'd appreciate an assesment on how much more future-proof this patch is versus Frédéric's one. Thomas Lübking wrote: Afaiu it will break when the bugzilla server upgrades to 5.0 (the token security model will be dropped) but I could not find a schedule for future bugzilla releases (nor know about bugs.kde.org update policy) - Ben? If users around using kde-runtime4 is the critical condition, this seems a likely threat, though (given eg. RHEL lifetimes - RHEL7 extended support ends 2027 ;-) Ben Cooksley wrote: bugs.kde.org is updated when it becomes necessary (security issues) or when someone gets around to deploying the latest release. There isn't really a schedule as such. Based on the above comment, i'd suggest making Dr Konqi as capable as possible - although do remember that we probably don't want to receive bug reports from extremely old versions of our software, even if RHEL is supporting it. Ian Wadham wrote: @Albert: I had to cherry-pick Revision 681446e1 from master into KDE/4.14 today. This was committed to master over 2 weeks ago, but I did not realise then that it had to go into KDE/4.14 too. It fixes a bug in the backtrace formatting on all platforms, makes sure the Dr Konqi window is on top of the crashed app's window on all platforms and has a workaround for a crash caused by KCookieJar not being found on Apple OS X. The third item has to go into the repository first, because the patch for this present review (which avoids using cookies) affects the same area of code. Sorry for the noise. Albert Astals Cid wrote: cherry-pick Revision 681446e1 In which repo? That fix is 681446e1 in the (KDE 4) kde-runtime repo, KDE/14.4 branch, and it is 25ec1c8d in kde-runtime, master branch. I cherry-picked it from master to KDE/14.4 in my local repo, then I pushed it to origin KDE/14.4. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review68051 --- On Oct. 9, 2014, 12:06 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 9, 2014, 12:06 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
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. 9, 2014, 11:30 p.m.) Status -- This change has been marked as submitted. 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
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. 9, 2014, 12:06 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. Changes --- Simplified BugzillaManager::setFeaturesForVersion() by using the KDE_MAKE_VERSION macro. Removed the commented-out testing code. Re-tested with a range of version numbers, past, present, future, incomplete and having more tha 3 parts. Performed end-to-end tests of crash-report submission, including new bug reports, attachment to previous bugs and rejection of duplicates. This patch will be committed to KDE 4.14 and master later today, if there are no objections. 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. 7, 2014, 1:13 p.m., Thomas Lübking wrote:
drkonqi/bugzillalib.cpp, line 81
https://git.reviewboard.kde.org/r/120431/diff/4/?file=316623#file316623line81
The patch largely consists of hand-crafted version handling.
replacing this by int version = KDE_MAKE_VERSION(major, minor,
release); and simple integer metricts for comparism should considerably
lower complexity (thus make the patch easier to be accepted ;-)
Yes, I know it's crap to write a lot of code and remove it afterwards.
Ian Wadham wrote:
This is exactly the kind of advice I hope for in a review. I did look to
see, several weeks ago, if there were some version-compare methods in KDE or
Qt or on Google, but did not find any. I also considered something like
version = (major * 100 + minor * 1000 + release), but thought it would be
rather a 1960s style kludge... ;-) I have lived and worked through all the
trouble those YYMMDD strings caused (Y2K and all that). Still, I suppose the
parts of Bugzilla versions are unlikely to go past 255...
I have no objection to deleting code and replacing it with something
shorter and simpler. I guess I would still need the code to convert a QString
version (from Bugzilla and the bugs.kde.org database) to a single
KDE_MAKE_VERSION integer, or is there something else in KDE/Qt to do that?
What *does* worry me is 5-minutes-to-midnight re-programming, i.e. I
would have to make and test all changes on Thursday, just hours before Albert
starts tagging KDE 4.14.2. In my experience, that could be riskier than
committing my patch as it stands.
But either way, we at least have a month to fix any problems before KDE
4.14.3, the last release of KDE 4. Then there is always KDE 14.12 and Dr
Konqi is an app, not a library...
@Albert and Thomas: Please let me know what you would like me to commit
on Thursday: my patch as it stands, my patch simplified as Thomas suggests or
Frédéric's patch.
Albert Astals Cid wrote:
I would prefer the simplified version. If you really feel you're going to
break the code, i'll take a commitment to do the simplified version for 4.14.3
Thomas Lübking wrote:
I guess I would still need the code to convert a QString version (from
Bugzilla and the bugs.kde.org database) to a single KDE_MAKE_VERSION integer,
or is there something else in KDE/Qt to do that?
You'll have to split the received string into 3 integers (major, minor,
release) for the KDE_MAKE_VERSION macro.
I found no spec for it. Is it really more than 1.2.3?
In case: the present number splitting just collects the first 3 numbers -
you'd rather have to isolate [0-9]*.[0-9]*.[0-9]* first.
If not:
```cpp
QStringList l = string.split(QLatin1Char('1'));
if (l.count() == 3)
version = KDE_MAKE_VERSION(l.at(0).toUInt(), l.at(1).toUInt(),
l.at(2).toUInt());
else
kDebug() sth's severely fucked up here;
fi
Also added a couple of lines to pad out the Bugzilla version number if it has
3 parts and a kWarning() if it has 3 parts.
On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote:
drkonqi/bugzillalib.cpp, line 125
https://git.reviewboard.kde.org/r/120431/diff/4/?file=316623#file316623line125
I'll frankly call this over-engineered (though likely just as result of
the handcrafted version stuff):
m_security = UseCookies;
m_otherStuff = OldDefault;
if (version KDE_MAKE_VERSION(4,4,3)) {
m_security = UseTokens;
}
if (version KDE_MAKE_VERSION(4,4,4)) {
m_otherStuff = NewStuff;
}
if (version KDE_MAKE_VERSION(5,0,0)) {
m_security = UsePasswords;
}
...
This adds better connection between version requirement and impact.
Thanks, Thomas, the simplified patch uses the above approach. But, ahem, there
are three logic errors in the above... :-) Need to use = in the comparisons...
On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote:
drkonqi/bugzillalib.cpp, line 159
https://git.reviewboard.kde.org/r/120431/diff/4/?file=316623#file316623line159
this apprently either enfores a strict numeric order in the changes
array or verify your comparism algo.
It should not abort outside debug builds (and I don't see why it should
abort for changes order at all)
The logic needs to go in ascending order of versions and the same in your
KDE_MAKE_VERSIONS approach. Essentially it fast-forwards through the versions
until the right internal settings (of m_security, etc.) are reached, simulating
the changes that occur in the real Bugzilla. If you do them out of order, the
last change could be the winner...
- Ian
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120431
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote: My 2¢ Bugzilla will require an update anyway and that means at some point it'll be (then silently) broken in KDE SC4 again and somebody has to step up and fix it with another patch. In the meantime we've diverging codebases for KDE 4 5 - meh. I agree with Albert that this patch looks a bit scaringly complex (at least compared to Frédéric's patch), but believe that the complexity can be vastly reduced and like a forward compatible and 4+5 common patch better. Albert Astals Cid wrote: You have a point here, if it's possible that Frédéric's patch gets broken in the timeframe we still have users around using kde-runtime4 then that would be a good reason to use this patch. I'd appreciate an assesment on how much more future-proof this patch is versus Frédéric's one. Thomas Lübking wrote: Afaiu it will break when the bugzilla server upgrades to 5.0 (the token security model will be dropped) but I could not find a schedule for future bugzilla releases (nor know about bugs.kde.org update policy) - Ben? If users around using kde-runtime4 is the critical condition, this seems a likely threat, though (given eg. RHEL lifetimes - RHEL7 extended support ends 2027 ;-) Ben Cooksley wrote: bugs.kde.org is updated when it becomes necessary (security issues) or when someone gets around to deploying the latest release. There isn't really a schedule as such. Based on the above comment, i'd suggest making Dr Konqi as capable as possible - although do remember that we probably don't want to receive bug reports from extremely old versions of our software, even if RHEL is supporting it. @Albert: I had to cherry-pick Revision 681446e1 from master into KDE/4.14 today. This was committed to master over 2 weeks ago, but I did not realise then that it had to go into KDE/4.14 too. It fixes a bug in the backtrace formatting on all platforms, makes sure the Dr Konqi window is on top of the crashed app's window on all platforms and has a workaround for a crash caused by KCookieJar not being found on Apple OS X. The third item has to go into the repository first, because the patch for this present review (which avoids using cookies) affects the same area of code. Sorry for the noise. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review68051 --- On Oct. 9, 2014, 12:06 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/ --- (Updated Oct. 9, 2014, 12:06 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
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
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 huge 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. 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
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. 7, 2014, 6:31 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, Ben Cooksley, and Darío Andrés Rodríguez. Changes --- Hi Dario, Are you not on kde-core-devel? Are you able to review this stuff as a matter of urgency? Seems you are the one who knows most about Dr Konqi... 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
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 huge 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
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. 7, 2014, 6:49 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, Ben Cooksley, Darío Andrés Rodríguez, and Jekyll Wu. 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. 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. Changes --- Added George Kiagiadakis and Matthias Fuchs as suggested 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
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 huge 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
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote: drkonqi/bugzillalib.cpp, line 81 https://git.reviewboard.kde.org/r/120431/diff/4/?file=316623#file316623line81 The patch largely consists of hand-crafted version handling. replacing this by int version = KDE_MAKE_VERSION(major, minor, release); and simple integer metricts for comparism should considerably lower complexity (thus make the patch easier to be accepted ;-) Yes, I know it's crap to write a lot of code and remove it afterwards. This is exactly the kind of advice I hope for in a review. I did look to see, several weeks ago, if there were some version-compare methods in KDE or Qt or on Google, but did not find any. I also considered something like version = (major * 100 + minor * 1000 + release), but thought it would be rather a 1960s style kludge... ;-) I have lived and worked through all the trouble those YYMMDD strings caused (Y2K and all that). Still, I suppose the parts of Bugzilla versions are unlikely to go past 255... I have no objection to deleting code and replacing it with something shorter and simpler. I guess I would still need the code to convert a QString version (from Bugzilla and the bugs.kde.org database) to a single KDE_MAKE_VERSION integer, or is there something else in KDE/Qt to do that? What *does* worry me is 5-minutes-to-midnight re-programming, i.e. I would have to make and test all changes on Thursday, just hours before Albert starts tagging KDE 4.14.2. In my experience, that could be riskier than committing my patch as it stands. But either way, we at least have a month to fix any problems before KDE 4.14.3, the last release of KDE 4. Then there is always KDE 14.12 and Dr Konqi is an app, not a library... @Albert and Thomas: Please let me know what you would like me to commit on Thursday: my patch as it stands, my patch simplified as Thomas suggests or Frédéric's patch. On Oct. 7, 2014, 1:13 p.m., Thomas Lübking wrote: drkonqi/bugzillalib.cpp, line 131 https://git.reviewboard.kde.org/r/120431/diff/4/?file=316623#file316623line131 Afaiu the bugzilla roadmap, they become mandatory with 5.0.0, not 4.5.0? (only deprecated w/ 4.5 but this would add more time to invoke kwallet etc.) AFAICS Bugzilla doco writers sometimes use 5.0 as a shorthand for 4.5.0. See REFERENCES: in the Description section of this review, starting at api in the top Bugzilla doco webpage. Confusing, isn't it? The Bugzilla version after 4.5.x might be 4.6.x or 5.0.x. Who can tell? - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review68051 --- 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
Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla
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? 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. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120431/#review67946 --- 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
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
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. 3, 2014, 7:03 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. Changes --- The code for setFeaturesForVersion() has been re-written completely, to accommodate any type of feature change, in any number of versions, in a simpler and more rugged way. This should also take care of the issues Jan Kundrát raised. 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 Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.h, line 431
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315732#file315732line431
These are never saved on disk, right?
I don't think that this makes much sense given that the rest of the
stack will happily use regular QString/QByteArray/QIODevice for actual
network IO.
These are never saved on disk, right?
No. And if nobody else is worried about this, neither am I. We are not playing
for sheep-stations here.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.h, line 442
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315732#file315732line442
`const QString `
Fixed.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 88
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line88
It's customary to use smallCaps for these identifiers
Fixed. The new array of structs is called changes.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 107
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line107
I would suggest a QLatin1String here, but that's me
Done.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 115
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line115
10 is a default, so I'm not convinced it's worth stating it manually
Fixed.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 119
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line119
While this code is correct, I dislike the fact that `currentVersion[3]`
and `part 2` are related together.
Yes, this one is longer, but also safer:
if (part = sizeof(currentVersion)/sizeof(*currentVersion)) {
// ...
The 3 is a const int now and the BugzillaVersion triplet is a typedef. I have
used sizeof() to calculate the number of struct items in BugzillaChange
changes[].
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 154
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line154
It would be much cleaner IMHO if there was a single
map/associative_array/... mapping the versions to feature set. The proposed
way is IMHO quite fragile as the code relies on the fact that the
`security` and `Versions` share the same length, yet this is not checked
anywhere.
The changes[] array is now an array of structs, each containing a version at
which the change takes place and an enum value to label the type of change.
The labels are used later in a switch() where the actual feature codes (e.g.
m_security) get set.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, lines 164-173
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line164
switch statement to make it obvious that we're checking an enum and
want to react to each and every option?
Done.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 459
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line459
What guarantees that there's always result[0]?
Bugzilla? Or are their announcements in question? Anyway, I have added a check
that the result list has count() 0.
On Sept. 30, 2014, 9:22 a.m., Jan Kundrát wrote:
drkonqi/bugzillalib.cpp, line 461
https://git.reviewboard.kde.org/r/120431/diff/1/?file=315733#file315733line461
This leaks authentication data to an on-disk log.
Deleted. Also found another instance and fixed it. BTW, tokens are
intentionally short-lived IIUC. You get a new one on every login.
- Ian
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120431/#review67658
---
On Oct. 3, 2014, 7:03 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:03 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
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. 3, 2014, 7:52 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley. Changes --- Fix white space and a slip of the pen. 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 120376: drKonqi Fix Bug 337742 - Unable to send report: error code 410 from Bugzilla
On Sept. 26, 2014, 11:54 a.m., Ian Wadham wrote: Hi Frédéric, As announced on KDE Core devel, in http://lists.kde.org/?l=kde-core-develm=141016488132293w=2 about 3 weeks ago, I also am working on Dr Konqi. I am about to publish a general patch, which is aimed at the present problem posed by the change to tokens in Bugzilla https://bugs.kde.org/show_bug.cgi?id=337742, but also intends to avoid such problems in future and to be forward-portable to KF5. My approach is to check the version number of the Bugzilla software and to switch to whichever security method is appropriate for that version: cookies, tokens or passwords-only. Of course, my patch will implement tokens for the time being, but the idea is to switch automatically to passwords-only when the time comes, without any new release of KDE software being necessary. See http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN in the documentation for Bugzilla 4.5.5 (the next version), as opposed to 4.4.5 (the current version). Bugzilla 4.5.5 allows tokens, but I believe they will be discontinued at some stage, though I cannot put my finger on where I have seen that discussion. This should avoid users having to experience further bugs in Dr Konqi's connection to bugs.kde.org. My patch is also intended to be extendable, so that Dr Konqi can be updated and re-released, ahead of time, if any further feature change is announced by Bugzilla and could adversely affect Dr Konqi. Frédéric Sheedy wrote: Great, good news! My patch was only a quick fix to what you are doing. I did not mean that you should drop what you are doing and discard this review and patch completely... :-) Instead, we should work together and each be aware of what the other is doing. Please revive your patch and this review. From what I can tell, the patch (after review and shipping) will be good immediately and at least until the version after Bugzilla 4.5.x. Also, your patch has some improvements to the testing, which is important. And I think we need to get a fix into the closing versions of KDE 4 ASAP (next deadline Thursday, 9 October). My fixes will be more long-term and I am running short of days to work on them, due to other commitments, and anyway they may take a while to review... So please revive your review and patch, Frédéric. One immediate comment: I found that I could retrieve the token by using the tag token, but I could not use token in the args map. I had to use Bugzilla_token. I have no idea why that is. I am using an Apple OS X platform, but that should not make a difference to a web dialog. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120376/#review67481 --- On Sept. 26, 2014, 3:28 p.m., Frédéric Sheedy wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120376/ --- (Updated Sept. 26, 2014, 3:28 p.m.) Review request for KDE Runtime. Bugs: 337742 http://bugs.kde.org/show_bug.cgi?id=337742 Repository: kde-runtime Description --- Bugzilla 4.4.5 now request token to create report. Diffs - drkonqi/bugzillalib.h 570169b drkonqi/bugzillalib.cpp f74753c drkonqi/tests/bugzillalibtest/bugzillalibtest.cpp 46c95b6 Diff: https://git.reviewboard.kde.org/r/120376/diff/ Testing --- Testing was done using crashtest program in drkonqui folder on https://bugstest.kde.org Create new bug report and add attachement works now. Thanks, Frédéric Sheedy
Re: Review Request 120354: [OS X] turn kglobalaccel into an agent, removing it from Dock and application switcher
On Sept. 24, 2014, 5:10 p.m., Martin Gräßlin wrote: Please watch coding style and please also have a look at the frameworks variant. It still needs porting to MacOS *hint,hint* and that would be very, very appreciated. I recently sent a mail to frameworks-devel concerning moving the daemon into the framework. Would be great if you could have a look at it and help that we have MacOS support soon in the framework. René J.V. Bertin wrote: It being kglobalaccel? Or the change to set agentship from the running app, preferably by adding an API call somewhere so that end applications don't have to dabble in CoreFoundation code? The former I can't help you with because as you know I cannot run anything KF5 in the foreseeable future. The latter is something I could work on, but again without testing. Oh, wait, you're asking me to port to MacOS. Hmmm, I doubt Qt ever existed even for version 9 of that venerable old pile of cultural luggage O:-) (MacOS is what was used before Mac OS X came out. You're good at spotting whitespace differences, so I don't have to explain any further :P ) As to kglobalaccel: I've taken this app as a demonstration case because it's one of a handful daemons that cluttered my Dock (the others being nepomukfilewatch and nepomukstorage, not sure patches to those are of any relevance?). But I have no actual idea to what kglobalaccel does and to what extent it does that on OS X too. I haven't noticed any loss in (shortcut) functionality after quitting it... is there something I could try to see if it is required? Also, the KDE4 version is the same on OS X and on Linux, why would the KF5 version require porting ? Martin Gräßlin wrote: Also, the KDE4 version is the same on OS X and on Linux, why would the KF5 version require porting ? well the X11 version needed porting due to the switch to QPA. So I assume that other platforms need porting, too. QPA? So we all have to have green hair now?... :-) See http://qt-project.org/videos/watch/qpa-the-qt-platform-abstraction or is there some other QPA?... :-) @Martin: On a serious note, can you give us the exact link on kde-frameworks-devel archives that you are talking about? I think only Marko is a member of that list. Could your post have any connection with upcoming discussions I am about to start on kde-core-devel, re kdeinit4, klauncher, kded4, kwrapper and friends? Our priority is to get KDE background processes working properly (or at all) in KDE 4 on Apple OS X, because KF5 is a distant mirage for the KDE-Mac group and the MacPorts users (except for Marko). However, if KDE-Mac work has spinoffs for the Frameworks/KF5 effort, well and good. We are already starting to see that happen. If we could get more dialog going with KDE core developers, all of us could proceed a lot faster and we could all benefit. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/#review67376 --- On Sept. 24, 2014, 5:23 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120354/ --- (Updated Sept. 24, 2014, 5:23 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime and kdelibs. Repository: kde-runtime Description --- See https://bugs.kde.org/show_bug.cgi?id=339333 for more detailed discussion. KDE helper applications that need to be able to present widgets or otherwise talk with the GUI layer require special attention on OS X, if one doesn't want them to appear in the Dock or task switcher nor present a bare-bones menubar when made active. Applications that live in an app bundle can set LSUIElement=1 in their Info.plist to signal the window server that they're agents (and thus don't want the aforementioned visual presence). This feature is already in use (see Info.plis.template for apps like kded4 and kdeinit4, and the corresponding code in their respective CMake files). kglobalaccel is a different case as it's built as a standard *n*x app (`/opt/local/bin/kglobalaccel` in a standard MacPorts install) and thus has no Info.plist. It is however possible to set the corresponding bit via CoreFoundation, and that's what this patch does. Suggestion: a member function I'd tentatively call `appIsService` would be welcome, but one could also make this the default behaviour when starting a `GUIenabled=false` application on OS X. That's actually the main reason for submitting this RR: see if we can come to a consensus if and how to use this new knowledge. Diffs - kglobalaccel/main.cpp 4d230b8
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 24, 2014, 12:59 a.m.) Status -- This change has been marked as submitted. Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 24, 2014, 1:01 a.m.) Status -- This change has been marked as submitted. Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page. When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs - kdeui/util/kcrash.cpp 45eb46b Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software. Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 Warning: connect() failed: : No such file or directory With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating). I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. Thanks, Ian Wadham
Re: Review Request 120202: [OS X] improvements to the kwallet/OSX keychain integration
On Sept. 18, 2014, 10:28 p.m., Albert Astals Cid wrote:
kdeui/util/kwallet.h, line 545
https://git.reviewboard.kde.org/r/120202/diff/1/?file=312224#file312224line545
This is bad, slots in an ifdef are a bad idea.
Is there any reason this slot has to be in KWallet and not some other
object?
René J.V. Bertin wrote:
May I ask why slots in an #ifdef are a bad idea, worse than any other
kind of code? I can see why platform-specific class members are not very
elegant, but not why that would be different for slots.
The slot has to have access to the Wallet instance, but it should be
possible to move it into the KWalletPrivate class since I already added a
pointer to the instance to that class. Would that be better?
Albert Astals Cid wrote:
An ifdef in a public class is horrible.
As a user of the KWallet class when i should connect to it? Never? Then
don't show me to me it exists.
Thomas Lübking wrote:
moc does not handle preprocessor statements.
You'll likely get some error if the condition does not match because moc
adds the slot unconditionally, but the function isn't available.
That aside, #ifdef'ing functions in a public header (ie. exported API) is
a bad idea in general, because it causes different ABI (not that much a
problem of an architecure split) and usually confusion.
- preattyplease #ifdef the implementation instead.
```cpp
void Foo::bar()
{
#if WANT_THIS
fooBarFoo();
#endif
}
```
@Albert
tbf, there're quite some present slots tagged internal in that class
and since they're all private slots, they're not available to user code
anyway. The general approach is ok, because they don't affect the vtable.
René J.V. Bertin wrote:
Understood (and agreed). Not why moc doesn't take ifdefs into account,
but that may be a design choice, and isn't relevant here.
Albert Astals Cid wrote:
@Thomas, i think last i checked you can still to connect to private
slots, the only thing is that you can't call them directly, but the
metaobject doesn't know about private.
Thomas Lübking wrote:
Indeed (jaws wide open) - so moc doesn't even care about that attribute.
Good to know, I foresee abuse -)
René J.V. Bertin wrote:
OK, implementation question.
How do I declare a slot in a private class that doesn't have a specific
header file?
Putting `private QSLOT` above the function definition makes things
compile, but the runtime complains about a missing slot (curiously even
expecting it in KWallet::Wallet). Yes, I did update the connect call to pass
in the pointer to the parent class
Albert Astals Cid wrote:
Does the object you're adding the slot have a Q_OBJECT?
René J.V. Bertin wrote:
No, the WalletPrivate class didn't need one until now. I think I figured
something out (see the updated diff I'll be uploading). I'm not perfectly
happy with making `QOSXKeychain` inherit `QObject` and putting the slot
declaration in that class (as a virtual), but the alternative would
apparently have been to use multiple inheritance in WalletPrivate. I
generally prefer to avoid multiple inheritance, and I'm also not sure to what
extent moc would have been able to pick up the necessary bits when hidden in
class that only exists in a cpp file .
Re this issue, I just found a problem building KWalletD from KDE 4 kde-runtime
master. About a year and 2 weeks ago, Valentin Rusu, added a slot called
connectToScreenSaver() to kwalletd.h and kwalletd.cpp, with an #ifdef Q_WS_X11
conditional wrapping the code in both files. This is now failing to build on my
machine, using Clang:
In file included from
/kdedev/kde4m/kdesrc/kde/kde-runtime/kwalletd/kwalletd.cpp:1670:
/kdedev/kde4m/kdesrc/build/kde/kde-runtime/kwalletd/kwalletd.moc:267:22: error:
no member named 'connectToScreenSaver' in 'KWalletD'
case 60: _t-connectToScreenSaver(); break;
~~ ^
In file included from
/kdedev/kde4m/kdesrc/kde/kde-runtime/kwalletd/kwalletd.cpp:25:
/kdedev/kde4m/kdesrc/kde/kde-runtime/kwalletd/kwalletd.h:247:14: warning:
private
field '_useGpg' is not used [-Wunused-private-field]
bool _useGpg;
^
1 warning and 1 error generated.
Any ideas on the error? Also the warning occurs on KDE 4.14, but not KDE
4.13.
The same error arose in my KDE 4.13 build setup after I touched kwalletd.h
and kwalletd.cpp, but those files have always built OK previously. It is
probably at least 2 months since I last compiled KWalletD on my KDE 4.13, so
perhaps I now have a pickier compiler (installed by MacPorts) or maybe Automoc
and MOC are doing something different.
- Ian
---
This is an automatically generated e-mail. To reply, visit:
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On Sept. 19, 2014, 10:16 a.m., Ben Cooksley wrote: Unless anyone has any objections in the next 24 hours, I think this can go in as it makes Dr Konqi usable on another platform. Thomas Lübking wrote: +1 - Shit It ... from my side. Certainly no technical concerns remaining here - but i'm not the code owner/maintainer either ;-) Thomas Lübking wrote: ... shit it ... =) i should really read what i type. and maybe get a new keyboard =) Marko Käning wrote: Happened to me as well at some time, Thomas. :-) Weird, since letters t and p lie quite far away from each other and are even linked to seperate hands... ;-) --- Well, the problem with this RR - as well as its associated one - is that the project's maintainer should also say Ship it!, right? Well, AFAICS, there IS no maintainer (see git logs) and I am not prepared to spend time looking for one. This review has been open for nearly 2 months and nobody has stepped forward and said they are the maintainer. Also, Ben Cooksley's 24 hours were well and truly up (see above) and there were no objections to the patch, so I did the Ship It myself. :-) Anyway, I will not be committing any code until Tuesday, early hours (UTC). - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review66935 --- On Sept. 18, 2014, 10:57 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 18, 2014, 10:57 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: kinit/kinit.cpp, line 1481 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481 do you need $DISPLAY in OS X? René J.V. Bertin wrote: Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference. In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running. Ian Wadham wrote: Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow doctors the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably. This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best? I tried using lxr.kde.org to find further references, but there are thousands: mostly because display is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work. René J.V. Bertin wrote: Hmm, interesting. I should find some time to play with this in my 10.9 VM. Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart. If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value. This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY. Ian Wadham wrote: Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later. René J.V. Bertin wrote: I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.) René J.V. Bertin wrote: I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold: - When I log in, $DISPLAY is not set. This is probably because I
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: kinit/kinit.cpp, line 1481 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481 do you need $DISPLAY in OS X? René J.V. Bertin wrote: Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference. In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running. Ian Wadham wrote: Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow doctors the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably. This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best? I tried using lxr.kde.org to find further references, but there are thousands: mostly because display is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work. René J.V. Bertin wrote: Hmm, interesting. I should find some time to play with this in my 10.9 VM. Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart. If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value. This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY. Ian Wadham wrote: Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later. René J.V. Bertin wrote: I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.) René J.V. Bertin wrote: I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold: - When I log in, $DISPLAY is not set. This is probably because I
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review67098 --- Ship it! Ship It! - Ian Wadham On Sept. 18, 2014, 10:57 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 18, 2014, 10:57 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 47 https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47 this sounds fishy - at least the comment to be incorrect? i hope that OSX does not just actually abort() when you call setuid() but that indeed the tests fail and the applications exits(255)? In case of the latter, does the process itself run with suid until this point? I assume if we've to consider that drkonqi does not (require) to run suid, the test should be omitted if geteuid() (notice the e!) isn't 0. Skipping this altogether only makes sense for broken by design operating systems which fail to confirm to posix standards (windows ;-) Ian Wadham wrote: I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of setuid/setgid a security breach (it calls it setugid). It is part of new security rules that came into OS X about 4 versions ago. The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 any more, only by forking (see review 119497). So I propose to settle the issue by removing the Q_OS_MAC condition. I intend to leave in the comment, however, to remind me to do something at this point if I ever get the help I have asked for with the many problems in kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5. All the tests I did on this in July showed that the crashing app, kdeinit4 and Dr Konqi were all running as the logged-in user and no actual setting of uid or gid was needed. They would just set things to what they were before. Also none of the executable files had any special permission bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the machine somehow. FWIW the Apple OS X console log said, back in July: 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING KCrash::defaultCrashHandler (1623294600)... 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... crashRecursionCounter = 2 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler -psn_0_327760 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from wrapper. 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 drkonqi[14167:2503] The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 terminated. René J.V. Bertin wrote: Ian, do you think this could in any way be related to the fact that one must do certain permissions-related things in order the be able to use a non-Apple-provided debugger? (Which in turn might have something to do with preventing too easy reverse-engineering and other hacker business?) Ian Wadham wrote: No. Dr K works fine if you start it by forking, including the uid/gid stuff. And I am pretty sure MacPorts implements a way to provide access to debuggers of all stripes. That came up on macports-dev list a few months ago. René J.V. Bertin wrote: Yes, it (MacPorts) does. But one that involves something like a code-signing certificate, IIRC. In other words, it seems to be linked to the executable. OTOH, Dr K launches a standalone debugger, so as long as that application has the necessary permissions, all should be fine. Ian Wadham wrote: There have been
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 47 https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47 this sounds fishy - at least the comment to be incorrect? i hope that OSX does not just actually abort() when you call setuid() but that indeed the tests fail and the applications exits(255)? In case of the latter, does the process itself run with suid until this point? I assume if we've to consider that drkonqi does not (require) to run suid, the test should be omitted if geteuid() (notice the e!) isn't 0. Skipping this altogether only makes sense for broken by design operating systems which fail to confirm to posix standards (windows ;-) I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of setuid/setgid a security breach (it calls it setugid). It is part of new security rules that came into OS X about 4 versions ago. The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 any more, only by forking (see review 119497). So I propose to settle the issue by removing the Q_OS_MAC condition. I intend to leave in the comment, however, to remind me to do something at this point if I ever get the help I have asked for with the many problems in kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5. All the tests I did on this in July showed that the crashing app, kdeinit4 and Dr Konqi were all running as the logged-in user and no actual setting of uid or gid was needed. They would just set things to what they were before. Also none of the executable files had any special permission bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the machine somehow. FWIW the Apple OS X console log said, back in July: 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING KCrash::defaultCrashHandler (1623294600)... 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... crashRecursionCounter = 2 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler -psn_0_327760 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from wrapper. 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 drkonqi[14167:2503] The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 terminated. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review66817 --- On Sept. 16, 2014, 11:08 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 11:08 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 18, 2014, 10:57 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- Removed the Q_OS_MAC condition for bypassing setuid/setgid in main(). The comments remain as a reminder for when kdeinit4 or some other process can be used to start Dr Konqi, instead of just forking. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs (updated) - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner system tray
On Sept. 15, 2014, 12:19 p.m., Thomas Lübking wrote: kdeui/actions/kaction.cpp, line 149 https://git.reviewboard.kde.org/r/120149/diff/2/?file=312029#file312029line149 what if KAction *foo = new KAction(this); foo-setText(Foo); - you rather want to monitor the changed() signal? René J.V. Bertin wrote: Yes, that would probably be more elegant. I'm not exactly sure how one would monitor that signal, but it seems that it might be a bit complicated in the context of something that's bound to disappear? Thomas Lübking wrote: You'd add a private slot to KAction and connect(this, SIGNAL(changed()), SLOT(fixMenuRole())) Before altering the text in ::fixMenuRole(), don't forget to block (and later unblock) signals to not enter a recursion. Since the changed() signal is not only called for altering text (but also icons, the role and some other stuff) you also might want to keep a string member to check whether the text actually changed before updating the role. René J.V. Bertin wrote: The NULL alternative would be to modify the default KAction ctor to do `setMenuRole(NoRole)`, which is the effective default on other platforms (where `TextHeuristicRole` is unused). Ian Wadham wrote: I think this may be the best way to go with KDE 4 on OS X. Yesterday evening (Aust. time) I trawled through all the relevant source code in both kdelibs and Qt and I came up with the same idea, but decided to sleep on it. Maybe I sent it to you in my dreams... :-) Here's why I think it may be the neatest solution. 1. KDE 4 apps usually use QAction, KAction or KStandardAction, or derivative classes (e.g. KStandardGameAction?), to set up actions. 2. KStandardAction sets the correct MenuRole for all standard KDE actions, including NoRole as a default. 3. The problem lies with actions that are not standard KDE actions but have a similar wording (e.g. Configure Editor). 4. These can be picked up as false positives by the Qt-Mac heuristic and will then corrupt the Preferences entry in Apple's Application menu. 5. KStandardAction's create() first sets up data-values for the required action, then it creates the KAction object (or derived action object). 6. Finally, it sets the MenuRole to NoRole or one of the specialised roles. 7. Therefore, setting the MenuRole to NoRole in the KAction constructor would not invalidate what KStandardAction does. 8. Also, no KAction objects will then be affected by Qt's heuristic, even if they are not KStandardActions (e.g. Configure Editor is KAction?). 9. That will leave QActions in some KDE apps exposed, but I doubt if they will be a problem. If they are, they could be fixed manually. In KF5, KAction is deprecated in favour of QAction. I think the only solution there is to get into Qt5, as you and Thomas have discussed, and change the default MenuRole to be NoRole, for KDE apps, rather than the heuristic role. BTW, it occurs to me that the heuristic may be for the benefit of Qt's paying customers --- businesses and organisations who may have large in-house suites of apps written using Qt and may have a mix of hardware platforms and O/S's on people's desks. If we patched Qt5-Mac in MacPorts to change the default MenuRole, I doubt if any apps ported to Apple OS X would be adversely affected --- but you never know. I suppose it is easy enough to ask MacPorts' port command if any apps, other than KDE or Qt apps, depend on Qt-Mac. René J.V. Bertin wrote: Thanks Ian for writing this down in a more concise way. It's exactly the conclusion I've came to, except maybe for the reason why the heuristics are there. There'd be a large and influential enough customerbase who have Qt code running on Macs AND 1) insist on it showing the menus in the OS-X-dictated place and 2) can't be bothered to insert 1 or 2 `setMenuRole` calls for that to happen (guided by paid support feedback? And nothing similar would ever be required on one of the more wide-spread platforms Qt supports? Personally I'd have guessed this were the oeuvre of maybe even a single person who's in love with OS X and wants to do things right without having really thought of all the potential consequences (a bit like how I killed the icons in systray bug at first). Qt5's case is slightly more complicated because it introduces MenuRole for cut, copy, paste and select-all. That apparently is to modify the role of those standard actions (quote from the relevant commit message) when a QFileDialog is open. As long as they're not used to move menu items around it's probably OK, though. Marko is helping me look into that, and dfaure provided me with the name of the heuristics' author. Ian: what kind of app that's not a KDE or Qt app could possibly be affected by this? On Apple OS
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 47 https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47 this sounds fishy - at least the comment to be incorrect? i hope that OSX does not just actually abort() when you call setuid() but that indeed the tests fail and the applications exits(255)? In case of the latter, does the process itself run with suid until this point? I assume if we've to consider that drkonqi does not (require) to run suid, the test should be omitted if geteuid() (notice the e!) isn't 0. Skipping this altogether only makes sense for broken by design operating systems which fail to confirm to posix standards (windows ;-) Ian Wadham wrote: I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of setuid/setgid a security breach (it calls it setugid). It is part of new security rules that came into OS X about 4 versions ago. The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 any more, only by forking (see review 119497). So I propose to settle the issue by removing the Q_OS_MAC condition. I intend to leave in the comment, however, to remind me to do something at this point if I ever get the help I have asked for with the many problems in kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5. All the tests I did on this in July showed that the crashing app, kdeinit4 and Dr Konqi were all running as the logged-in user and no actual setting of uid or gid was needed. They would just set things to what they were before. Also none of the executable files had any special permission bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the machine somehow. FWIW the Apple OS X console log said, back in July: 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING KCrash::defaultCrashHandler (1623294600)... 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... crashRecursionCounter = 2 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler -psn_0_327760 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from wrapper. 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 drkonqi[14167:2503] The application with bundle ID is running setugid(), which is not allowed. 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 terminated. René J.V. Bertin wrote: Ian, do you think this could in any way be related to the fact that one must do certain permissions-related things in order the be able to use a non-Apple-provided debugger? (Which in turn might have something to do with preventing too easy reverse-engineering and other hacker business?) Ian Wadham wrote: No. Dr K works fine if you start it by forking, including the uid/gid stuff. And I am pretty sure MacPorts implements a way to provide access to debuggers of all stripes. That came up on macports-dev list a few months ago. René J.V. Bertin wrote: Yes, it (MacPorts) does. But one that involves something like a code-signing certificate, IIRC. In other words, it seems to be linked to the executable. OTOH, Dr K launches a standalone debugger, so as long as that application has the necessary permissions, all should be fine. There have been no problems with hooking up
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review66801 --- Please would someone give this a Ship It, or should I do it myself? I need to ship this patch and the accompanying 119497 patch simultaneously (they are inter-dependent and 119497 already has a Ship It). Also I need to get on with further work on Dr Konqi to bring its security-code up-to-date with bugs.kde.org and the current Bugzilla software version. All of this work will have benefits in Frameworks/KF5 as well as KDE 4. - Ian Wadham On Sept. 16, 2014, 11:08 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 11:08 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 10:49 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs (updated) - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: This part of the patch, to fix the bug in the backtrace lines highlighter, has been re-written as suggested by Thomas, by adding a dummy entry to the lines, and the ASSERT remains because we should never get past the dummy, however many '\n' characters are in the last entry in the backtrace. On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 111 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111 This can go unconditionally. Show really only shows the window. Becoming active and then raise for that is WM detail - and WMs have to deal with inadequate raise requests anyway ;-) Ian Wadham wrote: I do not understand your comments at all. I just know that the raise() is essential in this context, otherwise the end-user never sees Dr Konqi's window and never investigates or reports the crash. On Apple OS X, an app which is started properly, by clicking an icon or running an Apple OS X open command, will raise the app's window, but Dr Konqi is not being started this way. Thomas Lübking wrote: You can omit the system test. It's ok to call raise() here on any system. For safety, raise() will be used on all platforms and window managers, making sure the Dr Konqi dialog is always visible. On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 286 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286 #ifndef Ian Wadham wrote: No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. ATM they are only explanatory. But there is a place to add code if anybody can think of something appropriate (e.g. to check for cookies on the user's browser of choice in a portable way, maybe using Qt). René J.V. Bertin wrote: Probably not relevant here at all, but mentioning a place to add appropriate code for this kind of thing reminds me of the fact that browser plugins are organised in a quite different way on OS X, and it would be great if konqueror could pick them up. Just sayin', for the record :) Thomas Lübking wrote: I meant to use an #ifndef (and reverse the logic of course) because some #else branch is actually not required - unless of course you indeed want to add some apple specific code. The cookie-checking code will be bypassed on Apple OS X for now, because it can cause Dr Konqi to crash. It is intended that it will be replaced by code to handle the new token-checking policy of Bugzilla 4.4.3 and later (4.4.5 on bugs.kde.org). On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) Ian Wadham wrote: The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. Thomas Lübking wrote: Well, the claim is that aborting for no cookie support is wrong in the first place. If so, drop the code. If not (or unsure) please don't break it with an unrelated patch. Aaron J. Seigo wrote: The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog. Sorry for the typos. This form barel works at all with the android web browser :( miAnimizin Ian Wadham wrote: The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs. After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 11:08 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- Patches for reviews 119497 and 119498 are an inter-dependent pair, but on two different KDE 4 repositories. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 16, 2014, 11:14 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- Patches for reviews 119497 and 119498 are an inter-dependent pair, but on two different KDE 4 repositories. Repository: kdelibs Description --- *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page. When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs - kdeui/util/kcrash.cpp 45eb46b Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software. Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 Warning: connect() failed: : No such file or directory With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating). I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: kinit/kinit.cpp, line 1481 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481 do you need $DISPLAY in OS X? René J.V. Bertin wrote: Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference. In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running. Ian Wadham wrote: Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow doctors the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably. This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best? I tried using lxr.kde.org to find further references, but there are thousands: mostly because display is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work. René J.V. Bertin wrote: Hmm, interesting. I should find some time to play with this in my 10.9 VM. Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart. If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value. This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY. Ian Wadham wrote: Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later. René J.V. Bertin wrote: I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.) René J.V. Bertin wrote: I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold: - When I log in, $DISPLAY is not set. This is probably because I
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On Sept. 15, 2014, 7:26 p.m., Marko Käning wrote: Hi Ian, shall I test this on a Mavericks VM before you're committing this? In case I shall do it, do you have a test case for me? Greets, Marko Thanks, but please wait until I drop the other shoe, review 119498, fix Dr Konqi. The test case I use is to start Palapeli (jigsaw puzzle), open any puzzle and start dragging a piece, then, without letting go of the mouse button, hit menu item Game-Restart Puzzle. That will cause a crash every time. You need to set up and use a shortcut key for the Game-Restart Puzzle action (use Settings-Configure Shortcuts...). - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review66598 --- On Sept. 15, 2014, 1:59 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 15, 2014, 1:59 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page. When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs - kdeui/util/kcrash.cpp 45eb46b Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software. Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 Warning: connect() failed: : No such file or directory With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating). I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
On July 27, 2014, 11:32 a.m., Thomas Lübking wrote: kdeui/util/kcrash.cpp, line 316 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293441#file293441line316 is libdispatch OSX only or is it also used on FreeBSD? The question (more to Michael ;-) is whether unconditionally closing all FDs is acceptable in general (there's hell lot of Q_OS_* items, incl. Q_OS_HURD ;-) or the check should be inverted to #ifdef Q_OS_LINUX Michael Pyne wrote: Unfortunately closing all FDs is probably not acceptable *in general*, but in the context of a launching a crash handler in a crashed KDE GUI application, I don't see any reason why it would hurt, it's not as if the application itself is going to need the FD anymore as it's about to crash and has already run its emergency save function (and if the app does need it, they can either use their own crash function or use the documented KeepFD flag). Closing all FDs is a security and rlimit precaution in case Dr. Konqi gets started directly from the crashing proc instead of via kdeinit. The check should probably remain on any POSIX-alike, in my opinion, as we wouldn't want Dr. Konqi on Mac OS X accidentally having access to a crashing application FDs if launched directly either. Ian Wadham wrote: On Apple OS X it is Apple's COCOA library internals that have the problem FDs, not the app, and COCOA crashes internally if you close its FDs in the crash handler. We do not know what numbers those FDs have in any arbitrary app or run of an app, and I think there is intrinsically no way to know. We also do not know what FDs may have been created by internals of the KDE library, but they do not seem to mind being closed peremptorily. I could put a setFlags call (conditional on Q_OS_MAC) a few lines earlier in the default crash-handler, but there does not seem to be much point in that. It is quite safe to leave FDs open, because KCrash closes them all unconditionally on line 623 of kcrash.cpp (if it starts Dr K by forking), with the comment We are in the child now. Close FDs unconditionally. Presumably, by that time, the COCOA library has had a chance to terminate its internals gracefully, because this time there is no secondary crash. Presumably also, if Dr K is started via kinit and klauncher, its FDs are all its own, but kinit is a very grey area for me. Michael Pyne wrote: Yes, you're right. It seems in the only problematic case (a direct fork/exec to start drkonqi) that we already close FDs unconditionally. In that case I think don't closing the FDs from the crash handler adds any value (and I suppose, might even interfere in debugging once drkonqi can get a debugger attached), so it might be best to remove the feature from the default crash handler entirely. David, thoughts? NOT closing FDs at this point has been made conditional on Q_OS_WIN or Q_OS_MAC. Others may make it unconditional on all platforms. It might be a safe thing to do... On July 27, 2014, 11:32 a.m., Thomas Lübking wrote: kinit/kinit.cpp, line 1478 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1478 this and line 1504 look like debug leftovers? or are they needed for extra logging? Ian Wadham wrote: I was using them for diagnosing this portability bug in kinit, but I thought it would be best to leave them in as a safety measure, so that someone can see what happened in the event that my issue/question re line 119 (what to do about the usage of DISPLAY in Apple OS X) causes premature termination of kdeinit4 in the future in an Apple OS X environment. This part of the patch has been discontinued. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63257 --- On Sept. 15, 2014, 1:39 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 15, 2014, 1:39 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 15, 2014, 1:39 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- This is a new patch for KCrash only (on KDE 4), to prevent it crashing on Apple OS X and to make it start Dr Konqi on Apple OS X only by forking, because starting Dr K via kdeinit4 always fails on Apple OS X. The patch also incorporates ideas arising in previous reviews and closes the relevant issues. The proposed changes to kinit/kinit.cpp (kdeinit4) have been discontinued temporarily. This is because I appealed for help and answers to some questions about kdeinit4, klauncher, kwrapper and kded4 and how they should interact with each other and with applications, but I was not able to get that help and those answers. So KDE 4 software on MacPorts and Apple OS X will continue as before, making minimal to zero use of those background processes. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs (updated) - kdeui/util/kcrash.cpp 45eb46b Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software. Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 Warning: connect() failed: : No such file or directory With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating). I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
On July 28, 2014, 12:57 a.m., Ian Wadham wrote: kinit/kinit.cpp, line 119 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line119 The real issue is on this line. I do not know how MAC_DISPLAY got into the act, but clearly it has not been tested recently, if ever. There is no MAC_DISPLAY in Apple OS X. Also DISPLAY is a threatened species in Mac OS X and its existence in an installation appears to depend, in more recent versions of Apple OS X, on whether FOSS XQuartz (a non-Apple X11 emulator) is installed. It is not clear ATM whether the socket name on which kinit listens needs to be qualified in some way on Apple OS X, as opposed to Linux and X11, or whether $DISPLAY could safely have an empty string as its value. Also, I find it questionable that kinit.cpp, wrapper.c and kcrash.cpp use different methods or cloned source-code to evaluate the all-important socket name on which they will communicate. See kdeui/util/kcrash.cpp line 637. There must be a better way to program this... That is why I would like to see some KDE core developers reviewing this code. I am not a KDE core developer. David Faure wrote: The reason we have $DISPLAY in the kdeinit socket name on X11, is to allow the same user to have more than one graphical session. I don't mean two full KDE-workspace instances running (they'd overwrite config files), but it happened to me sometimes that I would use ssh -X from another machine, then start one app (which wasn't running in the main session). What happens then is that another kdeinit4 starts, in that separate session (which has a separate dbus session). So it should all be separate from the main session, hence $DISPLAY. AFAIK this use case doesn't apply to Mac, so it would be ok to have an empty string in there. René J.V. Bertin wrote: It doesn't, indeed, and OS X doesn't allow non-X11 apps to be started remotely. (It doesn't really work for me on Linux either, launching a KDE app from an ssh-X session rarely if ever started a new dbus session for me ...) David Faure wrote: (It should have, after dbus got support for autostarting session, but otherwise you can always do it by hand eval `dbus-launch` ; kdeinit4 ; kmyapp ) René J.V. Bertin wrote: Ah, yes, I do get something like that printed on the terminal - but since I'm a tcsh-addicted dinosaur I cannot simply copy/paste the suggestion and I've never yet bothered to figure out how to translate them. Easier to start x11vnc and connect to the main session :) Ian Wadham wrote: Thank you, David, for taking the time to reply. I know you are always very busy. So the easiest fix on Apple OS X (all versions) would be to use $DISPLAY whenever the socket name is computed and allow an empty string. I will modify this patch accordingly. David, can you find a core developer from the Frameworks team to help me occasionally with advice, answers to technical questions and reviews? I am really struggling with the KDE portability problems on Apple OS X and I am sure I could work many times faster with a little expert help. Michael Pyne has helped me a lot in the last week or two, but he has business commitments coming up. This part of the patch has been discontinued. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63291 --- On Sept. 15, 2014, 1:39 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 15, 2014, 1:39 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 15, 2014, 1:59 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Summary (updated) - Report crashes of KDE apps in Apple OS X (1) (fix kcrash) Repository: kdelibs Description (updated) --- *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page. When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs - kdeui/util/kcrash.cpp 45eb46b Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software. Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports: KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 Warning: connect() failed: : No such file or directory With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating). I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning. Thanks, Ian Wadham
Working on Dr Konqi
Hi guys, This is to let you know that I am working on Dr Konqi on KDE 4.14, mainly to get it to work properly on the Apple OS X platform and allow crash reports to be submitted from there. But also, I am going to have a go at updating it to use tokens on Bugzilla 4.4.5 instead of cookies. I would also like to make Dr K sensitive to new versions of Bugzilla, so that it can be coded ahead of time to accommodate changes, such as from cookies to tokens as occurred in July. I expect that the changes I make will be portable forward to KF 5. Cheers, Ian W.
Location of Dr Konqi in Frameworks/KF 5
Hi guys, I have heard that Dr Konqi source code for Frameworks/KF 5 has been placed in plasma-workspace. Please could you consider keeping it in some location that is common to all platforms? This includes both Linux platforms and non-Linux platforms, such as Windows and Apple OS X, where Plasma is not usually required. Dr K used to be in kde-runtime on KDE 4 and is needed on every platform, along with KCrash. Cheers, Ian W.
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) Ian Wadham wrote: The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. Thomas Lübking wrote: Well, the claim is that aborting for no cookie support is wrong in the first place. If so, drop the code. If not (or unsure) please don't break it with an unrelated patch. Aaron J. Seigo wrote: The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog. Sorry for the typos. This form barel works at all with the android web browser :( miAnimizin Ian Wadham wrote: The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs. After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle of the cookie check (on Apple OS X). Dr K uses remote procedure calls to do its work on BKO (class KXmlRpc::Client), including logging in. See code in kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K could somehow connect to BKO via the user's browser of choice or cookies therein, using something really portable, similar to QDesktopServices::openUrl(), but I cannot see any immediate way to do that. I have another bug, not yet investigated in detail, where Dr K has lost the login to BKO somehow and cannot submit the completed report, but it was still able to save it in a file. It is hard to know how to test Dr K's bug-report submission thoroughly without cluttering up BKO with irrelevant reports. Is there a test version of the BKO database somewhere? Ben Cooksley wrote: The use of the Bugzilla XMLRPC api is required i'm afraid. The web browser interface cannot be used - due to CSRF protections now built into it. In addition, it changes from time to time breaking compatability. This form of HTML scraping was used by prior versions of Dr Konqi - and broke quite badly when Bugzilla was upgraded to 4.2.x. Ian Wadham wrote: @Ben Cooksley: Understood. I was thinking more along the lines of connecting without starting a browser window (which would be a nuisance for the user anyway), but somehow using the cookies that might have been stored by the user's browser of choice, and if that fails THEN ask for username and password. Our problem, on Apple OS X, is that none of Dr K works ATM if your browser of choice is Safari or Firefox or even Konqueror, because the cookies are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of course, Dr K must still use KXmlRpc::Client for data transfer to and fro. RJVB Bertin wrote: ? Maybe it's because I have Chrome as my default browser, but Konqueror uses the kcookiejar over here. If I make sure kded4 is running, that is; otherwise it can't. I do have a bit of a hard time believing that someone tweaked things so that KDE would use the native cookie store but as a function of which browser you have configured as a default. (If I'd have to chose I'd say that support for native plugins is a tad more useful!) Ben Cooksley wrote: Unfortunately Bugzilla has removed support for using cookies to submit XMLRPC API queries in version 4.4, in favour of access tokens so it isn't possible to do that either i'm afraid :( Ian Wadham wrote: It seems that bugs.kde.org has changed to using
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) Ian Wadham wrote: The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. Thomas Lübking wrote: Well, the claim is that aborting for no cookie support is wrong in the first place. If so, drop the code. If not (or unsure) please don't break it with an unrelated patch. Aaron J. Seigo wrote: The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog. Sorry for the typos. This form barel works at all with the android web browser :( miAnimizin Ian Wadham wrote: The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs. After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle of the cookie check (on Apple OS X). Dr K uses remote procedure calls to do its work on BKO (class KXmlRpc::Client), including logging in. See code in kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K could somehow connect to BKO via the user's browser of choice or cookies therein, using something really portable, similar to QDesktopServices::openUrl(), but I cannot see any immediate way to do that. I have another bug, not yet investigated in detail, where Dr K has lost the login to BKO somehow and cannot submit the completed report, but it was still able to save it in a file. It is hard to know how to test Dr K's bug-report submission thoroughly without cluttering up BKO with irrelevant reports. Is there a test version of the BKO database somewhere? Ben Cooksley wrote: The use of the Bugzilla XMLRPC api is required i'm afraid. The web browser interface cannot be used - due to CSRF protections now built into it. In addition, it changes from time to time breaking compatability. This form of HTML scraping was used by prior versions of Dr Konqi - and broke quite badly when Bugzilla was upgraded to 4.2.x. @Ben Cooksley: Understood. I was thinking more along the lines of connecting without starting a browser window (which would be a nuisance for the user anyway), but somehow using the cookies that might have been stored by the user's browser of choice, and if that fails THEN ask for username and password. Our problem, on Apple OS X, is that none of Dr K works ATM if your browser of choice is Safari or Firefox or even Konqueror, because the cookies are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of course, Dr K must still use KXmlRpc::Client for data transfer to and fro. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 30, 2014, 1:04 p.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 30, 2014, 1:04 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/gdbhighlighter.cpp, line 74 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74 an abort is not a crash ;-) If you hit this assert, the looked up (lineNr - 1) is somehow out of bounds, ie. there's no line with a key = (lineNr -1) in the map. This should likely never happen on any system. Can you check what the lineNr actually is as compared to qDebug() lineNr lines.keys(); ? Ian Wadham wrote: I did at one time have a few qDebug() statements to try and find what was wrong with the algorithm. AFAICT it is trying to match one or more lines in (const QString text) with single (possibly long) lines of backtrace in QMapint, BacktraceLine. I think it failed if one backtrace line was formatted into three text lines or maybe if the last backtrace line was formatted into two text lines. AFAICT (there is a real dearth of explanatory comments) the code is merely introducing pretty colours, etc. into the formatted text. As such, it should not abort Dr Konqi and lose the crash report. Thomas Lübking wrote: Of course it should not crash. The point is that the assert explicitly tells you that there's something wrong with the code. Skippping it won't fix the issu - that's like puting duct tape over a warning sign on your cars dashboard to fix no cooling water. Since the lines map seems only used to map lines to textblocks, i assume the issue is that the lines are eg. not \n terminated in gdb output on OSX (no idea, though) and the only item in the map is that for the key 0 In this case that'd be the issue to fix. Ian Wadham wrote: Please spare me the motoring analogies. To me, the ASSERT at this point, is like bringing the car to a screeching halt or running it into the nearest fence, simply because the glovebox light will not come on. I am a real-time and O/S programmer from way back and have designed and written a few crash procedures for different systems. They need to be rugged and simple (unlike Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe programming, graceful failure or graceful degradation. If an ASSERT and abort technique has to be used in RT programming, to prevent potential database corruption, it needs to be backed by an appropriate recovery and restart procedure. Actually I think lines.end() is a legitimate return from lines.lowerBound(lineNr - 1) in Dr K's algorithm (see http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The lineNr can actually get ahead of the number of lines in the map by by too much, if there are several multi-line entries in QString text. Using an ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in this case, so I'll put in an ASSERT and see if it actually happens in practice. ???). My solution is to re-use the last entry from the QMap. Another might be to use return; instead of the ASSERT, leaving the last bit of the highlighting incomplete, but not losing the valuable backtrace data. A better (more rugged) approach might be: get a line from text if it is from the left-hand end of a backtrace entry (i.e. not a continuation line) get the next backtrace entry if past last entry return re-format the line from text I would have used something like that in my patch, but I do not know enough about the format of backtrace data to get the first if condition right. How would I? Re \n characters, they occur as expected in the content of QString text on Apple OS X. RJVB Bertin wrote: If it walks and talks like a crash ... we should not end up in the discussion deadlock I once had with my boss who claimed embedded code cannot crash (because there's no OS or whatelse to replace the application code). Anyway, I like Ian's suggestion to just return to the caller instead of exitting (and I concur with his lazy programming analysis). So if I understood correctly, DrKonqi does some reformatting of the backtrace before including it for upload with the bug report. What I haven't understood is how important this reformatting is. Could it be a thought to cancel the reformating procedure and return with the raw text, instead of with a partly formated text, when the assert condition triggers? About processing backtraces: recent OS X versions use lldb instead of gdb. How have you tackled that, Ian - added a dependency on port:gdb ? Aaron J. Seigo wrote: This is not lazy programming but programming by contract. That it reaches the lasT of lines is a bug... it should nEver happen algorithmic Ally. The bug appears to be lowerbound sage. It returns
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) Ian Wadham wrote: The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. Thomas Lübking wrote: Well, the claim is that aborting for no cookie support is wrong in the first place. If so, drop the code. If not (or unsure) please don't break it with an unrelated patch. Aaron J. Seigo wrote: The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog. Sorry for the typos. This form barel works at all with the android web browser :( miAnimizin The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs. After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle of the cookie check (on Apple OS X). Dr K uses remote procedure calls to do its work on BKO (class KXmlRpc::Client), including logging in. See code in kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K could somehow connect to BKO via the user's browser of choice or cookies therein, using something really portable, similar to QDesktopServices::openUrl(), but I cannot see any immediate way to do that. I have another bug, not yet investigated in detail, where Dr K has lost the login to BKO somehow and cannot submit the completed report, but it was still able to save it in a file. It is hard to know how to test Dr K's bug-report submission thoroughly without cluttering up BKO with irrelevant reports. Is there a test version of the BKO database somewhere? - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 30, 2014, 1:04 p.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 30, 2014, 1:04 p.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: kinit/kinit.cpp, line 1481 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481 do you need $DISPLAY in OS X? RJVB Bertin wrote: Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference. In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running. Ian Wadham wrote: Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow doctors the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably. This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best? I tried using lxr.kde.org to find further references, but there are thousands: mostly because display is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work. RJVB Bertin wrote: Hmm, interesting. I should find some time to play with this in my 10.9 VM. Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart. If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value. This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY. Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63447 --- On July 27, 2014, 9:15 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated July 27, 2014, 9:15 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/gdbhighlighter.cpp, line 74 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74 an abort is not a crash ;-) If you hit this assert, the looked up (lineNr - 1) is somehow out of bounds, ie. there's no line with a key = (lineNr -1) in the map. This should likely never happen on any system. Can you check what the lineNr actually is as compared to qDebug() lineNr lines.keys(); ? Ian Wadham wrote: I did at one time have a few qDebug() statements to try and find what was wrong with the algorithm. AFAICT it is trying to match one or more lines in (const QString text) with single (possibly long) lines of backtrace in QMapint, BacktraceLine. I think it failed if one backtrace line was formatted into three text lines or maybe if the last backtrace line was formatted into two text lines. AFAICT (there is a real dearth of explanatory comments) the code is merely introducing pretty colours, etc. into the formatted text. As such, it should not abort Dr Konqi and lose the crash report. Thomas Lübking wrote: Of course it should not crash. The point is that the assert explicitly tells you that there's something wrong with the code. Skippping it won't fix the issu - that's like puting duct tape over a warning sign on your cars dashboard to fix no cooling water. Since the lines map seems only used to map lines to textblocks, i assume the issue is that the lines are eg. not \n terminated in gdb output on OSX (no idea, though) and the only item in the map is that for the key 0 In this case that'd be the issue to fix. Ian Wadham wrote: Please spare me the motoring analogies. To me, the ASSERT at this point, is like bringing the car to a screeching halt or running it into the nearest fence, simply because the glovebox light will not come on. I am a real-time and O/S programmer from way back and have designed and written a few crash procedures for different systems. They need to be rugged and simple (unlike Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe programming, graceful failure or graceful degradation. If an ASSERT and abort technique has to be used in RT programming, to prevent potential database corruption, it needs to be backed by an appropriate recovery and restart procedure. Actually I think lines.end() is a legitimate return from lines.lowerBound(lineNr - 1) in Dr K's algorithm (see http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The lineNr can actually get ahead of the number of lines in the map by by too much, if there are several multi-line entries in QString text. Using an ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in this case, so I'll put in an ASSERT and see if it actually happens in practice. ???). My solution is to re-use the last entry from the QMap. Another might be to use return; instead of the ASSERT, leaving the last bit of the highlighting incomplete, but not losing the valuable backtrace data. A better (more rugged) approach might be: get a line from text if it is from the left-hand end of a backtrace entry (i.e. not a continuation line) get the next backtrace entry if past last entry return re-format the line from text I would have used something like that in my patch, but I do not know enough about the format of backtrace data to get the first if condition right. How would I? Re \n characters, they occur as expected in the content of QString text on Apple OS X. RJVB Bertin wrote: If it walks and talks like a crash ... we should not end up in the discussion deadlock I once had with my boss who claimed embedded code cannot crash (because there's no OS or whatelse to replace the application code). Anyway, I like Ian's suggestion to just return to the caller instead of exitting (and I concur with his lazy programming analysis). So if I understood correctly, DrKonqi does some reformatting of the backtrace before including it for upload with the bug report. What I haven't understood is how important this reformatting is. Could it be a thought to cancel the reformating procedure and return with the raw text, instead of with a partly formated text, when the assert condition triggers? About processing backtraces: recent OS X versions use lldb instead of gdb. How have you tackled that, Ian - added a dependency on port:gdb ? Aaron J. Seigo wrote: This is not lazy programming but programming by contract. That it reaches the lasT of lines is a bug... it should nEver happen algorithmic Ally. The bug appears to be lowerbound sage. It returns
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
On July 28, 2014, 12:57 a.m., Ian Wadham wrote: kinit/kinit.cpp, line 119 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line119 The real issue is on this line. I do not know how MAC_DISPLAY got into the act, but clearly it has not been tested recently, if ever. There is no MAC_DISPLAY in Apple OS X. Also DISPLAY is a threatened species in Mac OS X and its existence in an installation appears to depend, in more recent versions of Apple OS X, on whether FOSS XQuartz (a non-Apple X11 emulator) is installed. It is not clear ATM whether the socket name on which kinit listens needs to be qualified in some way on Apple OS X, as opposed to Linux and X11, or whether $DISPLAY could safely have an empty string as its value. Also, I find it questionable that kinit.cpp, wrapper.c and kcrash.cpp use different methods or cloned source-code to evaluate the all-important socket name on which they will communicate. See kdeui/util/kcrash.cpp line 637. There must be a better way to program this... That is why I would like to see some KDE core developers reviewing this code. I am not a KDE core developer. David Faure wrote: The reason we have $DISPLAY in the kdeinit socket name on X11, is to allow the same user to have more than one graphical session. I don't mean two full KDE-workspace instances running (they'd overwrite config files), but it happened to me sometimes that I would use ssh -X from another machine, then start one app (which wasn't running in the main session). What happens then is that another kdeinit4 starts, in that separate session (which has a separate dbus session). So it should all be separate from the main session, hence $DISPLAY. AFAIK this use case doesn't apply to Mac, so it would be ok to have an empty string in there. RJVB Bertin wrote: It doesn't, indeed, and OS X doesn't allow non-X11 apps to be started remotely. (It doesn't really work for me on Linux either, launching a KDE app from an ssh-X session rarely if ever started a new dbus session for me ...) David Faure wrote: (It should have, after dbus got support for autostarting session, but otherwise you can always do it by hand eval `dbus-launch` ; kdeinit4 ; kmyapp ) RJVB Bertin wrote: Ah, yes, I do get something like that printed on the terminal - but since I'm a tcsh-addicted dinosaur I cannot simply copy/paste the suggestion and I've never yet bothered to figure out how to translate them. Easier to start x11vnc and connect to the main session :) Thank you, David, for taking the time to reply. I know you are always very busy. So the easiest fix on Apple OS X (all versions) would be to use $DISPLAY whenever the socket name is computed and allow an empty string. I will modify this patch accordingly. David, can you find a core developer from the Frameworks team to help me occasionally with advice, answers to technical questions and reviews? I am really struggling with the KDE portability problems on Apple OS X and I am sure I could work many times faster with a little expert help. Michael Pyne has helped me a lot in the last week or two, but he has business commitments coming up. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63291 --- On July 27, 2014, 9:15 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated July 27, 2014, 9:15 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 111 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111 This can go unconditionally. Show really only shows the window. Becoming active and then raise for that is WM detail - and WMs have to deal with inadequate raise requests anyway ;-) I do not understand your comments at all. I just know that the raise() is essential in this context, otherwise the end-user never sees Dr Konqi's window and never investigates or reports the crash. On Apple OS X, an app which is started properly, by clicking an icon or running an Apple OS X open command, will raise the app's window, but Dr Konqi is not being started this way. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 27, 2014, 9:16 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 27, 2014, 9:16 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/reportassistantpages_bugzilla.cpp 86ca327 drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 286 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286 #ifndef No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. ATM they are only explanatory. But there is a place to add code if anybody can think of something appropriate (e.g. to check for cookies on the user's browser of choice in a portable way, maybe using Qt). On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 27, 2014, 9:16 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 27, 2014, 9:16 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/reportassistantpages_bugzilla.cpp 86ca327 drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/gdbhighlighter.cpp, line 74 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74 an abort is not a crash ;-) If you hit this assert, the looked up (lineNr - 1) is somehow out of bounds, ie. there's no line with a key = (lineNr -1) in the map. This should likely never happen on any system. Can you check what the lineNr actually is as compared to qDebug() lineNr lines.keys(); ? I did at one time have a few qDebug() statements to try and find what was wrong with the algorithm. AFAICT it is trying to match one or more lines in (const QString text) with single (possibly long) lines of backtrace in QMapint, BacktraceLine. I think it failed if one backtrace line was formatted into three text lines or maybe if the last backtrace line was formatted into two text lines. AFAICT (there is a real dearth of explanatory comments) the code is merely introducing pretty colours, etc. into the formatted text. As such, it should not abort Dr Konqi and lose the crash report. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 27, 2014, 9:16 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 27, 2014, 9:16 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/reportassistantpages_bugzilla.cpp 86ca327 drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e Diff: https://git.reviewboard.kde.org/r/119498/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome. Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998. I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)
On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: kinit/kinit.cpp, line 1481 https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481 do you need $DISPLAY in OS X? RJVB Bertin wrote: Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference. In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running. Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow doctors the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably. This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best? I tried using lxr.kde.org to find further references, but there are thousands: mostly because display is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63447 --- On July 27, 2014, 9:15 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated July 27, 2014, 9:15 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kdelibs Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have two portability problems: 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely. 2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash. This deafness of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment. Diffs - kdeui/util/kcrash.cpp 45eb46b kinit/kinit.cpp e41845a Diff: https://git.reviewboard.kde.org/r/119497/diff/ Testing --- Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/gdbhighlighter.cpp, line 74 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74 an abort is not a crash ;-) If you hit this assert, the looked up (lineNr - 1) is somehow out of bounds, ie. there's no line with a key = (lineNr -1) in the map. This should likely never happen on any system. Can you check what the lineNr actually is as compared to qDebug() lineNr lines.keys(); ? Ian Wadham wrote: I did at one time have a few qDebug() statements to try and find what was wrong with the algorithm. AFAICT it is trying to match one or more lines in (const QString text) with single (possibly long) lines of backtrace in QMapint, BacktraceLine. I think it failed if one backtrace line was formatted into three text lines or maybe if the last backtrace line was formatted into two text lines. AFAICT (there is a real dearth of explanatory comments) the code is merely introducing pretty colours, etc. into the formatted text. As such, it should not abort Dr Konqi and lose the crash report. Thomas Lübking wrote: Of course it should not crash. The point is that the assert explicitly tells you that there's something wrong with the code. Skippping it won't fix the issu - that's like puting duct tape over a warning sign on your cars dashboard to fix no cooling water. Since the lines map seems only used to map lines to textblocks, i assume the issue is that the lines are eg. not \n terminated in gdb output on OSX (no idea, though) and the only item in the map is that for the key 0 In this case that'd be the issue to fix. Please spare me the motoring analogies. To me, the ASSERT at this point, is like bringing the car to a screeching halt or running it into the nearest fence, simply because the glovebox light will not come on. I am a real-time and O/S programmer from way back and have designed and written a few crash procedures for different systems. They need to be rugged and simple (unlike Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe programming, graceful failure or graceful degradation. If an ASSERT and abort technique has to be used in RT programming, to prevent potential database corruption, it needs to be backed by an appropriate recovery and restart procedure. Actually I think lines.end() is a legitimate return from lines.lowerBound(lineNr - 1) in Dr K's algorithm (see http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The lineNr can actually get ahead of the number of lines in the map by by too much, if there are several multi-line entries in QString text. Using an ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in this case, so I'll put in an ASSERT and see if it actually happens in practice. ???). My solution is to re-use the last entry from the QMap. Another might be to use return; instead of the ASSERT, leaving the last bit of the highlighting incomplete, but not losing the valuable backtrace data. A better (more rugged) approach might be: get a line from text if it is from the left-hand end of a backtrace entry (i.e. not a continuation line) get the next backtrace entry if past last entry return re-format the line from text I would have used something like that in my patch, but I do not know enough about the format of backtrace data to get the first if condition right. How would I? Re \n characters, they occur as expected in the content of QString text on Apple OS X. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/#review63254 --- On July 27, 2014, 9:16 a.m., Ian Wadham wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated July 27, 2014, 9:16 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime Description --- When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of Why does nobody report the problem(s) on bugs.kde.org? It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks. So far I have identified a number of portability bugs in KDE on Apple OS X: 1
