yum error of extras

[Brian Millett]

Seth, having added
[pre-extras]
name=Pre Extras
baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
enabled=1
gpgcheck=1

I looked to see what was available, then tried to update.

Results follow:
.....
--> 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}

-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
[phone]           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn

[seth vidal]

On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  Seth, having added
>  [pre-extras]
>  name=Pre Extras
>  baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
>  enabled=1
>  gpgcheck=1
>  
>  I looked to see what was available, then tried to update.
>  
>  Results follow:
>  .....
>  --> 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}
>   
Looks like garbage in the epoch field of aalib.

I'll take a look at both yum and the pkg.

could you open a bug on this?

Thanks
-sv

[Brian Millett]

>  On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
> > Seth, having added
> > [pre-extras]
> > name=Pre Extras
> > baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
> > enabled=1
> > gpgcheck=1
> >
> > I looked to see what was available, then tried to update.
> >
> > Results follow:
> > .....
> > --> 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}
> >
>
>  Looks like garbage in the epoch field of aalib.
>
>  I'll take a look at both yum and the pkg.
>
>  could you open a bug on this? 
Done.  #143138



-- 
Brian Millett
Enterprise Consulting Group  "Shifts in paradigms
[phone]           often cause nose bleeds."
bpmATec-groupDOTcom                     Greg Glenn

[Michael Schwendt]

On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:

>  On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  > Seth, having added
>  > [pre-extras]
>  > name=Pre Extras
>  > baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
>  > enabled=1
>  > gpgcheck=1
>  > 
>  > I looked to see what was available, then tried to update.
>  > 
>  > Results follow:
>  > .....
>  > --> Running transaction check
>  > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for package:
>  > aalib-devel 
>  > ValueError: invalid literal for long(): %{epoch}
>  > 
>  
>  Looks like garbage in the epoch field of aalib.
>  
>  I'll take a look at both yum and the pkg.
>  
>  could you open a bug on this? 
Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
%epoch still used. Fixed.

[seth vidal]

>  Not necessary. Ran into it, too. Spec was bad. Epoch was dropped,
> but
>  %epoch still used. Fixed. 
Well it sorta is necessary. I need to take a look and figure out why yum
is tracing back. It really shouldn't be. It should be complaining
nicely :)

-sv

[Dag Wieers]

On Thu, 16 Dec 2004, Michael Schwendt wrote:
>  On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:
>  > On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  >
>  > > Results follow:
>  > > .....
>  > > --> Running transaction check
>  > > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for package:
>  > > aalib-devel
>  > > ValueError: invalid literal for long(): %{epoch}
>  > 
>  > Looks like garbage in the epoch field of aalib.
>  > 
>  > I'll take a look at both yum and the pkg.
>  > 
>  > could you open a bug on this?
>  
>  Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
>  %epoch still used. Fixed. 
Ah, sweet irony.

http://www.fedora.us/pipermail/fedora-devel/2003-April/000795.html
http://www.fedora.us/pipermail/fedora-devel/2003-May/001396.html
http://www.fedora.us/pipermail/fedora-devel/2003-June/001422.html

Especially, that last thread indicates almost everyone was against 
mandatory epochs.

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

[Michael Schwendt]

On Fri, 17 Dec 2004 10:13:29 +0100 (CET), Dag Wieers wrote:

>  On Thu, 16 Dec 2004, Michael Schwendt wrote:
>  > On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:
>  > > On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  > >
>  > > > Results follow:
>  > > > .....
>  > > > --> Running transaction check
>  > > > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for package:
>  > > > aalib-devel
>  > > > ValueError: invalid literal for long(): %{epoch}
>  > > 
>  > > Looks like garbage in the epoch field of aalib.
>  > > 
>  > > I'll take a look at both yum and the pkg.
>  > > 
>  > > could you open a bug on this?
>  > 
>  > Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
>  > %epoch still used. Fixed.
>  
>  Ah, sweet irony. 
No irony here, just an incomplete change and commit by somebody.

[Dag Wieers]

On Fri, 17 Dec 2004, Michael Schwendt wrote:

