Description of problem: Reporting installer bugs to bugzilla fail with rpc error: No version named ‘16-Alpha‘ in the 'Fedora' product Version-Release number of selected component (if applicable): https://admin.fedoraproject.org/updates/anaconda-16.14.5-1.fc16 https://admin.fedoraproject.org/updates/libreport-2.0.5-5.fc16 https://admin.fedoraproject.org/updates/lorax-16.4.1-1.fc16 16AlphaRC4 How reproducible: 100% Steps to Reproduce: 1.https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla Actual results: unable to automatically report bug to bugzilla Expected results: Shouldn't the version be '16' instead of ‘16-Alpha‘ for bugs reported to bugzilla?
Created attachment 518408 [details] error_window.png
Well this is taken from the anaconda product string which is in .buildstamp file, which is made by lorax based on the parameter given to pungi. So I see 2 options. Either you need to make composes with a different product parameter, or libreport can strip any -Alpha, -Beta suffixes from the product string.
I think this may have been a compose time error, Dennis? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
We can make the version parsing in libreport more robust, but I would really like to see some rule about the version string to prevent this situation in future when someone else come up with new awesome idea how to format it. btw, if it was "F16 Alpha" (without the dash) it would work. So how about keeping the same format as in /etc/system-release: Fedora release 16 (Verne) Fedora release 16 (Rawhide) Fedora release 16 ({Alpha, Beta, Gamma, ..})
I was able to report a traceback when running the *live* installer, FWIW. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It is related to the --ver argument passed to pungi during compose. It sure would be nice to define acceptable values for the --ver argument. However, that's an exercise for the retrospective, not this bug report. There is some existing anaconda logic to prune out non-integer numbers from the version string (refer to http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=da70178ecaadcfd875cf8a6cb36c0b2605f972bc). It seems this same logic is needed elsewhere in anaconda now too. I'm not yet sure if libreport needs to be told '16' (and not '16-Alpha'), or if libreport is doing the guesswork to determine the appropriate version.
(In reply to comment #6) > There is some existing anaconda logic to prune out non-integer numbers from the > version string Heh, you know what I mean :) s/non-integer numbers/non-numerics/ I believe jmoskovc may already have a libreport fix in the works to address this issue?
this is how we determine the version: def getVersion_fromPRODUCT(): try: from pyanaconda import product return product.productVersion except: try: import product return product.productVersion except: return "" I fixed it on libreport side, at least for now ...
libreport-2.0.5-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libreport-2.0.5-6.fc16
*** Bug 730898 has been marked as a duplicate of this bug. ***
Package libreport-2.0.5-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.0.5-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreport-2.0.5-6.fc16 then log in and leave karma (feedback).
Discussed in an impromptu blocker review in #fedora-qa on 2011-08-16. Accepted as a blocker under the criterion "The installer must be able to report failures to Bugzilla, with appropriate information included" with +1s from myself, jsmith, tflink, red_alert (sandro mathys), and dgilmore.
Confirmed it fixed in anaconda 16.14.6 of F16-alpha-rc5
Thanks, setting VERIFIED.
libreport-2.0.5-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 741211 has been marked as a duplicate of this bug. ***
This was re-animated in libreport-2.0.5.980-1.fc16.x86_64 as the relevant patch was not sent upstream, but was dropped from the spec :( https://bugzilla.redhat.com/show_bug.cgi?id=741211 was the report, and I just went through the git logs. If no-one's around to fix this I can do it, should be a simple matter of re-introducing the patch.
libreport-2.0.5.982-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/libreport-2.0.5.982-1.fc16
tflink created a boot.iso for testing this: http://tflink.fedorapeople.org/iso/20110926_libreport.x64.boot.iso I booted with that boot.iso and followed the randomize_tb path of http://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla , and successfully reported https://bugzilla.redhat.com/show_bug.cgi?id=741420 . Fix looks good to me.
Package libreport-2.0.5.982-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.0.5.982-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreport-2.0.5.982-1.fc16 then log in and leave karma (feedback).
Fixed in 16 Beta RC3 (i386 and x86_64).
Confirmed fixed in Fedora 16 beta RC3 x86_64. Moving to VERIFIED.
libreport-2.0.5.982-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.