Bug 989162

Summary: virt-install fails when pointed at rawhide tree (invalid literal for int() with base 10: 'rawhide')
Product: [Fedora] Fedora Reporter: Lars Seipel <ls>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: berrange, crobinso, hbrock, jforbes, patrick, sochotni, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-manager-0.10.0-4.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1091666 (view as bug list) Environment:
Last Closed: 2013-10-10 00:56:32 UTC Type: Bug
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: 1091666, 1321719    
Attachments:
Description Flags
trivial patch to unbreak virt-install on current rawhide trees none

Description Lars Seipel 2013-07-28 06:08:43 UTC 
Created attachment 779269 [details]
trivial patch to unbreak virt-install on current rawhide trees

As the rawhide compose now generates install images again[1] I pointed virt-install at a suitable install tree (--location=$url). Virt-install fails with the following line:

ERROR (cli:451) Error validating install location: invalid literal for int() with base 10: 'rawhide'

The corresponding backtrace points to FedoraDistro.isValidStore in virtinst/OSDistro.py. After collecting version information from the treeinfo it checks if the returned version is "development". This doesn't seem to be true for current rawhide trees which return "rawhide".

When encountering a version of "rawhide" the os_variant should be set to the latest Fedora version, as is done for "development". The attached trivial patch (against virt-manager.git) does this.

If a version of "development" is no longer used at all it additionally might be possible to remove the check for it.

Version-Release number of selected component (if applicable):
virt-manager-common-0.10.0-1.fc19.noarch

Additional info:
[1] https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001201.html
Comment 1 Cole Robinson 2013-07-29 16:29:21 UTC 
Thanks Lars, I pushed your patch upstream:

https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=72648c9185e3ccb27fb9896a4e7a48f1769c8a4e
Comment 2 Fedora Update System 2013-09-24 15:48:35 UTC 
virt-manager-0.10.0-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/virt-manager-0.10.0-2.fc19
Comment 3 Fedora Update System 2013-09-26 06:23:27 UTC 
Package virt-manager-0.10.0-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17656/virt-manager-0.10.0-2.fc19
then log in and leave karma (feedback).
Comment 4 Fedora Update System 2013-10-06 19:40:21 UTC 
virt-manager-0.10.0-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/virt-manager-0.10.0-4.fc19
Comment 5 Fedora Update System 2013-10-10 00:56:32 UTC 
virt-manager-0.10.0-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 6 Patrick Monnerat 2016-10-22 17:07:44 UTC 
Should be reopened: release name is now "Rawhide", causing the same error.
Tested with F23 and virt-manager-common-1.3.2-2. Test is now in file /usr/share/virt-manager/virtinst/urlfetcher.py.