Description of problem: See example bug filed by anaconda - bug#696237 Version-Release number of selected component (if applicable): * report-0.20-1.fc15 How reproducible: Steps to Reproduce: 1. https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla Actual results: Fedora 15 installer bugs are filed against version='rawhide' Expected results: Fedora 15 installer bugs should be filed against version='15' Additional info:
Discussed at 2011-04-15 blocker review meeting. We agreed this partly hits Alpha criterion "# The installer must be able to report failures to Bugzilla, with appropriate information included ", but the practical impact is not terrible: bugs would still be reported, and fixes are going to wind up in F16 whether the report is against 15 or 16. Accepted as NTH, though, it should be a trivial fix and we should fix it if possible. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So there are two problems here. The first is that the python module that used to be named 'product' is now 'pyanaconda/product'. I have fixed that. The second problem is that, for F15 Alpha, the version stored in pyanaconda.product.productVersion is '15-Alpha'. and the code in the Bugzilla Filer module is expecting that version to exactly match one of the versions in bugzilla.redhat.com (for Product Fedora). Obviously I can strip off the dash and everything after it, but what's really needed here is some kind specification of values can appear in pyanaconda.product.productVersion and pyanaconda.product.productName and how they get mapped to bugzilla products and versions. James, is that possible?
(In reply to comment #2) > Obviously I can strip off the dash and everything after it, but what's really > needed here is some kind specification of values can appear in > pyanaconda.product.productVersion and pyanaconda.product.productName and how > they get mapped to bugzilla products and versions. James, is that possible? I don't think that's unexpected, but someone from anaconda-devel@ would know for sure (clumens cc'd). Assuming the value for pyanaconda.product.productName is also the same value used in .treeinfo for the 'version' attribute, the version will only be a digit at the final release. It appears to be suffixed with -Alpha or -Beta depending on the interim milestone. * F-12/Alpha/Fedora/x86_64/os/.treeinfo:version = 12-Alpha * F-12/Beta/Fedora/x86_64/os/.treeinfo:version = 12-Beta * F-12/GOLD/Fedora/x86_64/os/.treeinfo:version = 12 * F-13/Alpha/Fedora/x86_64/os/.treeinfo:version = 13-Alpha * F-13/Beta/Fedora/x86_64/os/.treeinfo:version = 13-Beta * F-13/GOLD/Fedora/x86_64/os/.treeinfo:version = 13 * F-14/Alpha/Fedora/x86_64/os/.treeinfo:version = 14-Alpha * F-14/Beta/Fedora/x86_64/os/.treeinfo:version = 14-Beta * F-14/GOLD/Fedora/x86_64/os/.treeinfo:version = 14 * F-15/Alpha/Fedora/x86_64/os/.treeinfo:version = 15-Alpha * F-15/Beta/Fedora/x86_64/os/.treeinfo:version = 15-Beta As for a formal specification of acceptable values, perhaps clumens or rel-eng can provide that information.
There's not really any formal specification of what those values can be. It's been my intention that they stay numbers we can use for things like bug filing and upgrade allowance checking, but obviously we don't do any enforcing. anaconda just takes the value from .treeinfo, which gets it from lorax, which gets it passed straight from the pungi command line. Given the history shown above, I'd say the most reasonable thing to do here is just assume we'll continue to have "-Alpha" and "-Beta" and trim off appropriately. I should probably do the same to anaconda's upgrade checking code.
OK, that's what I'll do.
I guess it would probably be a good idea to add a comment in the anaconda code to the effect that the string used there is significant for external consumers and that it would be a good idea to stick to the same format in future, and if it has to be changed, notify (list of consumers) about the change?
report-0.20-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/report-0.20-2.fc15
Package report-0.20-2.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing report-0.20-2.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/report-0.20-2.fc15 then log in and leave karma (feedback).
Tested using a private boot.iso, and confirmed this resolves the reported bug.
Also tested using the same custom boot.iso as jlaska. The test created bug 700196 which is correctly assigned against F15. That bug has been closed.
report-0.20-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.