Description of problem: unable to build spins from *.ks files Version-Release number of selected component (if applicable): Current as of 12/18/2013 fedora 20 stack. Clean install and update done on 2013/12/18. How reproducible: Always fails Steps to Reproduce: 1. run the following; note it is using the released verson of the kickstart file. livecd-creator --config=/usr/share/spin-kickstarts/fedora-live-base.ks --fslabel=test --tmpdir=/var/tmp/x64 --verbose 2. 3. Actual results: tail Build-test.txt --lines 10 File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 871, in <lambda> urls = property(fget=lambda self: self._geturls(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 868, in _geturls self._baseurlSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 834, in _baseurlSetup self.check() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 554, in check 'Cannot find a valid baseurl for repo: %s' % self.ui_id yum.Errors.RepoError: Cannot find a valid baseurl for repo: fedora Expected results: creation of test.iso Additional info: This appears to be related to closed bug 962183. Which to me implies that 962183 should not have been closed.
It looks like releasever might not be defaulting to the running version of Fedora. I'm fairly sure this used to work. For a workaround use the --releasever option to set the release version.
The Addition of --releasever=$releasever to the livecd-creator command appears to be a good work around. My test build is now actually doing a build. Thanks Bruno.
It looks like fedora-release is now providing an unversioned redhat-release which breaks falling back to using the system version if none is specified. I don't know if this is intentional or not.
In my test script I had set basearch, and releasever as exported vars. The script I am running now is; export basearch=x86_64 export releasever=20 echo "Start X86_64 build at $(date)" > Build-test.txt livecd-creator --config=/usr/share/spin-kickstarts/fedora-live-base.ks --releasever=$releasever --fslabel=test --tmpdir=/var/tmp/x64 --verbose >>Build-test.txt 2>&1 echo "End X86_64 build at $(date)" >> Build-test.txt only change I mas was adding the --releasevars option.
Looking at the spec file for fedora-release shows that redhat-release has been unversioned there for a while (generic-release still has it versioned). So I suspect a library change that affected what was returned for a version for an unversioned provides. In any case, we probably should be checking system-version these days. Both fedora-release and generic-release provide a versioned version of system-release.
releasever isn't picked up from the environment. A library call is made to get rpm information for the installed system.
I seem to recall adding the releasever variable back in F17 days to get things to work for me. It was working in F-17, through F-19 ( until 11-25-2013 which was the last time I built our kiosk CD ). Looks like I have a testable iso now, as the test build just completed.
bug 962183 comments report that downgrading yum also 'fixed' this.
That may be, but I don't think it makes it a yum bug. I think the most correct fix is to switch to checking system-release instead of redhat-release in python-imgcreate. I'm also soliciting opinions about versioning redhat-release in fedora-release as it is in generic-release. This should also take care of the issue.
*** Bug 1044358 has been marked as a duplicate of this bug. ***
Compare #1040607, where the provide being versioned as %version-%release in generic-release caused a problem.
Yeah, my suggestion above won't work as the system-release provides would hit the problem in bug 1040607. We might want either smart(?) parsing of the version-release of provides in yum's library or to start providing system-release(release) instead of the current provides.
And we might want to do something different for f19, f20 and rawhide.
To be consistent with yum.conf we probably want to use the same value for distropkg in python-imgcreate: ['system-release(releasever)', 'redhat-release'] instead of just 'redhat-release'. It probably makes sense to have fedora-release and generic-release provide system-release(releasever) = 20 (or 21 or 19 as appropriate). We need system-release for some things that want either fedora-release or generic-release. I doubt versioning is needed for that. There may be some need for fedora-release still, perhaps from third party packages. I am not sure if redhat-releases version would be needed by things other than yum and python-imgcreate.
It's possible that the livecd-creator issue with the yum change is different than the one seen with yum. I tried changing the reference to system-release and things were still broken. This needs some more investigation.
This bug is actually caused by a change to the second argument of yum.config._getsysver . It is now a list of strings instead of a string. It also turns out that not using versions in provides will result in the version of the package being used, which is what we want and seems the simplest way to fix things.
I have committed a fix to master and f10-branch. Brian, is there any reason I shouldn't do new builds for using these two branches? Would this also be a good time to create f20-branch?
*** Bug 1048058 has been marked as a duplicate of this bug. ***
livecd-tools-20.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/livecd-tools-20.3-1.fc20
livecd-tools-19.8-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/livecd-tools-19.8-1.fc19
Package livecd-tools-20.3-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing livecd-tools-20.3-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0493/livecd-tools-20.3-1.fc20 then log in and leave karma (feedback).
I tested using su -c 'yum update --enablerepo=updates-testing livecd-tools-20.3-1.fc20' for livecd-tools, and removed the --releasevars option. Changes appears to work.
livecd-tools-20.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
livecd-tools-19.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
I have tested my builds on both F19, and F20 they produce good ISOs. thanks all