No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr'
Hi, I use updated fedora 7 what I could do ?
pungi -c /etc/pungi/f7-everything.i386 stops width :
INFO:pypungi.pungi:Running /usr/lib/anaconda-runtime/pkgorder /srv/pungi/f7/7/Everything/i386/os i386 Fedora ERROR:pypungi.pungi:Got an error from /usr/lib/anaconda-runtime/pkgorder ERROR:pypungi.pungi:Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 169, in <module> addGroups(ds, ["core", "base", "text-internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 105, in addGroups processTransaction(ds) File "/usr/lib/anaconda-runtime/pkgorder", line 77, in processTransaction ds.populateTs(keepold=0) File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 201, in populateTs self.downloadHeader(txmbr.po) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 863, in downloadHeader cache=repo.http_caching != 'none', File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 599, in getHeader cache=cache, File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 567, in _getFile http_headers=headers, File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 915, in retryfunc fo._do_grab() File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab else: new_fo = open(self.filename, 'wb') IOError: [Errno 2] No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr'
Thanks,
yap , pungi -P stops with message above others stages works including SplitTree stage and CreateISO.
Anything that I can test ? thanks,
On Wed, 2007-07-11 at 21:16 +0100, Sergio Monteiro Basto wrote:
Hi, I use updated fedora 7 what I could do ?
pungi -c /etc/pungi/f7-everything.i386 stops width :
INFO:pypungi.pungi:Running /usr/lib/anaconda-runtime/pkgorder /srv/pungi/f7/7/Everything/i386/os i386 Fedora ERROR:pypungi.pungi:Got an error from /usr/lib/anaconda-runtime/pkgorder ERROR:pypungi.pungi:Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 169, in <module> addGroups(ds, ["core", "base", "text-internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 105, in addGroups processTransaction(ds) File "/usr/lib/anaconda-runtime/pkgorder", line 77, in processTransaction ds.populateTs(keepold=0) File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 201, in populateTs self.downloadHeader(txmbr.po) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 863, in downloadHeader cache=repo.http_caching != 'none', File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 599, in getHeader cache=cache, File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 567, in _getFile http_headers=headers, File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 915, in retryfunc fo._do_grab() File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab else: new_fo = open(self.filename, 'wb') IOError: [Errno 2] No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr'
Thanks,
Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
On Fri, 13 Jul 2007 14:05:25 +0100 Sergio Monteiro Basto sergio@sergiomb.no-ip.org wrote:
yap , pungi -P stops with message above others stages works including SplitTree stage and CreateISO.
Sounds like pkgorder is busted in some way.
Anything that I can test ?
Well, we'll probably have to find out why pkgorder is busted and either work around it or fix it. Most likely we'll have to work around it since pkgorder is in anaconda and that doesn't really get updates.
On Fri, 13 Jul 2007, Jesse Keating wrote:
On Fri, 13 Jul 2007 14:05:25 +0100 Sergio Monteiro Basto sergio@sergiomb.no-ip.org wrote:
yap , pungi -P stops with message above others stages works including SplitTree stage and CreateISO.
Sounds like pkgorder is busted in some way.
Anything that I can test ?
Well, we'll probably have to find out why pkgorder is busted and either work around it or fix it. Most likely we'll have to work around it since pkgorder is in anaconda and that doesn't really get updates.
Could it be the latest yum? I got a report of a similar error when trying to install. I reverted yum, and am waiting for a report.
HTH.
On Fri, 13 Jul 2007 16:25:06 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
Could it be the latest yum? I got a report of a similar errorwhen trying to install. I reverted yum, and am waiting for a report.
It very well could be yum. Please let me know if things work better with the older yum.
On Fri, 13 Jul 2007, Jesse Keating wrote:
On Fri, 13 Jul 2007 16:25:06 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
Could it be the latest yum? I got a report of a similar errorwhen trying to install. I reverted yum, and am waiting for a report.
It very well could be yum. Please let me know if things work better with the older yum.
They seem to. I've now had two separate reports of success.
HTH.
On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
They seem to. I've now had two separate reports of success.
Interesting. Ok, now I'll have to see what changed in yum api to leave pkgorder behind.
Jesse Keating wrote:
On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
They seem to. I've now had two separate reports of success.
Interesting. Ok, now I'll have to see what changed in yum api to leave pkgorder behind.
I've heard yum does not create the header(s) directory / files anymore.
Kind regards,
Jeroen van Meeuwen -kanarip
On Sat, 2007-07-14 at 22:13 -0400, Jesse Keating wrote:
On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
They seem to. I've now had two separate reports of success.
Interesting. Ok, now I'll have to see what changed in yum api to leave pkgorder behind.
yep I confirm too
rpm -Uvh yum-3.2.0-1.fc7.noarch.rpm --oldpackage have solved the problem !
and yes yum-3.2.1 don't generate any headers files but yum-3.2.0 does .
thanks,
On Mon, 16 Jul 2007 16:34:58 +0100 Sergio Monteiro Basto sergio@sergiomb.no-ip.org wrote:
yep I confirm too
rpm -Uvh yum-3.2.0-1.fc7.noarch.rpm --oldpackage have solved the problem !
and yes yum-3.2.1 don't generate any headers files but yum-3.2.0 does .
Seth has helped us track this down to a change in the yum api. We're testing a fix now that will create the headers directory if headers are asked for, which is a work around until such time as nothing requests the headers (if possible). An updated yum will fix this issue.
On Mon, 16 Jul 2007 11:43:15 -0400 Jesse Keating jkeating@redhat.com wrote:
Seth has helped us track this down to a change in the yum api. We're testing a fix now that will create the headers directory if headers are asked for, which is a work around until such time as nothing requests the headers (if possible). An updated yum will fix this issue.
It has been clarified to me that this wasn't an API change, instead a function change.
On Mon, 16 Jul 2007, Jesse Keating wrote:
It has been clarified to me that this wasn't an API change, instead a function change.
I wonder if this is better fixed in Anaconda. I'm aware of the policy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited.
On Mon, 16 Jul 2007 10:05:11 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wacker@octothorp.org wrote:
I wonder if this is better fixed in Anaconda. I'm aware of thepolicy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited.
In reality, this is something that should have been in yum anyway, basically ensure that the headers directory exists if yum is being asked for headers.
As for updating anaconda, well, there are only so many work hours in the day, and so much that we want to accomplish for the next release. Spending time on re-releasing stuff for the current release just takes time away from the next release. Most anaconda issues can be worked around in various ways so that an update won't be necessary.
On Mon, 16 Jul 2007, Jesse Keating wrote:
In reality, this is something that should have been in yum anyway, basically ensure that the headers directory exists if yum is being asked for headers.
As for updating anaconda, well, there are only so many work hours in the day, and so much that we want to accomplish for the next release. Spending time on re-releasing stuff for the current release just takes time away from the next release. Most anaconda issues can be worked around in various ways so that an update won't be necessary.
I can dig it. I've done a few work-arounds for Anaconda locally in my time.
Thanks for all the hard work. I love Pungi!!
William F. Acker WB2FLW +1-303-722-7209 wrote:
On Mon, 16 Jul 2007, Jesse Keating wrote:
It has been clarified to me that this wasn't an API change, instead a function change.
I wonder if this is better fixed in Anaconda. I'm aware of thepolicy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited.
If I understand correctly the fix is in anaconda's development release.
Kind regards,
Jeroen van Meeuwen -kanarip
On Mon, 16 Jul 2007, Jeroen van Meeuwen wrote:
If I understand correctly the fix is in anaconda's development release.
Kind regards,
Does anyone know if the version now in development will still install Moonshine?
On Mon, Jul 16, 2007 at 10:42:49PM +0200, Jeroen van Meeuwen wrote:
William F. Acker WB2FLW +1-303-722-7209 wrote:
I wonder if this is better fixed in Anaconda. I'm aware of thepolicy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited.
If I understand correctly the fix is in anaconda's development release.
What version and/or what is the fix?
I see the same problem in RHEL 5.1, where the new yum and pkgorder won't work together, with the same symptoms as discussed in this thread.
FWIW: in RHEL 5.1 there is another pkgorder problem that was already fixed in F7:
- self.repos.populateSack(with='filelists') + self.repos.populateSack('enabled', 'filelists')
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jos Vos wrote:
On Mon, Jul 16, 2007 at 10:42:49PM +0200, Jeroen van Meeuwen wrote:
William F. Acker WB2FLW +1-303-722-7209 wrote:
I wonder if this is better fixed in Anaconda. I'm aware of thepolicy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited.
If I understand correctly the fix is in anaconda's development release.
What version and/or what is the fix?
I see the same problem in RHEL 5.1, where the new yum and pkgorder won't work together, with the same symptoms as discussed in this thread.
FWIW: in RHEL 5.1 there is another pkgorder problem that was already fixed in F7:
self.repos.populateSack(with='filelists')
self.repos.populateSack('enabled', 'filelists')
The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't.
- -- Kind regards,
Jeroen van Meeuwen - -kanarip
- -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
Hi Jeroen,
On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote:
The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't.
Correct, but I saw in this thread Jesse saying that the problem was identified and you mentioned that the fix should be in anaconda's development version.
Anyway, I seem to have solved it at least for my RHEL environment given Jesse's hint for creating a headers directory: in my pkgorder I now added at the end of setup():
os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755)
which seems to solve the problem.
I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), but maybe that's because in the meantime yum is fixed (or better: behaving differently, as I don't know the yum API well enough to say that yum was wrong). I want to stick to yum 3.2.1, as long as this the proposed version for RHEL 5.1
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jos Vos wrote:
Hi Jeroen,
On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote:
The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't.
Correct, but I saw in this thread Jesse saying that the problem was identified and you mentioned that the fix should be in anaconda's development version.
Anyway, I seem to have solved it at least for my RHEL environment given Jesse's hint for creating a headers directory: in my pkgorder I now added at the end of setup():
os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755)
which seems to solve the problem.
I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), but maybe that's because in the meantime yum is fixed (or better: behaving differently, as I don't know the yum API well enough to say that yum was wrong). I want to stick to yum 3.2.1, as long as this the proposed version for RHEL 5.1
Cheers,
The problem was with yum not creating the headers/ directory anymore in yum-3.2.1, and although Seth tried to fix that in yum-3.2.2, it didn't do the trick. But yeah, if you create the directory at some point manually, it should fix stuff.
- -- Kind regards,
Jeroen van Meeuwen - -kanarip
- -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
2007/8/26, Jeroen van Meeuwen kanarip@kanarip.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jos Vos wrote:
Hi Jeroen,
On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote:
The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't.
Correct, but I saw in this thread Jesse saying that the problem was identified and you mentioned that the fix should be in anaconda's development version.
Anyway, I seem to have solved it at least for my RHEL environment given Jesse's hint for creating a headers directory: in my pkgorder I now added at the end of setup():
os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755)
which seems to solve the problem.
I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), but maybe that's because in the meantime yum is fixed (or better: behaving differently, as I don't know the yum API well enough to say that yum was wrong). I want to stick to yum 3.2.1, as long as this the proposed version for RHEL 5.1
Cheers,
The problem was with yum not creating the headers/ directory anymore in yum-3.2.1, and although Seth tried to fix that in yum-3.2.2, it didn't do the trick. But yeah, if you create the directory at some point manually, it should fix stuff.
Kind regards,
Jeroen van Meeuwen
- -kanarip
I made yum-3.2.4-2 based fix file. yum-3.2.1/3.2.2/3.2.4 have same problem. New ISOs made that include New RPMS files at pungi or revisor, but during installation process exception error occured.
Apply patch to yum/yumRepo.py
--- yum/yumRepo.py 2007-08-29 02:38:39.000000000 +0900 +++ yum/yumRepo.py~ 2007-09-07 12:54:14.000000000 +0900 @@ -455,7 +455,7 @@ cookie = self.cachedir + '/' + self.metadata_cookie_fn self.setAttribute('metadata_cookie', cookie)
- for dir in [self.cachedir, self.pkgdir]: + for dir in [self.cachedir, self.hdrdir, self.pkgdir]: if self.cache == 0: if os.path.exists(dir) and os.path.isdir(dir): continue
please apply and re-make yum packages (ex: yum-3.2.4-2 -> yum-3.2.4-3) And new ISOs made at pungi or revisor. You will successfully install at new ISOs.
best regard.
pochi_ken wrote:
please apply and re-make yum packages (ex: yum-3.2.4-2 -> yum-3.2.4-3) And new ISOs made at pungi or revisor. You will successfully install at new ISOs.
best regard.
You cannot just go an spin ISOs even if this yum bug gets solved in F7 properly.
Another "fix" in RPM though causes anaconda to go flat on it's face so you cannot compose images without also excluding the rpm* updated packages.
RPM 4.4.2.1-1.fc7 does not allow packages to be added to the transaction more then once; it throws an exception and although that exception may be caught and handled appropriately, anaconda-runtime's pkgorder doesn't do so (but does add packages to the transaction multiple times).
This (for F7) cannot be fixed, as anaconda and anaconda-runtime will not get updated in between releases.
Revisor has a way to work around this, but I'm not amused at all we had to find such work around in the first place.
Apparently, the packages which anaconda depends upon can just break that compatibility (one way or the other) and get away with it, posing anyone of us for a number of challenges.
My complete list of excluded updates now is:
exclude=yum yum-updatesd rpm-build rpm-libs rpm rpm-devel rpm-python
On Fri, 2007-09-07 at 16:35 +0900, pochi_ken wrote:
I made yum-3.2.4-2 based fix file. yum-3.2.1/3.2.2/3.2.4 have same problem. New ISOs made that include New RPMS files at pungi or revisor, but during installation process exception error occured.
Apply patch to yum/yumRepo.py
--- yum/yumRepo.py 2007-08-29 02:38:39.000000000 +0900 +++ yum/yumRepo.py~ 2007-09-07 12:54:14.000000000 +0900 @@ -455,7 +455,7 @@ cookie = self.cachedir + '/' + self.metadata_cookie_fn self.setAttribute('metadata_cookie', cookie)
for dir in [self.cachedir, self.pkgdir]:
for dir in [self.cachedir, self.hdrdir, self.pkgdir]: if self.cache == 0: if os.path.exists(dir) and os.path.isdir(dir): continueplease apply and re-make yum packages (ex: yum-3.2.4-2 -> yum-3.2.4-3) And new ISOs made at pungi or revisor. You will successfully install at new ISOs.
best regard.
Hi,
Nice trick :) thanks, may be this patch should be upstreamed into yum. Well I don't try the new ISOs yet... but looks the right way to do it.
Thanks,
On Sat, 2007-08-25 at 23:55 +0200, Jos Vos wrote:
Hi Jeroen,
On Sat, Aug 25, 2007 at 11:15:28PM +0200, Jeroen van Meeuwen wrote:
The key item here may be yum. We've seen similar issues before. The system's yum version doesn't seem to matter, but the one pulled into the tree does. 3.2.0 works, 3.2.1 and 3.2.2 don't.
Correct, but I saw in this thread Jesse saying that the problem was identified and you mentioned that the fix should be in anaconda's development version.
Anyway, I seem to have solved it at least for my RHEL environment given Jesse's hint for creating a headers directory: in my pkgorder I now added at the end of setup():
os.mkdir(os.path.join(cachedir, 'anaconda', 'headers'), 0755)
which seems to solve the problem.
I don't see anything fixing the problem in anaconda-11.3.0.19 (devel), but maybe that's because in the meantime yum is fixed (or better: behaving differently, as I don't know the yum API well enough to say that yum was wrong). I want to stick to yum 3.2.1, as long as this the proposed version for RHEL 5.1
Just confirming that this patch on anaconda package solve the build problem.
but trying installing this isos will be or not a problem anaconda don't have this patch ?
Thanks in advance
buildsys@lists.fedoraproject.org
-
Jeroen van Meeuwen -
Jesse Keating -
Jos Vos -
pochi_ken -
Sergio Monteiro Basto -
William F. Acker WB2FLW +1 303 722 7209