Bug 143138 - yum error for extras, %{epoch} not a number.
yum error for extras, %{epoch} not a number.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-16 14:49 EST by Brian Millett
Modified: 2014-01-21 17:50 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-19 02:19:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Millett 2004-12-16 14:49:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041212 Firefox/1.0

Description of problem:
Well, this is more likely a bug in the repo for pre-extras, in the
primary.xml.gz.....pickle.

Trying to do a yum update results in this error:
--> Running transaction check
--> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for package:
aalib-devel
Traceback (most recent call last):
  File "/usr/bin/yum", line 7, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 104, in main
    (result, resultmsgs) = base.buildTransaction()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 219,
in buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 187,
in resolveDeps
    (checkdep, missing, conflict, errormsgs) = self._processReq(dep)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 271,
in _processReq
    CheckDeps, missingdep =
self._requiringFromTransaction(requiringPkg, requirementTuple, errormsgs)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 420,
in _requiringFromTransaction
    provSack = self.whatProvides(needname, needflags, needversion)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 65, in
whatProvides
    (r_e, r_v, r_r) = rpmUtils.miscutils.stringToVersion(version)
  File "/usr/lib/python2.4/site-packages/rpmUtils/miscutils.py", line
307, in stringToVersion
    epoch = string.atol(verstring[:i])
  File "/usr/lib/python2.4/string.py", line 419, in atol
    return _long(s, base)
ValueError: invalid literal for long(): %{epoch}


Version-Release number of selected component (if applicable):
yum-2.1.12-1

How reproducible:
Always

Steps to Reproduce:
1. add pre-extras yum repository entry.
2. yum update
3. choose to update packages 
4. read error    

Actual Results:  read the description

Expected Results:  yum updates packages

Additional info:
Comment 1 Ivan Gyurdiev 2004-12-29 15:52:55 EST
I have the same problem with today's update:

Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package gcc-c++.i386 0:3.4.3-11 set to be updated
---> Package libgnat.i386 0:3.4.3-11 set to be updated
---> Package libf2c.i386 0:3.4.3-11 set to be updated
---> Package firefox.i386 0:1.0-8 set to be updated
---> Package libstdc++-devel.i386 0:3.4.3-11 set to be updated
---> Package libgcj.i386 0:3.4.3-11 set to be updated
---> Package rpmdb-fedora.i386 1:4-0.20041229 set to be updated
---> Package libobjc.i386 0:3.4.3-11 set to be updated
---> Package libstdc++.i386 0:3.4.3-11 set to be updated
---> Package gcc-gnat.i386 0:3.4.3-11 set to be updated
---> Package selinux-policy-targeted.noarch 0:1.19.15-11 set to be updated
---> Package gcc-objc.i386 0:3.4.3-11 set to be updated
---> Package libgcc.i386 0:3.4.3-11 set to be updated
---> Package libselinux-devel.i386 0:1.19.3-3 set to be updated
---> Package cpp.i386 0:3.4.3-11 set to be updated
---> Package gaim.i386 1:1.1.1-1 set to be updated
---> Package libgcj-devel.i386 0:3.4.3-11 set to be updated
---> Package libselinux.i386 0:1.19.3-3 set to be updated
---> Package gcc-java.i386 0:3.4.3-11 set to be updated
---> Package gcc-g77.i386 0:3.4.3-11 set to be updated
---> Package gcc.i386 0:3.4.3-11 set to be updated
--> Running transaction check
--> Processing Dependency: libselinux = %{epoch}:1.19.3-3 for package:
libselinux-devel
Traceback (most recent call last):
  File "/usr/bin/yum", line 7, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 104, in main
    (result, resultmsgs) = base.buildTransaction()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 219,
in buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 187,
in resolveDeps
    (checkdep, missing, conflict, errormsgs) = self._processReq(dep)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 271,
in _processReq
    CheckDeps, missingdep =
self._requiringFromTransaction(requiringPkg, requirementTuple, errormsgs)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 420,
in _requiringFromTransaction
    provSack = self.whatProvides(needname, needflags, needversion)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 65, in
whatProvides
    (r_e, r_v, r_r) = rpmUtils.miscutils.stringToVersion(version)
  File "/usr/lib/python2.4/site-packages/rpmUtils/miscutils.py", line
307, in stringToVersion
    epoch = string.atol(verstring[:i])
  File "/usr/lib/python2.4/string.py", line 419, in atol
    return _long(s, base)
ValueError: invalid literal for long(): %{epoch}
Comment 2 Ivan Gyurdiev 2004-12-29 15:55:10 EST
It's also interesting that after this error every second yum update
fails to find the packages from -devel to update. 

The first yum update downloaded all of the above + xine, then failed.
The second upgraded xine from livna.org and that's all.
The third tried to update -devel and failed.
The fourth said no updates.
The fifth tried to update -devel and failed.
The sixth said no updates.

etc..
Comment 3 Seth Vidal 2004-12-29 16:04:37 EST
comment #1: yes - it's a problem in the selinux package - and the
problem causing the traceback has been fixed in yum cvs

comment #2: the problem you're citing is unrelated. That is only a
problem of mirrors in the mirrorlist being out of sync.

Note You need to log in before you can comment on or make changes to this bug.