Bug 574748
Summary: | anaconda/python-meh is filing F-13 bugs with version=rawhide | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | James Laska <jlaska> |
Component: | anaconda | Assignee: | Chris Lumens <clumens> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | dcantrell, jonathan, jturner, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | python-meh-0.7.1-1.fc13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-24 16:20:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 507684 |
Description
James Laska
2010-03-18 13:06:27 UTC
Moved to F13Target after discussion in the F13 Beta blocker review meeting. This would be nice to have for Beta, but we would not hold beta for this bug. Can you point me to a tree that was exhibiting this behavior? (In reply to comment #2) > Can you point me to a tree that was exhibiting this behavior? http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.TC0/Fedora/ Okay here's what I think is going on. In that tree's .buildstamp, we have: 201003152222.i386 Fedora 13-Beta https://bugzilla.redhat.com That means product.productVersion is "13-Beta". Later, we go grab a list of all the valid product versions for Fedora according to bugzilla, 13-Beta is nowhere to be found. So we fall back to the default of rawhide. In other words, this should not affect the final release of F13. If we care enough for the test releases, I can make meh smart enough to recognize this condition and try trimming off the "-whatever" from version numbers. Do we care enough? For the future, I do not know how report plans on getting the version number but it may be worth bringing this issue up with them too. Otherwise we may just see it again on F14. Doesn't seem like a huge problem to release with, but I don't think just filing bugs against rawhide is the right answer either. Adding jkeating to the list, but I'd propose that .buildstamp: 201003152222.i386 Fedora 13 https://bugzilla.redhat.com The datestamp and contents of .treeinfo sha256sum's can be used to determine what particular build this represents. Jesse, any objections or concerns? To accomplish that, we'd have to start calling the version "13" and not "13-Beta" which would screw up path names and iso names. So we either have to "hack" it in pungi or hack it in python-meh. I would much rather work around this in meh than do anything crazy in pungi or .buildstamp, as those are going to affect a whole lot more components. Does updates=http://clumens.fedorapeople.org/574748.img fix this issue? (In reply to comment #7) > Does updates=http://clumens.fedorapeople.org/574748.img fix this issue? Seems to do the trick (see bug#576264 for example). python-meh-0.7.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/python-meh-0.7.1-1.fc13 python-meh-0.7.1-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-meh'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/python-meh-0.7.1-1.fc13 python-meh-0.7.1-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |