When DrKonqi sends to bugs.kde.org a crash report from some application whole version string contains white space(like "2.8 Pre-Alpha" or "4.8.5 (4.8.5)"), the version information is lost (meaning the "Version" field is set as "unspecified"). Some recent examples : https://bugs.kde.org/show_bug.cgi?id=320379 https://bugs.kde.org/show_bug.cgi?id=320254 https://bugs.kde.org/show_bug.cgi?id=315602 I'm sure the cause here is not that those versions didn't exist yet when the crash reports were created. I added those versions quite sometime ago. I'm reporting here instead of bugzilla upstream, because I can't reproduce the problem after playing with DrKonqi and the vanilla BugZilla 4.2.5 installed on my local system. This unfortunately looks very like a problem of bugs.kde.org itself. I will add more information and findings in the follow comments. Reproducible: Always
Created attachment 80426 [details] a simple patch to redirect DrKonqi to local bugzilla installation I will summary how to set up a local testing environment. That should help sysadmins to understand and confirm my investigation. The attached simple patch will make DrKonqi sending crash reports to the local bugzilla installation ( say http://localhost/bko). There are still some extra operations to be performed on the local bugzilla installation to make it play together with DrKonqi : 1). add the "drkonqi" keyword 2). for the "OS" field, add the "Linux" value 3). for the "Platform/Hardware" field, add the value corresponding to your distribution, say "Gentoo Packages" or "Compiled Sources." . Use bugs.kde.org as reference. 4). for the "Priority" field, add the "NOR" value. 5). for the "Severity" field, add the "crash" value. 6). add the product corresponding to the crashed application. I use konqueror as testing application, so just add the "konqueror" product, add make sure it has the "general" component and some versions containing spaces . After those bugzilla operations are done, patch konqueror to change its version string to some value that already exists in the local bugzilla installtion, say "2.7 Pre-Alpha". (will attach another simple patch) Next, follow the simple step in https://bugs.kde.org/237652 to make the patched konqueror crash, then use the patched DrKonqi to send the crash reports to the local bugzilla installation. After the report is created, its "Version" field should be set as "2.7 Pre-Alpha" instead of "unspecified".
Created attachment 80427 [details] A simple patch to change konqueror's version string
My testing (see comment #2 for howto) shows that: DrKonqi + https://bugs.kde.org : "Versioin" is set as "unspecified" DrKonqi + local vanilla bugzilla 4.2.5 : "Version" field is correctly set. And here is the real weird thing: DrKonqi + local bugs.kde.org installation (using the kde branch in the kde:websites/bugs-kde-org repo) : "Version" field is also correctly set. So it seems that this very https://bugs.kde.org instance is the only problematic one.
Created attachment 80428 [details] A simple script tarball for easy testing Here is another simple script for easy testing, since using DrKonqi is more time consuming. By the way, this script works with my local bugs.kde.org installation, my local vanilla bugzilla installation and https://landfill.bugzilla.org/bugzilla-4.2-branch, but it doesn't work with https://bugs.kde.org.
And here is why I think this problem is annoying and fixing it is important: 1. It means information loss : "2.7 Pre-Alpha" ==> "unspecified". I know the version information is also contained in the comment, but that is not as useful as the "Version" field. 2. (My suspicion) It means bugs.kde.org will not reject crash reports from those versions which are disabled and contains spaces. So we receive useless crash reports which should have been rejected by bugs.kde.org if this bug is not present. See https://git.reviewboard.kde.org/r/110633/
We have some customisations to certain files - although the only one I can see which affects things here is to enter_bug.cgi - does Dr Konqi use this? -} elsif (formvalue('version')) { +} elsif (formvalue('version') and grep { $_->name eq formvalue('version') } @{ $vars->{'version'} }) {
(In reply to comment #6) > We have some customisations to certain files - although the only one I can > see which affects things here is to enter_bug.cgi - does Dr Konqi use this? > > -} elsif (formvalue('version')) { > +} elsif (formvalue('version') and grep { $_->name eq formvalue('version') } > @{ $vars->{'version'} }) { Most interaction is done through the XMLRPC interface (xmlrpc.cgi), and enter_bug.cgi is not used at all. Please pay special attention to my findings in comment #3. "DrKonqi + local bugs.kde.org installation (using the kde branch in the kde:websites/bugs-kde-org repo) : "Version" field is also correctly set. ". I highly suspect the problem lies in this very https://bugs.kde.org installation, not in the customized code within the kde:websites/bugs-kde-org repo ). That is why I added the simple howto in comment #1, #2 and #4: I hope others can confirm or unconfirm my findings by following the howto.
Okay. Can you try to reproduce against sandbox.bugs.kde.org please? The only things I can think of here are: 1) mod_perl being used. 2) Some dependency version difference.
(In reply to comment #8) > Okay. Can you try to reproduce against sandbox.bugs.kde.org please? > The only things I can think of here are: > 1) mod_perl being used. > 2) Some dependency version difference. Done, see http://sandbox.bugs.kde.org/show_bug.cgi?id=300227. It works as expected, unlike with the https://bugs.kde.org installation. By the way, sandbox.bugs.kde.org doesn't have the 'drkonqi' keyword, which causes a little trouble for the testing.
I notice a rare working example: https://bugs.kde.org/show_bug.cgi?id=321220 I have contacted the reporter in private mail, and he confirmed that that report was created through DrKonqi instead of using the Web interface.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
No response, closing.