>  On Fri, 17 Dec 2004 10:13:29 +0100 (CET), Dag Wieers wrote:
>  
>  > On Thu, 16 Dec 2004, Michael Schwendt wrote:
>  > > On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:
>  > > > On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  > > >
>  > > > > Results follow:
>  > > > > .....
>  > > > > --> Running transaction check
>  > > > > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for
> package:
>  > > > > aalib-devel
>  > > > > ValueError: invalid literal for long(): %{epoch}
>  > > > 
>  > > > Looks like garbage in the epoch field of aalib.
>  > > > 
>  > > > I'll take a look at both yum and the pkg.
>  > > > 
>  > > > could you open a bug on this?
>  > > 
>  > > Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
>  > > %epoch still used. Fixed.
>  > 
>  > Ah, sweet irony.
>  
>  No irony here, just an incomplete change and commit by somebody. 
The irony is that it still bites almost 2 years after nobody wanted to 
have it in the first place and it still ended up in the official policy 
because of a misinterpreted JBJ comment. Simplicity and implicitly.

http://www.fedora.us/pipermail/fedora-devel/2003-April/000795.html
http://www.fedora.us/pipermail/fedora-devel/2003-May/001396.html
http://www.fedora.us/pipermail/fedora-devel/2003-June/001422.html

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

[Michael Schwendt]

On Fri, 17 Dec 2004 13:58:16 +0100 (CET), Dag Wieers wrote:

>  On Fri, 17 Dec 2004, Michael Schwendt wrote:
>  
>  > On Fri, 17 Dec 2004 10:13:29 +0100 (CET), Dag Wieers wrote:
>  > 
>  > > On Thu, 16 Dec 2004, Michael Schwendt wrote:
>  > > > On Thu, 16 Dec 2004 14:38:41 -0500, seth vidal wrote:
>  > > > > On Thu, 2004-12-16 at 13:28 -0600, Brian Millett wrote:
>  > > > >
>  > > > > > Results follow:
>  > > > > > .....
>  > > > > > --> Running transaction check
>  > > > > > --> Processing Dependency: aalib = %{epoch}:1.4.0-0.rc5.2 for
> package:
>  > > > > > aalib-devel
>  > > > > > ValueError: invalid literal for long(): %{epoch}
>  > > > > 
>  > > > > Looks like garbage in the epoch field of aalib.
>  > > > > 
>  > > > > I'll take a look at both yum and the pkg.
>  > > > > 
>  > > > > could you open a bug on this?
>  > > > 
>  > > > Not necessary. Ran into it, too. Spec was bad. Epoch was dropped, but
>  > > > %epoch still used. Fixed.
>  > > 
>  > > Ah, sweet irony.
>  > 
>  > No irony here, just an incomplete change and commit by somebody.
>  
>  The irony is that it still bites almost 2 years after nobody wanted to 
>  have it in the first place and it still ended up in the official policy 
>  because of a misinterpreted JBJ comment. Simplicity and implicitly. 
No, no, no. It does not. aalib and aalib-devel were working fine.
Just imagine that the package had had "Epoch: 1" already.

Look at the CVS diff between revision 1.3 and 1.4. Matthias dropped
"Epoch: 0" while doing a version bump, but forgot to drop %epoch in
the rest of the same file. The package broke itself.

This has nothing to do with old discussions on explicit Epoch.

Btw, there are people who think it is a mistake to drop "Epoch: 0"
again. So until there will be a policy about this, you will see
packages which keep the explicit Epoch and others where packagers drop
it. What a weird world we live in. :)

[Dag Wieers]

On Fri, 17 Dec 2004, Michael Schwendt wrote:

>  Btw, there are people who think it is a mistake to drop "Epoch:
> 0"
>  again. So until there will be a policy about this, you will see
>  packages which keep the explicit Epoch and others where packagers drop
>  it. What a weird world we live in. :) 
Well, having a policy where the authority can decide what his package 
looks like is not a bad policy to work towards consensus. That's how it 
worked with us, whatever was not agreed upon was decided to leave it to 
the packager's taste. Some of those differences automatically fade away 
after a little while.

--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]