Hi, I have again worked on yum 3.2.8 for Centos 4 today, after a long time. The result is backported package yum-3.2.8-9.el4.hrb.2.1.5 which is the upgrade of yum-3.2.8-9.el4.hrb.2.1.3 I've been using smoothly for quite a long time.
Packages are in testing repos: http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/repodata/ http://fs12.vsb.cz/hrb33/el4/hrb/testing/x86_64/repodata/
I'd like to ask for QA tests. This patched version passes all the internal yum tests (aka 'make test').
Regards, David Hrbáč
On Thu, 2009-07-09 at 17:18 +0200, David Hrbáč wrote:
Hi, I have again worked on yum 3.2.8 for Centos 4 today, after a long time. The result is backported package yum-3.2.8-9.el4.hrb.2.1.5 which is the upgrade of yum-3.2.8-9.el4.hrb.2.1.3 I've been using smoothly for quite a long time.
Packages are in testing repos: http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/repodata/ http://fs12.vsb.cz/hrb33/el4/hrb/testing/x86_64/repodata/
I'd like to ask for QA tests. This patched version passes all the internal yum tests (aka 'make test').
David,
Thx for the work. I tried a test today and have a problem.
What I did was import your GPG.KEY file, manually added a .repo, and ran yum with a --disablerepo=* --enablerepo=hrb.
All seemed to go well.
I then did the same yum update command, but enabled the rpmforge repo to try and pick up a new rtorrent moddule to test for Dag.
Results were a message saying "There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: No module named op. Please install a package which provides this module, or verify that the module is installed correctly".
Since I did my steps manually and am not real handy with this stuff, how should I proceed to correct this?
Thanks,
William L. Maltby napsal(a):
David,
Thx for the work. I tried a test today and have a problem.
What I did was import your GPG.KEY file, manually added a .repo, and ran yum with a --disablerepo=* --enablerepo=hrb.
All seemed to go well.
I then did the same yum update command, but enabled the rpmforge repo to try and pick up a new rtorrent moddule to test for Dag.
Results were a message saying "There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: No module named op. Please install a package which provides this module, or verify that the module is installed correctly".
Since I did my steps manually and am not real handy with this stuff, how should I proceed to correct this?
Thanks,
William, repo has installer http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/hrb-release.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/x86_64/repoview/hrb-release.html
one installed disable stable repo. 1) what version of yum are you running? 2) what plugins?
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch. Regards, David
On Wed, 2009-07-22 at 20:15 +0200, David Hrbáč wrote:
William L. Maltby napsal(a):
David,
Thx for the work. I tried a test today and have a problem.
What I did was import your GPG.KEY file, manually added a .repo, and ran yum with a --disablerepo=* --enablerepo=hrb.
All seemed to go well.
I then did the same yum update command, but enabled the rpmforge repo to try and pick up a new rtorrent moddule to test for Dag.
Results were a message saying "There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: No module named op. Please install a package which provides this module, or verify that the module is installed correctly".
Since I did my steps manually and am not real handy with this stuff, how should I proceed to correct this?
Thanks,
William, repo has installer http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/hrb-release.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/x86_64/repoview/hrb-release.html
Good. I'll run the i386 one now.
one installed disable stable repo.
- what version of yum are you running?
Well, that machine is not used for much so I didn't worry about keeping backup/previous version stuff. It was a full updated CentOS 4.7. So whatever fully-updated yum is what I had.
- what plugins?
All the plugins that come standard.
I know that may not be that helpful, but I didn't have a lot of time and the machine wasn't critical, so I let things slide.
Now it has yum-utils-1.1.16-13.el4.hrb.1 yum-plugin-fastestmirror-0.2.4-3.c4 yum-metadata-parser-1.1.2-12.el4.hrb.1 yum-plugin-priorities-0.0.7-2.c4 (enabled in all repos) yum-fastestmirror-1.1.16-13.el4.hrb.1 yum-plugin-protectbase-1.1-1.c4 (disabled in all repos)
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch.
Ok. That yum is the one I picked up: yum-3.2.19-18.el4.hrb.
Do I need to regress to stock from here or is there a quick and dirty manual fix I can apply? I will run the relese file regardless.
Regards, David
<snip>
On Wed, 2009-07-22 at 20:15 +0200, David Hrbáč wrote:
<snip> repo has installer http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/hrb-release.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/x86_64/repoview/hrb-release.html
I only see ... hrb-release-0.1.3.el4.hrb. Is that the correct one?
I was attempting to test for you since I saw that in the past things sometimes stayed in testing repos for a *long* time.
Should I not have been doing this? If not, shouldn't I stick with the CentOS stock stuff? I do want to help test the little bit I can, so I guess once I re-establish a working yum, I should wait for a notification of another test version and then use that one?
one installed disable stable repo.
- what version of yum are you running?
- what plugins?
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch. Regards, David
<snip sig stuff>
On Wed, 2009-07-22 at 20:15 +0200, David Hrbáč wrote:
<snip>
William, repo has installer http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/hrb-release.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/x86_64/repoview/hrb-release.html
one installed disable stable repo.
- what version of yum are you running?
- what plugins?
I manually restored the box-stock yum. If you still need the version information, just let me know.
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch.
Until I hear otherwise from you, as to if I should be running your stable and why, I'll keep the stock C4 stuff installed. When you need another version tested, just post and I'll be glad to try again.
Regards, David
<snip sig stuff>
Dne 22.7.2009 22:27, William L. Maltby napsal(a):
Until I hear otherwise from you, as to if I should be running your stable and why, I'll keep the stock C4 stuff installed. When you need another version tested, just post and I'll be glad to try again.
Regards, David
<snip sig stuff>
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/repoview/yum.html http://fs12.vsb.cz/hrb33/el4/hrb/testing/x86_64/repoview/yum.html
Regards, David Hrbáč
On Mon, 2010-01-25 at 09:23 +0100, David Hrbáč wrote:
Dne 22.7.2009 22:27, William L. Maltby napsal(a):
Until I hear otherwise from you, as to if I should be running your stable and why, I'll keep the stock C4 stuff installed. When you need another version tested, just post and I'll be glad to try again.
Regards, David
<snip sig stuff>
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/repoview/yum.html http://fs12.vsb.cz/hrb33/el4/hrb/testing/x86_64/repoview/yum.html
I'll be glad to test. I'll fire up the C4 later today and install the stuff. Do I need to import a key, set up repos or anything? I've forgotten what I did before, but I can track back and discover it.
Regards, David Hrbáč
<snip sig stuff>
Dne 25.1.2010 17:46, William L. Maltby napsal(a):
I'll be glad to test. I'll fire up the C4 later today and install the stuff. Do I need to import a key, set up repos or anything? I've forgotten what I did before, but I can track back and discover it.
William, sorry to respond today, we had security incident, so I had no time :o). 1. get http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/hrb-release-0.1-4.el4.hrb.i386.... for 64bit replace i386 with x84_64 http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/hrb-release.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/x86_64/repoview/hrb-release.html 2. disable hrb repo in /etc/yum.repos.d/hrb.repo 3. leave hrb-testing disabled too 4. run yum check-update --enablerepo=hrb-test 5. run yum update yum --enablerepo=hrb-test
Regards, David
On Wed, 2010-01-27 at 08:59 +0100, David Hrbáč wrote:
Dne 27.1.2010 8:54, David Hrbáč napsal(a):
- run yum check-update --enablerepo=hrb-test
- run yum update yum --enablerepo=hrb-test
Sorry, should be: 4. run yum check-update --enablerepo=hrb-testing 5. run yum update yum --enablerepo=hrb-testing
I thought I got it all right, but still have problems. I must apologize in that other matters keep me from digging as deep as I normally would, so I'm in "just do it best I can and report" mode.
Current setup is this.
yum-updateonboot-0.5-2.el4.centos yum-metadata-parser-1.1.2-12.el4.hrb.1 yum-fastestmirror-1.1.16-13.el4.hrb.1 yum-utils-1.1.16-13.el4.hrb.1 yum-plugin-priorities-0.0.7-2.c4 yumex-1.0.2-1.0.c4 yum-3.2.19-18.el4.hrb.6 yum-arch-2.2.2-1.el4.rf yum-plugin-protectbase-1.1-1.c4
Tried a simple "yum update glib*" and got this
# yum update glib* Loaded plugins: fastestmirror, installonlyn, priorities, protectbase /usr/lib/python2.3/site-packages/yum/plugins.py:465: DeprecationWarning: registerOpt() will go away in a future version of Yum. Please manipulate config.YumConf and config.RepoConf directly. DeprecationWarning) Loading mirror speeds from cached hostfile * fasttrack: ftp.linux.ncsu.edu * update: ftp.linux.ncsu.edu * rpmforge: fr2.rpmfind.net * base: www.gtlib.gatech.edu * addons: ftp.linux.ncsu.edu * hrb-stable: fs12.vsb.cz * extras: ftp.linux.ncsu.edu 0 packages excluded due to repository protections 555 packages excluded due to repository priority protections Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package glibc-common.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc.i686 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-profile.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-devel.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-utils.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-headers.i386 0:2.3.4-2.43.el4_8.1 set to be updated --> Processing Dependency: glibc-devel = 2.3.4-2.43 for package: nptl-devel --> Running transaction check ---> Package nptl-devel.i686 0:2.3.4-2.43.el4_8.1 set to be updated --> Finished Dependency Resolution /usr/lib/yum-plugins/installonlyn.py:56: YumDeprecationWarning: getProvidesNames() will go away in a future version of Yum.
if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
Dependencies Resolved
================================================================================ Package Arch Version Repository Size ================================================================================Updating: glibc i686 2.3.4-2.43.el4_8.1 update 6.0 M glibc-common i386 2.3.4-2.43.el4_8.1 update 16 M glibc-devel i386 2.3.4-2.43.el4_8.1 update 1.9 M glibc-headers i386 2.3.4-2.43.el4_8.1 update 589 k glibc-profile i386 2.3.4-2.43.el4_8.1 update 1.1 M glibc-utils i386 2.3.4-2.43.el4_8.1 update 112 k nptl-devel i686 2.3.4-2.43.el4_8.1 update 935 k
Transaction Summary ================================================================================Install 0 Package(s) Update 7 Package(s) Remove 0 Package(s)
Total download size: 26 M Is this ok [y/N]: y Downloading Packages: Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 181, in main return_code = base.doTransaction() File "/usr/share/yum-cli/cli.py", line 391, in doTransaction problems = self.downloadPkgs(downloadpkgs, callback_total=self.download_callback_total_cb) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 1123, in downloadPkgs remote_pkgs.sort(mediasort) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 1072, in mediasort a = apo.getDiscNum() File "/usr/lib/python2.3/site-packages/yum/packages.py", line 586, in getDiscNum if self.basepath is None: File "/usr/lib/python2.3/site-packages/yum/sqlitesack.py", line 151, in __getattr__ (self.pkgId,)).fetchone() File "/usr/lib/python2.3/site-packages/yum/sqlitesack.py", line 123, in _sql_MD executeSQL(cur, sql, *args) File "/usr/lib/python2.3/site-packages/yum/sqlutils.py", line 150, in executeSQLPyFormat return cursor.execute(q, p) File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py", line 255, in execute _sqlite.DatabaseError: no such column: location_base
I had to C&P the error messages, so if there seems to be dupes, it's operator error.
Sorry I'm not able to be more thorough in my investigations before I post.
DH
<snip sig stuff>
Dne 28.1.2010 17:04, William L. Maltby napsal(a):
On Wed, 2010-01-27 at 08:59 +0100, David Hrbáč wrote:
Dne 27.1.2010 8:54, David Hrbáč napsal(a):
- run yum check-update --enablerepo=hrb-test
- run yum update yum --enablerepo=hrb-test
Sorry, should be: 4. run yum check-update --enablerepo=hrb-testing 5. run yum update yum --enablerepo=hrb-testing
I thought I got it all right, but still have problems. I must apologize in that other matters keep me from digging as deep as I normally would, so I'm in "just do it best I can and report" mode.
Current setup is this.
yum-updateonboot-0.5-2.el4.centos yum-metadata-parser-1.1.2-12.el4.hrb.1 yum-fastestmirror-1.1.16-13.el4.hrb.1 yum-utils-1.1.16-13.el4.hrb.1 yum-plugin-priorities-0.0.7-2.c4 yumex-1.0.2-1.0.c4 yum-3.2.19-18.el4.hrb.6 yum-arch-2.2.2-1.el4.rf yum-plugin-protectbase-1.1-1.c4
Tried a simple "yum update glib*" and got this
# yum update glib* Loaded plugins: fastestmirror, installonlyn, priorities, protectbase /usr/lib/python2.3/site-packages/yum/plugins.py:465: DeprecationWarning: registerOpt() will go away in a future version of Yum. Please manipulate config.YumConf and config.RepoConf directly. DeprecationWarning) Loading mirror speeds from cached hostfile
- fasttrack: ftp.linux.ncsu.edu
- update: ftp.linux.ncsu.edu
- rpmforge: fr2.rpmfind.net
- base: www.gtlib.gatech.edu
- addons: ftp.linux.ncsu.edu
- hrb-stable: fs12.vsb.cz
- extras: ftp.linux.ncsu.edu
0 packages excluded due to repository protections 555 packages excluded due to repository priority protections Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package glibc-common.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc.i686 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-profile.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-devel.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-utils.i386 0:2.3.4-2.43.el4_8.1 set to be updated ---> Package glibc-headers.i386 0:2.3.4-2.43.el4_8.1 set to be updated --> Processing Dependency: glibc-devel = 2.3.4-2.43 for package: nptl-devel --> Running transaction check ---> Package nptl-devel.i686 0:2.3.4-2.43.el4_8.1 set to be updated --> Finished Dependency Resolution /usr/lib/yum-plugins/installonlyn.py:56: YumDeprecationWarning: getProvidesNames() will go away in a future version of Yum.
if (m.name == instpkg or instpkg in m.po.getProvidesNames()) \
Dependencies Resolved
================================================================================ Package Arch Version Repository Size ================================================================================Updating: glibc i686 2.3.4-2.43.el4_8.1 update 6.0 M glibc-common i386 2.3.4-2.43.el4_8.1 update 16 M glibc-devel i386 2.3.4-2.43.el4_8.1 update 1.9 M glibc-headers i386 2.3.4-2.43.el4_8.1 update 589 k glibc-profile i386 2.3.4-2.43.el4_8.1 update 1.1 M glibc-utils i386 2.3.4-2.43.el4_8.1 update 112 k nptl-devel i686 2.3.4-2.43.el4_8.1 update 935 k
Transaction Summary ================================================================================Install 0 Package(s) Update 7 Package(s) Remove 0 Package(s)
Total download size: 26 M Is this ok [y/N]: y Downloading Packages: Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 181, in main return_code = base.doTransaction() File "/usr/share/yum-cli/cli.py", line 391, in doTransaction problems = self.downloadPkgs(downloadpkgs, callback_total=self.download_callback_total_cb) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 1123, in downloadPkgs remote_pkgs.sort(mediasort) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 1072, in mediasort a = apo.getDiscNum() File "/usr/lib/python2.3/site-packages/yum/packages.py", line 586, in getDiscNum if self.basepath is None: File "/usr/lib/python2.3/site-packages/yum/sqlitesack.py", line 151, in __getattr__ (self.pkgId,)).fetchone() File "/usr/lib/python2.3/site-packages/yum/sqlitesack.py", line 123, in _sql_MD executeSQL(cur, sql, *args) File "/usr/lib/python2.3/site-packages/yum/sqlutils.py", line 150, in executeSQLPyFormat return cursor.execute(q, p) File "/var/tmp/python-sqlite-root//usr/lib/python2.3/site-packages/sqlite/main.py", line 255, in execute _sqlite.DatabaseError: no such column: location_base
I had to C&P the error messages, so if there seems to be dupes, it's operator error.
Sorry I'm not able to be more thorough in my investigations before I post.
DH
<snip sig stuff>
Works, pretty well:Loaded plugins: fastestmirror, priorities, protect-packages, protectbase
[root@yumc4 ~]# yum check-update --enablerepo=hrb-testing --disablerepo=extras Loaded plugins: fastestmirror, priorities, protect-packages, protectbase Loading mirror speeds from cached hostfile * update: merlin.fit.vutbr.cz * base: merlin.fit.vutbr.cz * hrb-testing: fs12.vsb.cz * addons: merlin.fit.vutbr.cz * hrb-stable: fs12.vsb.cz 55 packages excluded due to repository protections [root@yumc4 ~]#
Do you have installonlyn plug-in installed? There's no such plug-in within this version. It's already included as a core feature. David Hrbáč
On Fri, 2010-01-29 at 12:41 +0100, David Hrbáč wrote:
<snip>
Works, pretty well:Loaded plugins: fastestmirror, priorities, protect-packages, protectbase
[root@yumc4 ~]# yum check-update --enablerepo=hrb-testing --disablerepo=extras Loaded plugins: fastestmirror, priorities, protect-packages, protectbase Loading mirror speeds from cached hostfile
- update: merlin.fit.vutbr.cz
- base: merlin.fit.vutbr.cz
- hrb-testing: fs12.vsb.cz
- addons: merlin.fit.vutbr.cz
- hrb-stable: fs12.vsb.cz
55 packages excluded due to repository protections [root@yumc4 ~]#
Do you have installonlyn plug-in installed? There's no such plug-in within this version. It's already included as a core feature.
Yes. But note that I disabled all the plugins, by editing their configuration files, for the prior test to make sure I was not introducing unexpected issues.
Are you saying that I need to leave those you mention enabled and disable the rest?
Installonlyn has a configuration file, but I don't see it as an rpm -q output. However, /usr/lib/yum-plugins/installonlyn.pvc exists, so it is installed. Should it be enabled, disabled or removed?
David Hrbáč
<snip>
Thanks,
Dne 29.1.2010 13:15, William L. Maltby napsal(a):
Yes. But note that I disabled all the plugins, by editing their configuration files, for the prior test to make sure I was not introducing unexpected issues.
Are you saying that I need to leave those you mention enabled and disable the rest?
Installonlyn has a configuration file, but I don't see it as an rpm -q output. However, /usr/lib/yum-plugins/installonlyn.pvc exists, so it is installed. Should it be enabled, disabled or removed?
Bill, [root@webmel4 ~]# ls /usr/lib/yum-plugins/ -al total 144 drwxr-xr-x 2 root root 4096 Jan 27 13:02 . drwxr-xr-x 55 root root 20480 Jan 27 04:02 .. -rw-r--r-- 1 root root 8674 Jul 13 2009 changelog.py -rw-r--r-- 1 root root 10215 Jul 13 2009 changelog.pyc -rw-r--r-- 1 root root 16865 Jul 13 2009 fastestmirror.py -rw-r--r-- 1 root root 18492 Jul 13 2009 fastestmirror.pyc -rw-r--r-- 1 root root 18130 Mar 5 2009 security.pyc -rw-r--r-- 1 root root 4808 Jul 9 2009 skip-broken.pyc -rw-r--r-- 1 root root 16928 Jul 13 2009 verify.pyc
There should be no installonlyn, nor instalonlyn.conf. David
On Fri, 2010-01-29 at 14:01 +0100, David Hrbáč wrote:
<sip>
Bill, [root@webmel4 ~]# ls /usr/lib/yum-plugins/ -al total 144 drwxr-xr-x 2 root root 4096 Jan 27 13:02 . drwxr-xr-x 55 root root 20480 Jan 27 04:02 .. -rw-r--r-- 1 root root 8674 Jul 13 2009 changelog.py -rw-r--r-- 1 root root 10215 Jul 13 2009 changelog.pyc -rw-r--r-- 1 root root 16865 Jul 13 2009 fastestmirror.py -rw-r--r-- 1 root root 18492 Jul 13 2009 fastestmirror.pyc -rw-r--r-- 1 root root 18130 Mar 5 2009 security.pyc -rw-r--r-- 1 root root 4808 Jul 9 2009 skip-broken.pyc -rw-r--r-- 1 root root 16928 Jul 13 2009 verify.pyc
There should be no installonlyn, nor instalonlyn.conf.
Ok. I'll make it look like that and do another.
Thanks!
David
<snip sig stuff>
On 01/25/2010 10:23 AM, David Hrbáč wrote:
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testin
I've installed those a couple of hours ago on a half-test half-production machine. So far, so good.
Manuel
Manuel Wolfshant wrote:
On 01/25/2010 10:23 AM, David Hrbáč wrote:
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testin
I've installed those a couple of hours ago on a half-test half-production machine. So far, so good.
Manuel
Since the upgrade I see daily in the logs:
/etc/cron.daily/logrotate:
error: yum:5 unknown option 'yearly' -- ignoring line
Manuel Wolfshant wrote:
Manuel Wolfshant wrote:
On 01/25/2010 10:23 AM, David Hrbáč wrote:
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testin
I've installed those a couple of hours ago on a half-test half-production machine. So far, so good.
Manuel
Since the upgrade I see daily in the logs:
/etc/cron.daily/logrotate:
error: yum:5 unknown option 'yearly' -- ignoring line
Sorry, I've pressed enter too fast. Make it:
Since the upgrade I see daily in the logs:
/etc/cron.daily/logrotate:
error: yum:5 unknown option 'yearly' -- ignoring line
I suppose that the support for rotating "yearly" is not included in logrotate-3.7.1-10.RHEL4 (stock Centos 4.8)
Sorry, I've pressed enter too fast. Make it:
Since the upgrade I see daily in the logs:
/etc/cron.daily/logrotate: error: yum:5 unknown option 'yearly' -- ignoring lineI suppose that the support for rotating "yearly" is not included in logrotate-3.7.1-10.RHEL4 (stock Centos 4.8)
Well, I do not see it within our logs :o( Where do you see it? I'll remove the 'yearly' from /etc/logrotate.d/yum. Regards, David
David Hrbáč wrote:
Sorry, I've pressed enter too fast. Make it:
Since the upgrade I see daily in the logs:
/etc/cron.daily/logrotate: error: yum:5 unknown option 'yearly' -- ignoring lineI suppose that the support for rotating "yearly" is not included in logrotate-3.7.1-10.RHEL4 (stock Centos 4.8)
Well, I do not see it within our logs :o( Where do you see it?
In the output of logrotate, on the stock C4.8 box used for testing. And I do NOT see any mention of "yearly" in the manual page for that version of logrotate
I'll remove the 'yearly' from /etc/logrotate.d/yum.
I think that rotating yearly in this context is overengineered, anyway. I use a size limit.
Manuel
On Wed, 2010-01-27 at 11:00 +0200, Manuel Wolfshant wrote:
David Hrbáč wrote:
I'll remove the 'yearly' from /etc/logrotate.d/yum.
I think that rotating yearly in this context is overengineered, anyway. I use a size limit.
There is a size limit, the reason there's a "yearly" there too is for:
https://bugzilla.redhat.com/174969 [Default logrotate config for yum produces wrong logwatch output]
On 01/29/2010 06:31 PM, James Antill wrote:
On Wed, 2010-01-27 at 11:00 +0200, Manuel Wolfshant wrote:
David Hrbáč wrote:
I'll remove the 'yearly' from /etc/logrotate.d/yum.
I think that rotating yearly in this context is overengineered, anyway. I use a size limit.
There is a size limit, the reason there's a "yearly" there too is for:
https://bugzilla.redhat.com/174969 [Default logrotate config for yum produces wrong logwatch output]
Mind that the bug has fixes for newer logrotate versions. The version included in Centos 4 is logrotate-3.7.1 and it does not understand the "yearly" keyword, hence the solution from https://bugzilla.redhat.com/show_bug.cgi?id=174969#c8 cannot be applied.
On Mon, 2010-01-25 at 09:23 +0100, David Hrbáč wrote:
<snip>
Hi William, are you still willing to test the yum 3.2.x on C4? Last week I have finished yum 3.2.19 backport to C4. We have been using it extensively on large set of production boxes. Packages are available within the hrb-testing repo. http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/repoview/yum.html http://fs12.vsb.cz/hrb33/el4/hrb/testing/x86_64/repoview/yum.html
David,
I got pretty far along, with a little manual removal of the stock stuff, but I think I've missed something. Here's my current status from an rpm -qa yum*
yum-kmod-1.1.16-13.el4.hrb.1 yum-list-data-1.1.16-13.el4.hrb.1 yum-fastestmirror-1.1.16-13.el4.hrb.1 yum-changelog-1.1.16-13.el4.hrb.1 yum-arch-2.2.2-1.el4.rf yum-downloadonly-1.1.16-13.el4.hrb.1 yum-versionlock-1.1.16-13.el4.hrb.1 yum-protectbase-1.1.16-13.el4.hrb.1 yum-kernel-module-1.1.16-13.el4.hrb.1 yum-metadata-parser-1.1.2-12.el4.hrb.1 yum-keys-1.1.16-13.el4.hrb.1 yum-allowdowngrade-1.1.16-13.el4.hrb.1 yum-priorities-1.1.16-13.el4.hrb.1 yum-tsflags-1.1.16-13.el4.hrb.1 yum-merge-conf-1.1.16-13.el4.hrb.1 yum-aliases-1.1.16-13.el4.hrb.1 yumex-1.0.2-1.0.c4 yum-utils-1.1.16-13.el4.hrb.1 yum-protect-packages-1.1.16-13.el4.hrb.1 yum-NetworkManager-dispatcher-1.1.16-13.el4.hrb.1 yum-3.2.19-18.el4.hrb.5 yum-verify-1.1.16-13.el4.hrb.1 yum-plugin-fastestmirror-0.2.4-3.c4 yum-updateonboot-1.1.16-13.el4.hrb.1 yum-tmprepo-1.1.16-13.el4.hrb.1 yum-filter-data-1.1.16-13.el4.hrb.1 yum-upgrade-helper-1.1.16-13.el4.hrb.1 yum-security-1.1.16-13.el4.hrb.1
The yum-refresh-updatesd has not made it in yet. It had a dependancy failure prior to getting all the above installed, so I excluded it and continued on.
Anyway, after getting to the above status, I did a yum update and got the following
Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 189, in getOptionsConfig enabled_plugins=self.optparser._splitArg(opts.enableplugins)) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 195, in _getConfig startupconf.pluginconfpath,disabled_plugins,enabled_plugins) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 361, in doPluginSetup plugin_types, confpath, disabled_plugins, enabled_plugins) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 159, in __init__ self._importplugins(types) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 202, in _importplugins self._loadplugin(modulefile, types) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 262, in _loadplugin module = imp.load_module(modname, fp, pathname, description) File "/usr/lib/yum-plugins/verify.py", line 167 @staticmethod ^ SyntaxError: invalid syntax
If you see any error in where I'm at, or need more information, just let me know.
Regards, David Hrbáč
<snip sig stuff>
HTH
Dne 27.1.2010 0:50, William L. Maltby napsal(a):
David,
I got pretty far along, with a little manual removal of the stock stuff, but I think I've missed something. Here's my current status from an rpm -qa yum*
yum-kmod-1.1.16-13.el4.hrb.1 yum-list-data-1.1.16-13.el4.hrb.1 yum-fastestmirror-1.1.16-13.el4.hrb.1 yum-changelog-1.1.16-13.el4.hrb.1 yum-arch-2.2.2-1.el4.rf yum-downloadonly-1.1.16-13.el4.hrb.1 yum-versionlock-1.1.16-13.el4.hrb.1 yum-protectbase-1.1.16-13.el4.hrb.1 yum-kernel-module-1.1.16-13.el4.hrb.1 yum-metadata-parser-1.1.2-12.el4.hrb.1 yum-keys-1.1.16-13.el4.hrb.1 yum-allowdowngrade-1.1.16-13.el4.hrb.1 yum-priorities-1.1.16-13.el4.hrb.1 yum-tsflags-1.1.16-13.el4.hrb.1 yum-merge-conf-1.1.16-13.el4.hrb.1 yum-aliases-1.1.16-13.el4.hrb.1 yumex-1.0.2-1.0.c4 yum-utils-1.1.16-13.el4.hrb.1 yum-protect-packages-1.1.16-13.el4.hrb.1 yum-NetworkManager-dispatcher-1.1.16-13.el4.hrb.1 yum-3.2.19-18.el4.hrb.5 yum-verify-1.1.16-13.el4.hrb.1 yum-plugin-fastestmirror-0.2.4-3.c4 yum-updateonboot-1.1.16-13.el4.hrb.1 yum-tmprepo-1.1.16-13.el4.hrb.1 yum-filter-data-1.1.16-13.el4.hrb.1 yum-upgrade-helper-1.1.16-13.el4.hrb.1 yum-security-1.1.16-13.el4.hrb.1
The yum-refresh-updatesd has not made it in yet. It had a dependancy failure prior to getting all the above installed, so I excluded it and continued on.
Anyway, after getting to the above status, I did a yum update and got the following
Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 189, in getOptionsConfig enabled_plugins=self.optparser._splitArg(opts.enableplugins)) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 195, in _getConfig startupconf.pluginconfpath,disabled_plugins,enabled_plugins) File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 361, in doPluginSetup plugin_types, confpath, disabled_plugins, enabled_plugins) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 159, in __init__ self._importplugins(types) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 202, in _importplugins self._loadplugin(modulefile, types) File "/usr/lib/python2.3/site-packages/yum/plugins.py", line 262, in _loadplugin module = imp.load_module(modname, fp, pathname, description) File "/usr/lib/yum-plugins/verify.py", line 167 @staticmethod ^ SyntaxError: invalid syntax
If you see any error in where I'm at, or need more information, just let me know.
William, not all plugins are production ready. We run within our production fastestmirror, changelog. For change log you need python-dateutil.noarch. You have installed all plugins, but what plugins are you really using? Just want to know. BTW thanks for reporting the error. Thanks, David
On Wed, 2010-01-27 at 09:00 +0100, David Hrbáč wrote:
<snip>
William, not all plugins are production ready. We run within our production fastestmirror, changelog. For change log you need python-dateutil.noarch. You have installed all plugins, but what plugins are you really using? Just want to know. BTW thanks for reporting the error.
I just saw your other post. I had an hrb repo already setup and just used it. I'll re-do using the hrb-test again tonight with your instructions from the other post. I'll also check my plugins - I know I use priority, protect (disabled since I use priority) and fastest mirror normally.
I'll post results from that new test this evening.
Thanks, David
<snip sig stuff>
I appreciate your efforts on this.
Dne 27.1.2010 16:03, William L. Maltby napsal(a):
I just saw your other post. I had an hrb repo already setup and just used it. I'll re-do using the hrb-test again tonight with your instructions from the other post. I'll also check my plugins - I know I use priority, protect (disabled since I use priority) and fastest mirror normally.
I'll post results from that new test this evening.
Well, priority and protect is the good point to start. Fastestmirror and changelog work. Thanks for testing. David
On Thu, 2010-01-28 at 10:06 +0100, David Hrbáč wrote:
Dne 27.1.2010 16:03, William L. Maltby napsal(a):
I just saw your other post. I had an hrb repo already setup and just used it. I'll re-do using the hrb-test again tonight with your instructions from the other post. I'll also check my plugins - I know I use priority, protect (disabled since I use priority) and fastest mirror normally.
I'll post results from that new test this evening.
Well, priority and protect is the good point to start. Fastestmirror and changelog work. Thanks for testing.
Just to eliminate as many variables as possible, I edited yum.conf and the yum/pluginconf.d/* files and disabled all plugins. It looks as though my normal setup in the repo files only hit protect (disabled), priority (enabled) and the fastest mirrors was enabled in the plugins.
The errors seem to be the same as the ones I posted earlier today.
Let me know what I can do to help. I stashed all the files on a floppy so I can send them to the list if needed.
David
<snip sig stuff>
David Hrbáč wrote:
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch.
Just a question as to what you are shotting for here - given that CentOS-4 has yum-2.4, which is by far the best yum yet ( it actually does what it says on the tin ). Might not be the fastest version, but at least it gets the depsolving right.
On Thu, 23 Jul 2009, Karanbir Singh wrote:
David Hrbáč wrote:
Please be aware that testing repo has a new version of yum 3.2.19, which is not production ready and the package is broken. I have been asking QA for yum-3.2.8-9.el4.hrb.2.1.5.noarch.rpm. Version 3.2.19 will follow soon, I"m running it now successfully with python-urlgrabber-3.1.0-5.el4.hrb.1.noarch.
Just a question as to what you are shotting for here - given that CentOS-4 has yum-2.4, which is by far the best yum yet ( it actually does what it says on the tin ). Might not be the fastest version, but at least it gets the depsolving right.
How does 3.2.X not get the depsolving right?
-sv
On Thu, Jul 23, 2009 at 6:02 AM, Seth Vidalskvidal@fedoraproject.org wrote:
On Thu, 23 Jul 2009, Karanbir Singh wrote:
Just a question as to what you are shotting for here - given that CentOS-4 has yum-2.4, which is by far the best yum yet ( it actually does what it says on the tin ). Might not be the fastest version, but at least it gets the depsolving right.
How does 3.2.X not get the depsolving right?
-sv
I know of at least one issue with yum in CentOS-5. If I try to build grub in mock, I get:
No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting.
Johnny Hughes explained the reason for the failure in his CentOS Forum post on 2008/02/09:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=12491&forum=3...
Excerpt: ---------------------------------------------------------------- There is a known bug in the yum that ships with centos-5 (and rhel-5) ... version 3.0.x ... where BuildRequires that are in the form of BuildRequires: <file_path> do not work.
This bug will take any file, the first one it finds actually, and use it to meet the build requirement ... not the one specified by the full path.
SO ... in this case the problem is that the grub spec file has this line for the x86_64 package build:
BuildRequires: automake /usr/lib/crt1.o
The problem is that what needs to be installed is glibc-devel.i386 ... however a different package meets that require due to the bug, and the build fails (if using mock and centos-5 as the base). If you use centos-4 as the base os and setup mock to build centos-5 packages on that machine, then this package will build via mock. ----------------------------------------------------------------
This still happens with the current yum-3.2.19-18.el5.centos.noarch (and mock-0.6.13-1.el5_2.3.x86_64) in CentOS-5.
Akemi
On Thu, 23 Jul 2009, Akemi Yagi wrote:
I know of at least one issue with yum in CentOS-5. If I try to build grub in mock, I get:
No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting.
centos5 has been out for a looooooooooong time now and the yum that's in centos 5.3 has had a number of bugfixes.
So is yum 3.X considered bad b/c 3.0.X had some bugs? B/c lemme tell you 2.4.X had a good number of bugs, too.
This still happens with the current yum-3.2.19-18.el5.centos.noarch (and mock-0.6.13-1.el5_2.3.x86_64) in CentOS-5.
It looks like it is fixed in yum available for what will be centos 5.4/rhel 5.4.
yum 3.2.22 doesn't have it this issue.
-sv
On Thu, Jul 23, 2009 at 11:57 AM, Seth Vidalskvidal@fedoraproject.org wrote:
On Thu, 23 Jul 2009, Akemi Yagi wrote:
I know of at least one issue with yum in CentOS-5. If I try to build grub in mock, I get:
No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting.
centos5 has been out for a looooooooooong time now and the yum that's in centos 5.3 has had a number of bugfixes.
Sorry, the above example output was from a CentOS 5.3 system with yum-3.2.19-18.el5. It was generated a few hours ago. :)
So is yum 3.X considered bad b/c 3.0.X had some bugs?
No, I did not say that. However, I will continue to use CentOS-4 for running mock for the time being.
B/c lemme tell you 2.4.X had a good number of bugs, too.
I firmly believe you. :-)
This still happens with the current yum-3.2.19-18.el5.centos.noarch (and mock-0.6.13-1.el5_2.3.x86_64) in CentOS-5.
It looks like it is fixed in yum available for what will be centos 5.4/rhel 5.4.
yum 3.2.22 doesn't have it this issue.
I'm not sure why, but I just installed yum-3.2.22-15.el5.noarch (from RHEL5.4beta) and mock ended with the same error as above...
Akemi
On Thu, 23 Jul 2009, Akemi Yagi wrote:
On Thu, Jul 23, 2009 at 11:57 AM, Seth Vidalskvidal@fedoraproject.org wrote:
On Thu, 23 Jul 2009, Akemi Yagi wrote:
I know of at least one issue with yum in CentOS-5. If I try to build grub in mock, I get:
No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting.
centos5 has been out for a looooooooooong time now and the yum that's in centos 5.3 has had a number of bugfixes.
Sorry, the above example output was from a CentOS 5.3 system with yum-3.2.19-18.el5. It was generated a few hours ago. :)
So is yum 3.X considered bad b/c 3.0.X had some bugs?
No, I did not say that. However, I will continue to use CentOS-4 for running mock for the time being.
B/c lemme tell you 2.4.X had a good number of bugs, too.
I firmly believe you. :-)
This still happens with the current yum-3.2.19-18.el5.centos.noarch (and mock-0.6.13-1.el5_2.3.x86_64) in CentOS-5.
It looks like it is fixed in yum available for what will be centos 5.4/rhel 5.4.
yum 3.2.22 doesn't have it this issue.
I'm not sure why, but I just installed yum-3.2.22-15.el5.noarch (from RHEL5.4beta) and mock ended with the same error as above...
1. did you clean out the mock cache entirely? 2. I just tested 3.2.22-14 on rhel5 - here's what I get: yum resolvedep /usr/lib/crt1.o Loaded plugins: security Importing additional filelist information 0:glibc-devel-2.5-34.i386
-sv
On Thu, Jul 23, 2009 at 1:10 PM, Seth Vidalskvidal@fedoraproject.org wrote:
It looks like it is fixed in yum available for what will be centos 5.4/rhel 5.4.
yum 3.2.22 doesn't have it this issue.
I'm not sure why, but I just installed yum-3.2.22-15.el5.noarch (from RHEL5.4beta) and mock ended with the same error as above...
- did you clean out the mock cache entirely?
Yes. I emptied /var/lib/mock/ .
- I just tested 3.2.22-14 on rhel5 - here's what I get:
yum resolvedep /usr/lib/crt1.o Loaded plugins: security Importing additional filelist information 0:glibc-devel-2.5-34.i386
This is what I get:
setup 0:automake-1.9.6-2.1.noarch 0:texinfo-4.8-14.el5.x86_64 No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting. ending
On Thu, 23 Jul 2009, Akemi Yagi wrote:
On Thu, Jul 23, 2009 at 1:10 PM, Seth Vidalskvidal@fedoraproject.org wrote:
It looks like it is fixed in yum available for what will be centos 5.4/rhel 5.4.
yum 3.2.22 doesn't have it this issue.
I'm not sure why, but I just installed yum-3.2.22-15.el5.noarch (from RHEL5.4beta) and mock ended with the same error as above...
- did you clean out the mock cache entirely?
Yes. I emptied /var/lib/mock/ .
- I just tested 3.2.22-14 on rhel5 - here's what I get:
yum resolvedep /usr/lib/crt1.o Loaded plugins: security Importing additional filelist information 0:glibc-devel-2.5-34.i386
This is what I get:
setup 0:automake-1.9.6-2.1.noarch 0:texinfo-4.8-14.el5.x86_64 No Package Found for /usr/lib/crt1.o 0:binutils-2.17.50.0.6-9.el5.x86_64 0:ncurses-devel-5.5-24.20060715.x86_64
Cannot find build req /usr/lib/crt1.o. Exiting. ending
is it in the repo properly?
-sv
On Thu, Jul 23, 2009 at 1:29 PM, Seth Vidalskvidal@fedoraproject.org wrote:
Cannot find build req /usr/lib/crt1.o. Exiting. ending
is it in the repo properly?
Just found out that centos-5-x86_64.cfg supplied by the centos mock rpm contains "*-devel.i?86" on the exclude= line. When this was deleted, all was well.
Now the question is: should the "*-devel.i?86" be removed from the cfg file? Karanbir?
Akemi
Akemi Yagi wrote:
On Thu, Jul 23, 2009 at 1:29 PM, Seth Vidalskvidal@fedoraproject.org wrote:
Cannot find build req /usr/lib/crt1.o. Exiting. ending
is it in the repo properly?
Just found out that centos-5-x86_64.cfg supplied by the centos mock rpm contains "*-devel.i?86" on the exclude= line. When this was deleted, all was well.
Yes, the config that ships is subtly broken and won't allow building of a couple packages (grub and syslinux), as you just found out.
Building of grub and syslinux packages on x86_64 need glibc-devel.i386 which pulls in glibc.i686 so the exclude line should exclude all .i?86 files except these two.
Now the question is: should the "*-devel.i?86" be removed from the cfg file? Karanbir?
Akemi
On 07/23/2009 10:22 PM, Akemi Yagi wrote:
Just found out that centos-5-x86_64.cfg supplied by the centos mock rpm contains "*-devel.i?86" on the exclude= line. When this was deleted, all was well.
how many other pkgs are now broken on the builds ? :)
On Thu, Jul 23, 2009 at 2:50 PM, Karanbir Singhmail-lists@karan.org wrote:
On 07/23/2009 10:22 PM, Akemi Yagi wrote:
Just found out that centos-5-x86_64.cfg supplied by the centos mock rpm contains "*-devel.i?86" on the exclude= line. When this was deleted, all was well.
how many other pkgs are now broken on the builds ? :)
Then, we are back to where we started and blame yum for the breakage?
Akemi
Karanbir Singh napsal(a):
Just a question as to what you are shotting for here - given that CentOS-4 has yum-2.4, which is by far the best yum yet ( it actually does what it says on the tin ). Might not be the fastest version, but at least it gets the depsolving right.
Well, 3.2.x is far better, faster, together with python-urlgrabber-3.1.0 the best one we have. Take it as a backport exercise if you like, I do the same, and I have proven that both 3.2.8 and 3.2.19 are backportable to python 2.3. I like sqlite repos so 3.2.x does. It has much better TUI also. David Hrbáč
-
Akemi Yagi -
David Hrbáč -
James Antill -
Karanbir Singh -
Manuel Wolfshant -
Ned Slider -
Seth Vidal -
William L. Maltby