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}
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
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
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.
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@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
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.
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@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
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. :)
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@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]