Re: [Yum-devel] [PATCH] use yum tag when logging to syslog
Terje Rosten wrote: * seth vidal | | it might be useful to allow that field to look like: | | Dec 12 08:09:38 hostname yum(yum-cli): Updated: openssh-server.x86_64 | 4.3p2-14.fc6 | Dec 12 08:09:38 hostname yum(yumex): Updated: openssh-server.x86_64 | 4.3p2-14.fc6 | Dec 12 08:09:38 hostname yum(pirut): Updated: openssh-server.x86_64 | 4.3p2-14.fc6 | Dec 12 08:09:38 hostname yum(yum-updatesd): Updated: | openssh-server.x86_64 4.3p2-14.fc6 | | so you can distinguish how the update/install/etc was performed. New patch with this fixed, tested with yum-cli, pirut and yum-updatesd. ( However logging with yum-updatesd is not possible unless you use the patch I posted some days ago: https://lists.dulug.duke.edu/pipermail/yum-devel/2006-December/002955.html See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212507 Comment #41. ) yumex seems to do some funny thing with logging, Tim? Yes, yumex do some funny stuff with logging, it don't use the logginglevels.doLoggingSetup to setup logging, because it is using a custom logging handler to print the logging output to a GTK TextView. I will try to fix it so it is using the default yum logging setup and just add another logging handler to handle the gtk.Textview output. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] use yum tag when logging to syslog
Terje Rosten wrote: * Tim Lauridsen | | I have worked a little with Terje's patch and modified it so the | application can be set by a function call. Thanks Tim, please install the patch. Ok, i will do that, should it go into the 3.0.x Branch or just into HEAD ??? Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] use yum tag when logging to syslog
seth vidal wrote: On Wed, 2007-01-03 at 10:35 +0100, Terje Røsten wrote: * Tim Lauridsen | | Ok, i will do that, should it go into the 3.0.x Branch or just into HEAD ??? Included in upcoming 3.0.3 would be nice, but I guess Seth want to wait: http://wiki.linux.duke.edu/YumTodo I'd prefer to get 3.0.3 out this friday with just the fewest number of bugfixes to 3.0.2 as possible and put in the changes you talk about here with in 3.0.4 if that makes sense. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Ok, i have applied it CVS HEAD, i will add to the 3_0_X branch after 3.0.3 has been released. Tim. ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum 3.0.2
Terje Rosten wrote: * seth vidal | | If no one sees anything brazen and stupid by friday I'll put out a 3.0.3 | to fix this up. I might found one more bug, I did some profiling (howto coming soon) to discover the issue. It's a performance issue, yum 3.0.2 is spending lots of time (70%) in the returnObsoletes function. To understand the problem have a look at these callgraphs: http://web.phys.ntnu.no/~terjeros/yum/yum-3.0.2-callgraph.png http://web.phys.ntnu.no/~terjeros/yum/yum-3.0.1-callgraph.png generated by a simple 'yum install xpdf'. The kcachegrind files is available here: http://web.phys.ntnu.no/~terjeros/yum/ - Terje ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel I am seeing the same thing in yumex after upgrading yum to 3.0.2, it added about 1 min to the package list creation. I add some extra debug output to yumex and found out that it was doUpdateSetup there is the problem. output from yumex: yum 3.0.1 16:02:59 : Building Package Lists : doRpmDBSetup 16:03:00 : Building Package Lists : doTsSetup 16:03:00 : Building Package Lists : doUpdateSetup 16:03:02 : Building Package Lists : Updates 16:03:03 : Building Package Lists : 27 Updates found yum 3.0.2 16:05:56 : Building Package Lists : Start 16:05:56 : Building Package Lists : doRpmDBSetup 16:05:56 : Building Package Lists : doTsSetup 16:05:56 : Building Package Lists : doUpdateSetup 16:06:58 : Building Package Lists : Updates 16:06:59 : Building Package Lists : 27 Updates found 16:06:59 : Building Package Lists completed Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] Errors.py broken in the 3_0_X branch
Hi I detected some problems with Error.py, mainly because of self.args was renamed to self.value in the base class but not in the children classes, i merged the changes Errors.py in HEAD into 3_0_X, so now it is working again. https://lists.dulug.duke.edu/pipermail/yum-cvs-commits/2007-January/001260.html Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] fedorakmod work
Jack Neely wrote: = Package Arch Version RepositorySize = Installing: kmod-sysprofi686 1.0.8-1.2.6.19_1.2895.fc6 extras 6.3 k kmod-sysprofi686 1.0.8-1.2.6.18_1.2868.fc6 extras 6.2 k kmod-sysprof-xeni686 1.0.8-1.2.6.18_1.2868.fc6 extras 6.2 k Removing: kernel i686 2.6.18-1.2868.fc6 installed 44 M Installing for dependencies: kernel i686 2.6.19-1.2895.fc6 updates16 M sysprof i386 1.0.8-1.fc6 extras312 k This is looking strange, It only happen because the system don't have the latest kernel installed, so the latest kmod-sysprof pull in the latest kernel as a dependency and make installonlyn to remove already installed kernel. The strange part is why don't the depsolve make an error, it is run after the postresolv hook has been called if the transaction is changed. kmod-sysprofi686 1.0.8-1.2.6.18_1.2868.fc6 should depend on kernel i686 2.6.18-1.2868.fc6 this dependency can't be meet because the .2868 kernel is marked for removal, so it should cause an error. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] announcing repoman!
Chris Lumens wrote: David Cantrell and I have been working on a small utility to configure yum repositories and made it available publically on Sunday night after putting some serious work into it over the weekend. He sent an announcement to fedora-devel-list, but since he's not on this list I said I'd forward it along. For now, the project is being hosted on his machine but we'll probably move it later. Here's the text of the announcement. My apologies to those who will be seeing this twice. One note modifying the text is that we now do have devel packages available since the problem was with the spec file, not with the build system. - Chris Announcing repoman -- Repoman is a PyGTK frontend for configuring common and basic settings for yum. Specifically, it lets users enable and disable individual repos easily. Users can add and remove repositories as well. Repoman is not meant to expose all of yum's configuration settings in GUI form, but rather the common settings most users will care about. One of the interesting features is the Tracking page. Users can easily switch between stable (with or without updates) or development branches and repoman will enable and disable the correct repositories for the user. Repoman also offers a set of Python classes for reading and writing out /etc/yum.repos.d files. The core element is the RepoStanza, which are contained in RepoFiles, and all of those make up a Repos collection. This program is evolving a lot, so help testing and/or coding is appreciated. Repoman is short for repository manager. DOWNLOAD Web page: http://www.boston.burdell.org/repoman/ Source archives are available in tar.gz format. We have RPMs available for Fedora Core 6. We would have rawhide RPMs available, but we ran in to a problem building on rawhide. QUESTIONS/BUGS Please email me or Chris Lumens (email addresses on web page) if you bug reports. Hi Chris I have also started a project called 'system-config-repo' doing exactly the same stuff as repoman. You can checkout the sources and rawhide rpms here: http://www.yum-extender.org/dnl/system-config-repo/devel/ If you and David are interested we can merge our projects, no need for two different repository manager projects. Let me know what you think. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Config file migrations for 3.1.x
James Bowes wrote: Jeremy Katz wrote: I can see a few options: 1) Bail on moving things. Kind of sucks as moving things would get us a lot more consistency. 2) In the %post of the yum package, move everything around. This breaks verification of the packages containing repo files and leads to lots of rpmnew junk peppered across the filesystem 3) In the %post of the yum package, just move the config file. Ensure that we look at both /etc/yum/repos.d and /etc/yum.repos.d. Packages that contain repo configs need to deal with managing their own migration. 4) ??? I like 3. I don't think we want to mess with files that come from other rpms. What we should do is write a good script bit for %post, and make it available for the packagers of these repo configs. We could also spew out a warning when a file is in the old location. This might help spur packagers along but will probably just result in many duplicate bugs upon your plate, Mr. Katz. -James +1 Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum-utils 1.1.1 released (Yum = 3.1.1 Only)
Tim Lauridsen wrote: Hi. yum-utils 1.1.1 has been released. The yum-utils-1.1.x branch only works with yum = 3.1.1 Changes: - Changed 'with=' to 'mdtype=' in repos.populateSack calls, because of changes in the yum API in YumPackageSack.populate method to avoid warnings about 'with' is a reserved word in Python 2.6. - fixed UnicodeEncodeError: 'ascii' codec can't encode character errors in repo-rss Forgot to mention that the release contains a redesigned version of yumdownloader using the new yum-utils base class introduced in yum-3.1.1. This version inherit all command line options from the yum-cli and also command line option added by yum plugins. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] collapsing the packagesack objects
seth vidal wrote: Hey guys, I've been going through a lot of the package sack code looking for what takes so long on a couple of operations. What I've found is that to figure out what's going on at any given time you have to chase over 5 different files. And most of it is for ridiculous cases. At the hackfest at fudcon at the beginning of feb we talked about just biting the bullet and assuming the packagesack backend will be sqlite. If we're all on board with that then I'll probably start collapsing code down. Does that make sense to everyone? make sense to me, Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [BUG] Traceback in sqlitesack.py
Just stumpled over the one, i the current yum CVS HEAD. [EMAIL PROTECTED] yum]# time ./yummain.py remove policycoreutils Loading fastestmirror plugin Loading installonlyn plugin Loading mirror speeds from cached hostfile Setting up Remove Process Resolving Dependencies -- Running transaction check Checking deps for policycoreutils.i386 0-1.34.1-3.fc7 - e Traceback (most recent call last): File ./yummain.py, line 193, in module main(sys.argv[1:]) File ./yummain.py, line 135, in main (result, resultmsgs) = base.buildTransaction() File /home/tim/workspace/yum/yum/__init__.py, line 516, in buildTransaction (rescode, restring) = self.resolveDeps() File /home/tim/workspace/yum/yum/depsolve.py, line 1135, in _resolveDeps deps = self._mytsCheck() File /home/tim/workspace/yum/yum/depsolve.py, line 1115, in _mytsCheck ret.extend(self._checkRemove(txmbr)) File /home/tim/workspace/yum/yum/depsolve.py, line 1376, in _checkRemove for po in self.pkgSack.searchProvides(r): File /home/tim/workspace/yum/yum/__init__.py, line 487, in lambda pkgSack = property(fget=lambda self: self._getSacks()) File /home/tim/workspace/yum/yum/__init__.py, line 384, in _getSacks self._pkgSack.excludeArchs(archlist) File /home/tim/workspace/yum/yum/packageSack.py, line 331, in excludeArchs sack.excludeArchs(archlist) File /home/tim/workspace/yum/yum/sqlitesack.py, line 670, in excludeArchs obj = self.pc(rep,row) File /home/tim/workspace/yum/yum/sqlitesack.py, line 52, in __init__ self._read_db_obj(db_obj) File /home/tim/workspace/yum/yum/sqlitesack.py, line 70, in _read_db_obj if db_obj.has_key(item): AttributeError: 'sqlite3.Row' object has no attribute 'has_key' Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [BUG] Traceback in sqlitesack.py
seth vidal wrote: On Wed, 2007-02-28 at 14:41 +0100, Tim Lauridsen wrote: Just stumpled over the one, i the current yum CVS HEAD. Got it. I left a db2class() call in sqlitesack.py. Should be fixed now - please let me know when you get a chance. Still got the same error with current CVS Head. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Re: [yum-cvs] yum-utils/plugins/skip-broken skip-broken.py, 1.3, 1.4
Jeremy Katz wrote: On Thu, 2007-03-01 at 13:26 -0500, Tim Lauridsen wrote: Update of /home/groups/yum/cvs/yum-utils/plugins/skip-broken In directory login1.linux.duke.edu:/tmp/cvs-serv15598/plugins/skip-broken Modified Files: skip-broken.py Log Message: more clean fix for work with latest yum api Even this shouldn't be needed. How are things failing otherwise so that we can preserve the API instead of requiring people to change their code? You are right the original skip-broken code should work now without modifications. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] Depsolving localinstall packages is not working right
I was trying to install the Mondo system backup util and downloaded the needed rpms at ftp://ftp.mondorescue.org/fedora/6. I was trying to install then packages using 'yum localinstall *.rpm' and got some dependency errors. It look like that the depsolver dont uses the local packages when it is looking for dependencies. I have no problem installing the packages using 'rpm -ivh *.rpm' Tim [EMAIL PROTECTED] mondo]$ ls afio-2.4.7-1.i386.rpm mindi-busybox-1.2.2-1.fc6.i586.rpm buffer-1.19-1.i386.rpm mondo-2.2.1-1.fc6.i586.rpm mindi-1.2.1-1.fc6.i586.rpm mondo-doc-2.2.1-1.fc6.noarch.rpm [EMAIL PROTECTED] mondo]$ sudo yum localinstall *.rpm Loading installonlyn plugin Setting up Local Package Process Examining afio-2.4.7-1.i386.rpm: afio - 2.4.7-1.i386 Examining buffer-1.19-1.i386.rpm: buffer - 1.19-1.i386 Examining mindi-1.2.1-1.fc6.i586.rpm: mindi - 1.2.1-1.fc6.i586 Examining mindi-busybox-1.2.2-1.fc6.i586.rpm: mindi-busybox - 1.2.2-1.fc6.i586 Examining mondo-2.2.1-1.fc6.i586.rpm: mondo - 2.2.1-1.fc6.i586 Examining mondo-doc-2.2.1-1.fc6.noarch.rpm: mondo-doc - 2.2.1-1.fc6.noarch Marking afio-2.4.7-1.i386.rpm to be installed Marking buffer-1.19-1.i386.rpm to be installed Marking mindi-1.2.1-1.fc6.i586.rpm to be installed Marking mindi-busybox-1.2.2-1.fc6.i586.rpm to be installed Marking mondo-2.2.1-1.fc6.i586.rpm to be installed Marking mondo-doc-2.2.1-1.fc6.noarch.rpm to be installed Resolving Dependencies -- Running transaction check Checking deps for mondo.i586 0-2.2.1-1.fc6 - u Checking deps for mindi.i586 0-1.2.1-1.fc6 - u Checking deps for mindi-busybox.i586 0-1.2.2-1.fc6 - u Checking deps for mondo-doc.noarch 0-2.2.1-1.fc6 - u Checking deps for buffer.i386 0-1.19-1 - u Checking deps for afio.i386 0-2.4.7-1 - u -- Processing Dependency: mindi-busybox for package: mindi -- Processing Dependency: mindi = 1.2.1 for package: mondo -- Processing Dependency: afio for package: mondo -- Finished Dependency Resolution Error: Missing Dependency: mindi-busybox is needed by package mindi Error: Missing Dependency: mindi = 1.2.1 is needed by package mondo Error: Missing Dependency: afio is needed by package mondo [EMAIL PROTECTED] mondo]$ rpm -ivh --test *.rpm Preparing...### [100%] [EMAIL PROTECTED] mondo]$ ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] Why i the fastestmirror a TYPE_INTERACTIVE plugin
Luke, Why is the fastestmirror plugin TYPE_INTERACTIVE and not TYPE_CORE. I would be nice if it worked in yumex, pup, pirut etc. There only use TYPE_CORE plugins. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] A little tools to test the speed of the depsolver
A have made a little tool to test the speed of the depsolver in yum
here is a test of timing the depsolve of k3b in a clean root:
sudo ./testyum.py --installroot=/tmp/yum-test k3b
the tool have all the normal command line switch in yum cli.
Tim
#!/usr/bin/python -tt
#
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Library General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
import sys
sys.path.insert(0,'/usr/share/yum-cli')
import yum
from cli import *
from utils import YumUtilBase
from yum.misc import getCacheDir
import time
class YumDepTester(YumUtilBase):
NAME = 'testyum'
VERSION = '1.0'
USAGE = 'usage: testyum package1 [package2] [package..]'
def __init__(self):
YumUtilBase.__init__(self,
YumDepTester.NAME,
YumDepTester.VERSION,
YumDepTester.USAGE)
self.logger = logging.getLogger(yum.verbose.cli.yumdeptester)
self.main()
def main(self):
parser = self.getOptionParser()
opts = self.doUtilConfigSetup()
# Check if there is anything to do.
if len(self.cmds) 1:
parser.print_help()
sys.exit(0)
# make yumdownloader work as non root user.
if self.conf.uid != 0:
cachedir = getCacheDir()
if cachedir is None:
self.logger.error(Error: Could not make cachedir, exiting)
sys.exit(50)
self.repos.setCacheDir(cachedir)
# Setup yum (Ts, RPM db, Repo Sack)
self.doUtilYumSetup()
# Do the real action
self.doDepTest()
def doDepTest(self):
for p in self.cmds:
self.logger.info('Adding : %s ' % p)
self.addPackage(p)
# buildTransaction
startTime = time.time()
print Starting buildTransaction
(res, resmsg) = self.buildTransaction()
endTime = time.time()
print buildTransaction took : %2f % (endTime - startTime)
if res != 2:
print Unable to build transaction
for m in resmsg:
print m
sys.exit(1)
else:
pass
def addPackage(self, pkg):
try:
mbrs = self.install(pattern = pkg)
return len(mbrs)
except yum.Errors.InstallError:
print sys.stderr, No package matching %s %(pkg,)
return 0
if __name__ == __main__:
util = YumDepTester()
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] yum-utils 1.0.4 Released.
yum-utils 1.0.4 has been released. (works with yum 3.0.x) The mayor change is that the plugins now runs with plugins enabled, so they will work on RHEL5 where the repos are added by a plugin. Check the Changelog for more changes. Tarball: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.0.4.tar.gz SRPM: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.0.4-1.src.rpm Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [patch] YumBase.comps property broken
Florian Festi wrote: Tracebacks when pressing n after yum update cu Florian Index: __init__.py === RCS file: /cvsroot/yum/cvs/yum/yum/__init__.py,v retrieving revision 1.311 diff -u -r1.311 __init__.py --- __init__.py 19 Mar 2007 21:53:56 - 1.311 +++ __init__.py 20 Mar 2007 08:38:12 - @@ -509,7 +509,7 @@ fset=lambda self, value: setattr(self, _up, value), fdel=lambda self: setattr(self, _up, None)) comps = property(fget=lambda self: self._getGroups(), - fset=lambda self, value: self._setGroups(self, value), + fset=lambda self, value: self._setGroups(value), fdel=lambda self: setattr(self, _comps, None)) Thanks, i found this one too, i have already commit a fix. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] yum-utils 1.0.4 Released.
yum-utils 1.0.4 has been released. (works with yum 3.0.x) The mayor change is that the plugins now runs with plugins enabled, so they will work on RHEL5 where the repos are added by a plugin. Check the Changelog for more changes. Tarball: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.0.4.tar.gz SRPM: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.0.4-1.src.rpm Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] depsolving work
seth vidal wrote:
On Wed, 2007-03-21 at 19:28 +0100, Terje Røsten wrote:
seth vidal
Tim, Terje and Florian in particular, please check out latest cvs and
let me know where it screws up.
Something strange is going on, I will try to explain what I saw:
Doing this (on rawhide i386):
# time echo n | python yummain.py -d100 -e100 install redhat-artwork
/tmp/o.log
Gives:
Without patches: 11s
With patches: 150s!
Not good.
With patches depsolving stops here:
looking at redhat-artwork as a requirement of ('metacity', 'i386', '0',
'2.18.0', '1.fc7')
After 60s (sic!) the next line is
looking to see what requires ('/usr/share/icons/Bluecurve/index.theme',
None, (None, None, None)) of redhat-artwork - 5.0.11-1.fc7.i386
While the next line without patches is:
looking to see what requires ('/etc/gtk-2.0/gtkrc', None, (None, None,
None)) of redhat-artwork - 5.0.11-1.fc7.i386
And a lot of looking to see what requires lines which is not present
in with patches output.
So with patches a lot of files is skipped, however in some strange way
skipping is much more expensive.
I think I know one thing about what's going on and I'm going to see if
comparing the lists as 'sets()' works fast enough or not.
-sv
I was making some measurement and i saw the same problems with
depsolving on redhat-artwork.
but with the latest 1.144 revision of depsolve.py made the problems go away.
here is my current measurement:
# time echo n | ./yummain.py update -C yum-314-all.out
real0m26.103s
user0m19.038s
sys 0m3.160s
# time echo n | ./yummain.py update -C yum-314-all.out
real0m26.145s
user0m19.142s
sys 0m2.895s
# time echo n | ./yummain.py update -C yum-head-all.out
real0m19.626s
user0m10.334s
sys 0m2.422s
# time echo n | ./yummain.py update -C yum-head-all.out
real0m21.451s
user0m10.285s
sys 0m2.521s
Tim
Loading skip-broken plugin
Loading installonlyn plugin
Setting up Update Process
Resolving Dependencies
-- Running transaction check
Checking deps for samba-common.i386 0-3.0.24-5.fc7 - None
Checking deps for yumex.noarch 0-1.9.4-1.0.fc7 - None
Checking deps for libraw1394.i386 0-1.2.1-3.fc7 - u
Checking deps for audit-libs.i386 0-1.5.1-1.fc7 - u
Checking deps for mkinitrd.i386 0-6.0.8-3 - None
Checking deps for xorg-x11-drv-nv.i386 0-2.0.0-1.fc7 - None
Checking deps for gthumb.i386 0-2.10.0-1.fc7 - u
Checking deps for libsmbclient.i386 0-3.0.24-5.fc7 - None
Checking deps for selinux-policy-targeted.noarch 0-2.5.9-2.fc7 - u
Checking deps for openssh-clients.i386 0-4.5p1-6.fc7 - u
Checking deps for samba-common.i386 0-3.0.24-6.fc7 - u
Checking deps for SDL.i386 0-1.2.11-2 - u
Checking deps for selinux-policy.noarch 0-2.5.9-2.fc7 - u
Checking deps for nash.i386 0-6.0.8-4 - u
Checking deps for audit.i386 0-1.5.1-1.fc7 - u
Checking deps for libsmbclient.i386 0-3.0.24-6.fc7 - u
Checking deps for rp-pppoe.i386 0-3.8-1.fc7 - u
Checking deps for parted.i386 0-1.8.6-1.fc7 - u
Checking deps for cups-libs.i386 1-1.2.9-1.fc7 - None
Checking deps for festival.i386 0-1.96-0.11.fc7 - None
Checking deps for warzone2100-data.i386 0-2.0.5-3.fc7 - None
Checking deps for yumex.noarch 0-1.9.5-1.0.fc7 - u
Checking deps for audit.i386 0-1.5-2.fc7 - None
Checking deps for setroubleshoot-server.noarch 0-1.9.3-1.fc7 - None
Checking deps for openssh-server.i386 0-4.5p1-6.fc7 - u
Checking deps for audit-libs-python.i386 0-1.5.1-1.fc7 - u
Checking deps for xorg-x11-drv-nv.i386 0-2.0.0-2.fc7 - u
Checking deps for gdm.i386 1-2.18.0-4.fc7 - None
Checking deps for samba-client.i386 0-3.0.24-6.fc7 - u
Checking deps for warzone2100.i386 0-2.0.5-4.fc7 - u
Checking deps for xorg-x11-drv-vesa.i386 0-1.3.0-4.fc7 - None
Checking deps for festival.i386 0-1.96-1.fc7 - u
Checking deps for openssh.i386 0-4.5p1-5.fc7 - None
Checking deps for gdm.i386 1-2.18.0-5.fc7 - u
Checking deps for setroubleshoot-server.noarch 0-1.9.4-1.fc7 - u
Checking deps for gnome-desktop.i386 0-2.18.0-2.fc7 - None
Checking deps for warzone2100.i386 0-2.0.5-3.fc7 - None
Checking deps for setroubleshoot.noarch 0-1.9.3-1.fc7 - None
Checking deps for desktop-printing.i386 0-0.20-3.fc7 - None
Checking deps for festival-speechtools-libs.i386 0-1.2.96-0.11.fc7 - None
Checking deps for gthumb.i386 0-2.9.3-1.fc7 - None
Checking deps for festvox-slt-arctic-hts.i386 0-0.20061229-0.11.fc7 - None
Checking deps for SDL.i386 0-1.2.11-1 - None
Checking deps for audit-libs-python.i386 0-1.5-2.fc7 - None
Checking deps for selinux-policy.noarch 0-2.5.8-8.fc7 - None
Checking deps for xterm.i386 0-224-2.fc7 - u
Checking deps for cups.i386 1-1.2.10-1.fc7 - u
Checking deps for redhat-artwork.i386 0-5.0.11-1.fc7 - None
Checking deps for selinux-policy-targeted.noarch 0-2.5.8-8.fc7 - None
Checking deps for mkinitrd.i386 0-6.0.8-4 - u
Checking deps for gnome-desktop.i386 0-2.18.0-3.fc7 - u
Checking deps for warzone2100-data.i386 0-2.0.5-4.fc7 - u
Checking deps for festival-speechtools-libs.i386 0-1.2.96-1.fc7 - u
Re: [Yum-devel] depsolving work
seth vidal wrote:
On Wed, 2007-03-21 at 20:33 +0100, Tim Lauridsen wrote:
seth vidal wrote:
On Wed, 2007-03-21 at 19:28 +0100, Terje Røsten wrote:
seth vidal
Tim, Terje and Florian in particular, please check out latest cvs and
let me know where it screws up.
Something strange is going on, I will try to explain what I saw:
Doing this (on rawhide i386):
# time echo n | python yummain.py -d100 -e100 install redhat-artwork
/tmp/o.log
Gives:
Without patches: 11s
With patches: 150s!
Not good.
With patches depsolving stops here:
looking at redhat-artwork as a requirement of ('metacity', 'i386', '0',
'2.18.0', '1.fc7')
After 60s (sic!) the next line is
looking to see what requires ('/usr/share/icons/Bluecurve/index.theme',
None, (None, None, None)) of redhat-artwork - 5.0.11-1.fc7.i386
While the next line without patches is:
looking to see what requires ('/etc/gtk-2.0/gtkrc', None, (None, None,
None)) of redhat-artwork - 5.0.11-1.fc7.i386
And a lot of looking to see what requires lines which is not present
in with patches output.
So with patches a lot of files is skipped, however in some strange way
skipping is much more expensive.
I think I know one thing about what's going on and I'm going to see if
comparing the lists as 'sets()' works fast enough or not.
-sv
I was making some measurement and i saw the same problems with
depsolving on redhat-artwork.
but with the latest 1.144 revision of depsolve.py made the problems go
away.
I swapped out the list for a dict and the look up is, of course, much
faster for large numbers of files/provides.
I may put out a 3.1.5 with this for the moment and work on the
tuple_of_doom changes in 3.1.6 b/c it is more invasive.
suggestions welcome.
-sv
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Just put out a 3.1.5.
I made some more measurements with yumex. see the attached outputs.
Summary:
head : 20s.
314 : 23s
311:46s (2s in second run, with all headers in cache, not a very
usual case)
Tim
Tim
20:54:38 : -- Populating transaction set with selected packages. Please wait.
20:54:38 : --- Downloading header for cairo-devel to pack into transaction set.
20:54:39 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/cairo-devel-1.4.2-1.fc7.i386.rpm
20:54:39 : --- Package cairo-devel.i386 0:1.4.2-1.fc7 set to be updated
20:54:39 : --- Downloading header for cups to pack into transaction set.
20:54:39 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/cups-1.2.10-1.fc7.i386.rpm
20:54:43 : --- Package cups.i386 1:1.2.10-1.fc7 set to be updated
20:54:43 : --- Downloading header for warzone2100-data to pack into
transaction set.
20:54:44 : Getting :
http://ftp.chg.ru/pub/Linux/fedora/linux/extras/development/i386/warzone2100-data-2.0.5-4.fc7.i386.rpm
20:54:44 : --- Package warzone2100-data.i386 0:2.0.5-4.fc7 set to be updated
20:54:44 : --- Downloading header for yumex to pack into transaction set.
20:54:44 : Getting :
http://ftp.chg.ru/pub/Linux/fedora/linux/extras/development/i386/yumex-1.9.5-1.0.fc7.noarch.rpm
20:54:44 : --- Package yumex.noarch 0:1.9.5-1.0.fc7 set to be updated
20:54:44 : --- Downloading header for redhat-artwork to pack into transaction
set.
20:54:44 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/redhat-artwork-5.0.11-2.fc7.i386.rpm
20:54:55 : --- Package redhat-artwork.i386 0:5.0.11-2.fc7 set to be updated
20:54:55 : --- Downloading header for libraw1394 to pack into transaction set.
20:54:56 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/libraw1394-1.2.1-3.fc7.i386.rpm
20:54:56 : --- Package libraw1394.i386 0:1.2.1-3.fc7 set to be updated
20:54:56 : --- Downloading header for mkinitrd to pack into transaction set.
20:54:56 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/mkinitrd-6.0.8-4.i386.rpm
20:54:57 : --- Package mkinitrd.i386 0:6.0.8-4 set to be updated
20:54:57 : --- Downloading header for cairo to pack into transaction set.
20:54:57 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/cairo-1.4.2-1.fc7.i386.rpm
20:54:57 : --- Package cairo.i386 0:1.4.2-1.fc7 set to be updated
20:54:57 : --- Downloading header for gnome-desktop to pack into transaction
set.
20:54:58 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/gnome-desktop-2.18.0-3.fc7.i386.rpm
20:54:58 : --- Package gnome-desktop.i386 0:2.18.0-3.fc7 set to be updated
20:54:58 : --- Downloading header for audit-libs to pack into transaction set.
20:54:59 : Getting :
http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/Fedora/audit-libs-1.5.1-1.fc7.i386.rpm
[Yum-devel] yum 3.1.5 looks much better.
I did the following in Fedora Rawhide Today. #yum clean all #yum makecache #time echo n | yum update -C Transaction Summary = Install 2 Package(s) Update 52 Package(s) Remove 2 Package(s) Total download size: 89 M real3m20.373s user2m21.146s sys 0m15.843s #yum update yum (upodates yum-3.1.4 - yum-3.15) #time echo n | yum update -C Transaction Summary = Install 2 Package(s) Update 50 Package(s) Remove 2 Package(s) Total download size: 89 M real0m34.567s user0m20.431s sys 0m3.746s 3m20s - 34s, that a big improvment. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Please help
Nello wrote: Hi. i got big problems with yum. I do not know what to do... Nothing works... I do not want to reinstall my fedora all the time. Please help :) It would be nice if i get a command line i can paste in to download and install, overwriting my old one. I was about to run a restore on my computer because of this, but that isnt nessesary is it? I have read a lot, but i just can't figure it out. I would do anything to get my computer up and running. --- PS. I do not have python, so i am realy stuck. 5 days with linux :) Lars ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel HI Lars You have mailed the wrong list, try the Fedora mailing list[1] or Fedora Forum[2] , This list is for yum development discussions. Best Regards, TIm [1] : http://fedoraproject.org/wiki/Communicate/MailingListGuidelines [2] : http://www.fedoraforum.org ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum 3.1.6 and yum-metadata-parser 1.0.4
jonathan pickard wrote:
jonathan pickard wrote:
seth vidal wrote:
Hi all,
Yum 3.1.6 and yum-metadata-parser 1.0.4 are released.
[snip]
Hi
I have upgraded to yum 3.1.6 and upgraded the metadata-parser to 1.0.4,
I also have the following plugins installed:
kernel-module plugin
fedorakmod plugin
skip-broken plugin
# yum list yum*
Excluding Packages in global exclude list
Finished
Installed Packages
yum.noarch
3.1.6-1installed
yum-fedorakmod.noarch1.1.1-1
installed
yum-kernel-module.noarch1.1.1-1
installed
yum-metadata-parser.i386 1.0.4-1
installed
yum-skip-broken.noarch 1.1.1-1
installed
yum-utils.noarch 1.1.1-1
installed
When i run yum update with plugins=1 set in my yum.conf file i get:
# yum update
Loading kernel-module plugin
Loading fedorakmod plugin
Loading skip-broken plugin
Setting up Update Process
Excluding Packages in global exclude list
Finished
Resolving Dependencies
Traceback (most recent call last):
File /usr/bin/yum, line 29, in ?
yummain.main(sys.argv[1:])
File /usr/share/yum-cli/yummain.py, line 135, in main
(result, resultmsgs) = base.buildTransaction()
File /usr/lib/python2.4/site-packages/yum/__init__.py, line 543, in
buildTransaction
self.plugins.run('preresolve')
File /usr/lib/python2.4/site-packages/yum/plugins.py, line 162, in run
func(conduitcls(self, self.base, conf, **kwargs))
File /usr/lib/yum-plugins/kernel-module.py, line 60, in preresolve_hook
instpkgs = conduit.getRpmDB().getPackages()
AttributeError: 'RPMDBPackageSack' object has no attribute 'getPackages'
When i run yum update with plugins=0 set in my yum.conf file i get:
# yum update
Setting up Update Process
Excluding Packages in global exclude list
Finished
Resolving Dependencies
-- Running transaction check
--- Package ImageMagick.i386 0:6.2.8.0-4.fc6 set to be updated
Checking deps for ImageMagick.i386 0-6.2.8.0-4.fc6 - u
Checking deps for ImageMagick.i386 0-6.2.8.0-3.fc6.1 - None
[snip]
--- Package redhat-rpm-config.noarch 0:8.0.45-9.fc6 set to be updated
Checking deps for redhat-rpm-config.noarch 0-8.0.45-9.fc6 - u
Checking deps for evolution-data-server.i386 0-1.8.3-2.fc6 - None
Dependencies Resolved
=
Package Arch Version RepositorySize
=
Installing:
kernel-develi686 2.6.20-1.2933.fc6 updates
4.8 M
Updating:
[snip]
Transaction Summary
=
Install 1 Package(s)
Update 28 Package(s)
Remove 0 Package(s)
Total download size: 72 M
Is this ok [y/N]:
Apologies for replying to my own post - but if i disable to
kernel-module plugin then the update works.
and.. on my FC6 machine yum is significantly quicker than the .5
and .4 versions
Thanks
There is a problem with the kernel-module plugin in yum-utils-1.1.1, it
is fix in CVS and will be fixed in yum-utils-1.1.2.
You can grab a fixed kernel-module.py here:
http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum-utils/plugins/kernel-module/kernel-module.py?view=co
and place it in /usr/lib/yum-plugins.
Tim
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] New plugin: merge-conf
Aurelien Bompard wrote:
Hi yummers,
There's a feature of another package manager that I like: when a config file
has changed, it asks you if you want to keep your local copy or if you want
to install the package's version. RPM is non-interactive, so it's not
supposed to do this. But I thought this could be implemented in a yum
plugin.
I've written a plugin which does just that:
http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py
http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.3-1.noarch.rpm
Add the --merge-conf command line option to your yum update, and it will ask
you what to do with those .rpm{save,new} files as the packages are
installed. You'll be able to diff the files, choose your version, run
vimdiff on them, or spawn a shell to check further.
It should work with yum 3.0.x and yum 3.1.x at least. Please have a look,
the code is pretty easy. Since it's my first yum plugin and I'm not
completely familiar with the yum api, I'm sure it could use some love, so
please tell me what I can improve.
Thanks,
Aurélien
Hi Aurélien.
It looks good to me, if you want i can add to the other plugins in
yum-utils.
Tim
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yumdownloader (1.1.2/3.1.6) with --installroot
Charlie Brady wrote: On Thu, 12 Apr 2007, Charlie Brady wrote: AttributeError: 'NoneType' object has no attribute 'name' This patch to /usr/lib/python2.4/site-packages/yum/packages.py fixed that little problem: def __eq__(self, other): # if other == None: # return False if comparePoEVR(self, other) == 0 and self.arch == other.arch and self.name == other.name: return True return False This is still a problem in yum 3.1.6, but I notice fixed in CVS. So now I'm trying again, but with yum-3.1.6 and yum-install-1.1.2. I now find that yumdownloader requires various things to already exist in the installroot which it was happy and able to create in the earlier version. Specifically it expects the installroot to already include an rpmdb and cache directories for each repository (both of which I've found workarounds for), and then also demands to find a pre-cached repomd.xml file per repository. Are these intentional changes of behaviour, or are they regressions which I can help to debug? Here's the problem: ... self.conf.uid = os.geteuid() -if self.conf.uid != 0: - self.conf.cache = 1 ... After commenting out that code, and making the following changes to yumdownloader, I find that latest releases do indeed do a *much* better job at resolving dependencies. --- yumdownloader-1.1.2.orig2007-04-12 13:56:36.0 -0400 +++ yumdownloader-1.1.2 2007-04-12 16:40:20.0 -0400 @@ -24,6 +24,9 @@ from urlparse import urljoin +from urlgrabber.progress import TextMeter +import shutil + class YumDownloader(YumUtilBase): NAME = 'yumdownloader' VERSION = '1.0' ___ Yum-devel mailing list [EMAIL PROTECTED] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Thanks, i will add you changes to yumdownloader in yum-utils- 1.1.x. Tim ___ Yum-devel mailing list [EMAIL PROTECTED] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [PATCH] Dont force non root user to run in cache
I have created a patch to make yumdownloader work as non root with an install root. Can anybody see any problems with this. i should not affect cli user, because the cli setup code sets, self.conf.cache=1 for nonroot users. Tim ### Eclipse Workspace Patch 1.0 #P yum Index: yum/__init__.py === RCS file: /home/groups/yum/cvs/yum/yum/__init__.py,v retrieving revision 1.317 diff -u -r1.317 __init__.py --- yum/__init__.py 8 Apr 2007 15:59:59 - 1.317 +++ yum/__init__.py 13 Apr 2007 11:21:34 - @@ -150,8 +150,6 @@ # who are we: self.conf.uid = os.geteuid() -if self.conf.uid != 0: -self.conf.cache = 1 self.doFileLogSetup(self.conf.uid, self.conf.logfile) ___ Yum-devel mailing list [EMAIL PROTECTED] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Lazy initialization of mirror lists
James Bowes wrote: James Bowes wrote: It breaks everything right now. self.grabfunc = ... in _setupGrab should be self._grabfunc It also didn't set up the callbacks properly. Attached is a more working version. -James +urls = property(lambda self: self._geturls()) I think it will be a good idea to 'fset' and 'fdel' funtions to the urls property so it can be urls get be reset and overwritten by plugins and API programs. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum-security plugin review, possible merge into yum-utils?
James Antill wrote: On Fri, 2007-04-13 at 07:44 +0200, Terje Røsten wrote: James Antill 2. If you remove _everything_ in the preresolve_hook (think security only updates, when there are none) you end up with an empty transaction. At which point nothing in yum spots this and asks the user to confirm a transaction that does nothing. I have seen the same issue with Tim's skip-broken plugin when everything is broken :-) *nods* ... here's the obvious fix for that against current CVS: Index: depsolve.py === RCS file: /cvsroot/yum/cvs/yum/yum/depsolve.py,v retrieving revision 1.160 diff -u -p -r1.160 depsolve.py --- depsolve.py 17 Apr 2007 20:54:03 - 1.160 +++ depsolve.py 18 Apr 2007 20:50:15 - @@ -795,6 +795,8 @@ class Depsolve(object): if not deps: # FIXME: this doesn't belong here at all... +if not len(self.tsInfo): +return (0, ['Success - empty transaction']) for txmbr in self.tsInfo.getMembers(): if self.allowedMultipleInstalls(txmbr.po) and \ txmbr.ts_state == 'u': ...this works for me(tm). Look sane to me, i have submitted it to CVS Head. Did anyone have a look at the plugin itself and have any comments/questions? The plugin look very nice, good example of how to extend the yum command by a plugin. If you like i can add the plugins to yum-utils. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] --installroot behavioural change ...
Alan Milligan wrote: Hi, In the 3.0.x series of yum, the --installroot argument worked such that it cd/chroot'ed to this dir and *then* looked for /etc/yum.conf. In 3.1.6, it binds to /etc/yum.conf outside the installroot. This is a complete PITA when used with mock - my chroot is no longer the sandbox I thought it was - someone's kicked over my castle!! Is this something that someone will restore, or should I now modify my mock to pass yum -c?? Alan ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel I should work in the same ways in yum 3.1.x, but the problem is that the default yum.conf location has changed from /etc/yum.conf to /etc/yum/yum.conf, if you don't use an installroot, then yum will fall back to use /etc/yum.conf if /etc/yum/yum.conf is used. But if you use an installroot it will check for '/your/install/root/etc/yum/yum.conf' and it not exist then /etc/yum.conf will be used. It will try to make it work a little smarter. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] 3.2.X and stuff to do
seth vidal wrote: 2. don't branch, release 3.2.0 off of HEAD and continue working on HEAD but w/o breaking the API while we stabilize and work on new items. +1 Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] post 3.2.0 things to think about
seth vidal wrote: Some other brainstorms as I've been sitting around and talking to folks on jabber and irc. Some of these are things to add into yum, others are just things to implement as yum-utils - but feedback on the stupidity of some of these items is welcome, in no particular order: 1. supporting gpg/x509 signatures detached from repomd.xml on each repo - so we can check the content for validity Sounds like a good thing. 2. yum-util system-sync - to make two systems more or less identical pkg-wise to each other (maybe also spit out a %packages section to a ks.cfg, too) Sound good too. 3. taking the 'tolerant' config option in yum and using it to implement what the --skip-broken plugin does (more or less) but internal to yum +1, It is implemented as a class, so i could be move into yum, then it could be called by the yum-cli and the gui's. A more advanced approach is to build it into the depsolver, so it contruct a list packages with problems, there can be skipped if the option is set. It could be made default like in apt-get, reporting that the following packages could not be updated because for dep errors. 4. in general look at the plugins and utils and see what features would be better off in the base code or vice-versa. Is there core code that should really go live in a plugin Sound good to me, maybe some priorities or protectbase stuff, to make it easier to protect base packages from being overwritten på other repos. 5. yum-gate - take the code that rnorwood posted and maybe work on making it more releasable for folks to use as an authenticated yum repo. Alternatively, look at one of the other system-config-mgmt tools to work for that. I have just got some patches from another IBM'er, that make changes to UG and yum to support a client side SSL cert. I will post it on the list. 6. YumBase.install() has a pattern=pkgglob kwarg it takes, remove() and update() don't. I want to fix that. If for no other reason than to make the yum cli code simpler. Any of those things seem cool or silly? -sv * Switch from CVS to a distributed SCM like mercurial. * yum list vendors List install packages and the rpm vendors, there have been a lot of discussions on the EPEL list, about repotag as a way to locate the source of the packages, because the basic packages tools like yum don't show it in a simple way. * make some generic callback handler in yumbase there can be subcased by applications using yum API. Example: http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/yumex/src/yumgui/callbacks.py?view=markup. * yumlets :-) A sort of metapackage that contains a collection of packages and yum metadat, a sort of mini repo compressed into a single file. It could be very useful in there part of world where the broadband connection is very expensive. It could work like this. yum install /path/or/url/to/yumlet. Then yum would extract the packages and metadata in at special local yumlets repo cache and install the packages from there. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [UG][PATCH][1/2] Support for clientside SSL cert.
I got the following patches from Eric J. Barkie. Purpose: The main purpose of the client-side certificate patch is for restricting access to repositories when dealing with licensed RPMS/distributions, ie: RHEL. The typical use would be to generate a CA and then with that CA issue a certificate to each machine that will be running yum. The main repository would be hosted with Apache under mod_ssl with the SSLCACertificateFile set to your CA and SSLVerifyClient set to require. By doing this Apache takes care of the authentication and we can ensure that the yum repository can only be accessed by the intended clients. Take a look and let me know what you think. Tim --- urlgrabber-3.1.0/urlgrabber/grabber.py.orig 2006-12-26 13:48:26.0 -0500 +++ urlgrabber-3.1.0/urlgrabber/grabber.py 2006-12-26 13:49:02.0 -0500 @@ -809,6 +809,7 @@ self.urlparser = URLParser() self.quote = None self.ssl_ca_cert = None +self.ssl_client_cert = None self.ssl_context = None class URLGrabber: @@ -1045,7 +1046,7 @@ # --- ssl_factory = sslfactory.get_factory(self.opts.ssl_ca_cert, -self.opts.ssl_context) +self.opts.ssl_client_cert, self.opts.ssl_context) if need_keepalive_handler: handlers.append(HTTPHandler()) --- urlgrabber-3.1.0/urlgrabber/sslfactory.py.orig 2006-12-26 13:33:48.0 -0500 +++ urlgrabber-3.1.0/urlgrabber/sslfactory.py 2006-12-26 14:51:13.0 -0500 @@ -34,21 +34,24 @@ class M2SSLFactory: -def __init__(self, ssl_ca_cert, ssl_context): -self.ssl_context = self._get_ssl_context(ssl_ca_cert, ssl_context) +def __init__(self, ssl_ca_cert, ssl_client_cert, ssl_context): +self.ssl_context = self._get_ssl_context(ssl_ca_cert, ssl_client_cert, ssl_context) -def _get_ssl_context(self, ssl_ca_cert, ssl_context): +def _get_ssl_context(self, ssl_ca_cert, ssl_client_cert, ssl_context): -Create an ssl context using the CA cert file or ssl context. +Create a ssl context using the CA cert file and/or the client cert file or ssl context. -The CA cert is used first if it was passed as an option. If not, -then the supplied ssl context is used. If no ssl context was supplied, +The CA cert and client cert are used first if either or both are passed as an options. +If not, then the supplied ssl context is used. If no ssl context was supplied, None is returned. -if ssl_ca_cert: +if ssl_ca_cert or ssl_client_cert: context = SSL.Context() -context.load_verify_locations(ssl_ca_cert) -context.set_verify(SSL.verify_peer, -1) +if ssl_ca_cert: +context.load_verify_locations(ssl_ca_cert) +context.set_verify(SSL.verify_peer, -1) +if ssl_client_cert: +context.load_cert(ssl_client_cert) return context else: return ssl_context @@ -76,10 +79,10 @@ -def get_factory(ssl_ca_cert = None, ssl_context = None): +def get_factory(ssl_ca_cert = None, ssl_client_cert = None, ssl_context = None): Return an SSLFactory, based on if M2Crypto is available. if have_m2crypto: -return M2SSLFactory(ssl_ca_cert, ssl_context) +return M2SSLFactory(ssl_ca_cert, ssl_client_cert, ssl_context) else: # Log here if someone provides the args but we don't use them. if ssl_ca_cert or ssl_context: ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] post 3.2.0 things to think about
Charlie Brady wrote: On Thu, 3 May 2007, James Bowes wrote: seth vidal wrote: * Switch from cvs to git is git the clear winner on the distributed SCM wars? I always lose track. Yes. In some circles, perhaps. Mercurial is also widely used, very easy to use and does a very good job. I also like Mercurial too, it is very easy to use. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] post 3.2.0 things to think about
Panu Matilainen wrote: On Thu, 3 May 2007, Michael E Brown wrote: On Thu, May 03, 2007 at 05:11:46PM -0400, seth vidal wrote: On Thu, 2007-05-03 at 09:18 +0200, Tim Lauridsen wrote: * yum list vendors List install packages and the rpm vendors, there have been a lot of discussions on the EPEL list, about repotag as a way to locate the source of the packages, because the basic packages tools like yum don't show it in a simple way. Can't repoquery do this? Sure it can but... I think the point there is that we want to list the vendor at all times whenever we display the package name. The example given was something like this: core os package: foo-1.0-1.fc6.i386.rpm files: /bin/file1, /bin/file2 evil repo package: foo-1.1-1.fc6.i386.rpm files: /bin/file1, /bin/file2, /bin/file3 good repo package: bar-1.0-1.fc6.i386.rpm files: /bin/file3, /bin/file4 user does: 1) install system 2) configure evil repo 3) yum upgrade (upgrades foo) 4) configure good repo 5) yum install bar WTF?! Why does the [EMAIL PROTECTED]@ bar package in good repo conflict with my BASE OS package foo??? Dont they even test this stuff? The user then proceeds to berate admin of good repo, even though it was actually evil repo's fault. If, when you gave the conflict message (/bin/file3 from package foo conflicts with /bin/file3 from package bar), you also mentioned the vendor, that might allevate some problems. (/bin/file3 from package foo, vendor 'evil repo' conflicts with file /bin/file3 from package bar, vendor 'goot repo') Been reading the EPEL repotag flamewars I see :) And yes, I agree, dragging the vendor string out of the dark cave it's been hiding in all these years would seem to be a good thing. It's just that screen estate is already a scarce resource, there's no room on 80char terminal to put the potentially lengthy vendor string into, unless per-package info is split on two lines. This is why i think something like yum list vendors could be nice, i could show something like this foo-1.0-1.fc7.i386 Vendor X bar-1.0-2.fc7.noarch Vendor Y Of course that's not an issue with GUI', no reason not to make vendor string visible in yumex, pirut etc. I plan to do so in yumex. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] post 3.2.0 things to think about
seth vidal wrote: On Fri, 2007-05-04 at 08:33 +0200, Tim Lauridsen wrote: Panu Matilainen wrote: On Thu, 3 May 2007, Michael E Brown wrote: On Thu, May 03, 2007 at 05:11:46PM -0400, seth vidal wrote: On Thu, 2007-05-03 at 09:18 +0200, Tim Lauridsen wrote: * yum list vendors List install packages and the rpm vendors, there have been a lot of discussions on the EPEL list, about repotag as a way to locate the source of the packages, because the basic packages tools like yum don't show it in a simple way. Can't repoquery do this? Sure it can but... I think the point there is that we want to list the vendor at all times whenever we display the package name. The example given was something like this: core os package: foo-1.0-1.fc6.i386.rpm files: /bin/file1, /bin/file2 evil repo package: foo-1.1-1.fc6.i386.rpm files: /bin/file1, /bin/file2, /bin/file3 good repo package: bar-1.0-1.fc6.i386.rpm files: /bin/file3, /bin/file4 user does: 1) install system 2) configure evil repo 3) yum upgrade (upgrades foo) 4) configure good repo 5) yum install bar WTF?! Why does the [EMAIL PROTECTED]@ bar package in good repo conflict with my BASE OS package foo??? Dont they even test this stuff? The user then proceeds to berate admin of good repo, even though it was actually evil repo's fault. If, when you gave the conflict message (/bin/file3 from package foo conflicts with /bin/file3 from package bar), you also mentioned the vendor, that might allevate some problems. (/bin/file3 from package foo, vendor 'evil repo' conflicts with file /bin/file3 from package bar, vendor 'goot repo') Been reading the EPEL repotag flamewars I see :) And yes, I agree, dragging the vendor string out of the dark cave it's been hiding in all these years would seem to be a good thing. It's just that screen estate is already a scarce resource, there's no room on 80char terminal to put the potentially lengthy vendor string into, unless per-package info is split on two lines. This is why i think something like yum list vendors could be nice, i could show something like this foo-1.0-1.fc7.i386 Vendor X bar-1.0-2.fc7.noarch Vendor Y is there a sensible situation when a single repo will have more than one vendor contributing the same package name/arch? or are you meaning only for installed pkgs? Only for installed packages, i want a easy way to show the source of the packages, the same info that a repotag will give you, but there is no repo info in the rpmdb, the best available info is the vendor field. If yum contained some kind of transaction database, it could be a place to store the source of each package. If it is for installed pkgs we'd almost be better off recording the repo a package was installed FROM elsewhere. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum-security plugin review, possible merge into yum-utils?
Luke Macken wrote: On Tue, Apr 24, 2007 at 09:34:33AM -0400, James Antill wrote: o ysp_show_pkg_md_info() -- This looks like it would best fit into yum.update_md.UpdateNotice.__str__. Right now the __str__ for UpdateNotices is a bit ugly, but improvements are definitely welcome, and that seems like the place to do something like this. Very much so, but I didn't want to just reassign parts of the class. If you think it's good to change it though, feel free to replace the __str__ function and then delete that function with a simple print. I committed some cleanups to the yum.update_md.UpdateNotice.__str__ method. Attached is a patch to utilize it for the yum-security plugin. This patch is generated against CVS HEAD + yum-security-plugin.patch from your last email. So info-sec now looks like this: [EMAIL PROTECTED] ~]$ sudo yum --security info-sec Loading security plugin Loading fastestmirror plugin Loading installonlyn plugin Loading mirror speeds from cached hostfile === mutt-1.5.14-3.fc7 === Update ID : FEDORA-2007-0001 Release : Fedora Core 7 Type : security Status : testing Issued : 2007-05-07 23:27:54.125243 Bugs : 123 - netstat -M problem : 23425 - Bugzilla omits the bugzilla report item for bug reports CVEs : CVE-2007- Description : foobar Files : mutt-debuginfo-1.5.14-3.fc7.i386.rpm : mutt-1.5.14-3.fc7.i386.rpm : mutt-1.5.14-3.fc7.src.rpm info-sec done Feel free to make any tweaks to the output that you want. luke ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Hi Luke and James I have added the latest 2 patches to the security plugin in yum-utils CVS, please checkout that every thing works as expected. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] PATCH: Add '--disableplugin' option to temporary disable a plugin.
Hi,
I have created a patch to add a '--disableplugin' option,
ex.
yum --disableplugin=installonlyn list yum
Just want to make a sanity check, before commiting :-)
Tim
### Eclipse Workspace Patch 1.0
#P yum
Index: yum/plugins.py
===
RCS file: /home/groups/yum/cvs/yum/yum/plugins.py,v
retrieving revision 1.39
diff -u -r1.39 plugins.py
--- yum/plugins.py 26 Apr 2007 04:00:24 - 1.39
+++ yum/plugins.py 3 Jun 2007 17:25:14 -
@@ -106,7 +106,7 @@
'''
def __init__(self, base, searchpath, optparser=None, types=None,
-pluginconfpath=None):
+pluginconfpath=None,disabled=None):
'''Initialise the instance.
@param base: The
@@ -128,6 +128,7 @@
self.optparser = optparser
self.cmdline = (None, None)
self.verbose_logger = logging.getLogger(yum.verbose.YumPlugins)
+self.disabledPlugins = disabled
if not types:
types = ALL_TYPES
@@ -227,6 +228,10 @@
if plugintype not in types:
return
+# Check if this plugin has been temporary disabled
+if self.disabledPlugins:
+if modname in self.disabledPlugins:
+return
self.verbose_logger.log(logginglevels.INFO_2, 'Loading %s plugin',
modname)
Index: yum/__init__.py
===
RCS file: /home/groups/yum/cvs/yum/yum/__init__.py,v
retrieving revision 1.328
diff -u -r1.328 __init__.py
--- yum/__init__.py 29 May 2007 15:52:33 - 1.328
+++ yum/__init__.py 3 Jun 2007 17:25:14 -
@@ -110,7 +110,7 @@
def _getConfig(self, fn='/etc/yum/yum.conf', root='/', init_plugins=True,
plugin_types=(plugins.TYPE_CORE,), optparser=None, debuglevel=None,
-errorlevel=None):
+errorlevel=None,plugin_disabled=None):
'''
Parse and load Yum's configuration files and call hooks initialise
plugins and logging.
@@ -126,6 +126,7 @@
level will be read from the configuration file.
@param errorlevel: Error level to use for logging. If None, the debug
level will be read from the configuration file.
+@param plugin_disabled: Plugins to be disabled
'''
if self._conf:
@@ -148,7 +149,7 @@
if init_plugins and startupconf.plugins:
self.doPluginSetup(optparser, plugin_types, startupconf.pluginpath,
-startupconf.pluginconfpath)
+startupconf.pluginconfpath,plugin_disabled)
self._conf = config.readMainConfig(startupconf)
# run the postconfig plugin hook
@@ -258,7 +259,7 @@
self.plugins = plugins.DummyYumPlugins()
def doPluginSetup(self, optparser=None, plugin_types=None, searchpath=None,
-confpath=None):
+confpath=None,plugin_disabled=None):
'''Initialise and enable yum plugins.
Note: _getConfig() will initialise plugins if instructed to. Only
@@ -275,12 +276,13 @@
@param confpath: A list of directories to look in for plugin
configuration files. A default will be used if no value is
specified.
+@param plugin_disabled: Plugins to be disabled
'''
if isinstance(plugins, plugins.YumPlugins):
raise RuntimeError(plugins already initialised)
self.plugins = plugins.YumPlugins(self, searchpath, optparser,
-plugin_types, confpath)
+plugin_types, confpath, plugin_disabled)
def doRpmDBSetup(self):
Index: cli.py
===
RCS file: /home/groups/yum/cvs/yum/cli.py,v
retrieving revision 1.269
diff -u -r1.269 cli.py
--- cli.py 24 May 2007 00:48:35 - 1.269
+++ cli.py 3 Jun 2007 17:25:13 -
@@ -127,7 +127,7 @@
# Parse only command line options that affect basic yum setup
opts = self.optparser.firstParse(args)
-
+
# Just print out the version if that's what the user wanted
if opts.version:
print yum.__version__
@@ -143,7 +143,9 @@
plugin_types=(yum.plugins.TYPE_CORE,
yum.plugins.TYPE_INTERACTIVE),
optparser=self.optparser,
debuglevel=opts.debuglevel,
-errorlevel=opts.errorlevel)
+errorlevel=opts.errorlevel,
+plugin_disabled=opts.disableplugins)
+
except yum.Errors.ConfigError, e:
self.logger.critical(_('Config Error: %s'), e)
sys.exit(1)
@@ -1086,7 +1088,7 @@
try:
args = _filtercmdline(
('--noplugins','--version'),
-('-c', '-d', '-e', '--installroot'),
+
Re: [Yum-devel] [Patch] Resolver Performance and Correctness
seth vidal wrote: On Wed, 2007-06-06 at 10:24 +0300, Panu Matilainen wrote: On Tue, 5 Jun 2007, Jeremy Katz wrote: The other thing that would be nice (and you alluded to below) would be actually splitting into a patch series. As it stands right now, it's a good sized diff and it's hard to analyze pieces independently. Which really is important both for review and later bisection in case of problems. I know it makes things a lot less fun as you have to do things like move old code around first and then replace it, but it will make things a lot clearer. And fwiw, either using quilt or doing a local import to a git or hg or bzr repo makes doing things like this a lot simpler. thread hijack Would be even nicer if yum code was in git/hg repository to begin with :) Pretty please? /thread hijack I'll say what I've continued to say: Which one is going to be the 'winner' git or hg? I've looked at both and for yum's purposes they appear to be indistinguishable. So, what's the preference these days? Are the cool kids using git or hg? I'm going to go read the cvs-$scm docs and see which annoys me the least. -sv I have tried bot hg and git, hg seams easier to use at first look, but tools like Cogito[1] makes git easier to use. both ones will be fine with me. What troubles me a little, is the warning Jesse[2] sent about hg. Tim [1] : http://git.or.cz/cogito/ [2]: https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003630.html ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH/RFC] What to do if a plugin fails to load?
James Antill wrote:
On Wed, 2007-06-13 at 15:15 -0400, Jeremy Katz wrote:
On Wed, 2007-06-13 at 14:52 -0400, Matthew Miller wrote:
On Wed, Jun 13, 2007 at 02:43:13PM -0400, Jeremy Katz wrote:
In some cases (especially on distro upgrades where you have to do
further updates after the fact), loading plugins can fail to load for
various reasons. We should probably be tolerant of that and just not
load them. What do people think of the attached?
Not to make things more difficult, but some plugins may be more vital than
others -- in some cases, running with a plugin disabled may really screw up
the system. (For example, protectbase.)
Yeah, that's what makes things hard... but blowing up with a traceback
of ImportError is almost certainly the wrong failure mode.
Personally, I can't think of any major cases[1] where a plugin is going
to be so important that it's better to not run yum at all.
Even when you have edge cases like yum-security is broken, it's almost
certainly better to have yum --security update -y do a full update in
than to just fail and do nothing, even if it has a good error message.
How about making failure mode a
standard configuration option in the conf file for each plugin?
And then you get to what if reading the conf file fails?
Realistically, we just need to decide on a line and stick to it. Either
a) Failure to load a plugin just disables the plugin
b) Failure to load a plugin aborts with a nice-ish error message
My patch is the former, partially because it's the easier thing to
implement but also because getting out of the latter case is still not
obvious or simple for end-users.
The obvious candidate, for the second approach, would be something
like:
try:
module = imp.load_module(modname, fp, pathname, description)
+except ImportError:
+raise PluginYumExit('%s plugin failed to load; use --noplugins'
% modname)
...but as I said, I think your approach is better.
[1] In theory it might be better to abort immediately, for query
commands like:
yum --security list updates
...which is done on the cmd line, but even then it's fairly easy to see
what's gone wrong ... and someone running that from cron just before an
update will likely disagree.
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
My proposal is this one.
try:
module = imp.load_module(modname, fp, pathname, description)
except ImportError:
raise PluginYumExit('%s plugin failed to load; use
--disableplugin' % modname)
--disableplugin=plugin name is a new feature added to current yum CVS Head.
The GUI's like pirut yumex can catch the exception and ask the user what to
do.
The CLI just bails out, with a message to the user to solve the issue. Maybe it
should print the Stack trace so there is a way to
se what goes wrong in the plugin.
Tim
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum 3.2.1?
Jeremy Katz wrote: So, I think we've probably got a sufficient number of important bug fixes that it's worth getting a yum 3.2.1 out in the near future. I would love to see a yum 3.2.1 soon, i get a lot of yumex bugzilla reports because of a bug in config.py (fixed in CVS). Anyone know of anything really important that we should fix that we haven't yet? I am not aware anything impotent bugs not fixed yet. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Re: take two: protect-packages plugin
Matthew Miller wrote:
Also, Sveta says: wait, don't send that yet, change this:
confdir = conduit.confString('main','confdir')
if not confdir:
confdir = /etc/sysconfig/
to
confdir = conduit.confString('main','confdir','/etc/sysconfig')
.
Which I *will* take credit for, because I'm the one that suggested the
roundabout way.
I look fine to me, the only minor issues is the indentation, all other
yum stuff uses 4 spaces for indentation, this plugin 'uses 2, 3 and
sometime 4 spaces, it only a minor issue, so i have added it to
yum-utils CVS, it will be available in next yum-utils release.
Tim
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Introduce new error for no more mirrors
James Bowes wrote: On Wed, Jun 27, 2007 at 01:35:18PM -0400, Jeremy Katz wrote: When downloading, it can be useful to distinguish between an error due to no more mirrors being available and other errors. Attached patch adds a new error type so that if you care, you can catch it instead and then uses it in yumRepo._getFile(). Sound reasonable? Better ideas? Looks good. More specific exceptions classes are nice to have. -James +1 Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Persistent enable/disable of repositories.
seth vidal wrote: On Thu, 2007-07-05 at 03:04 +0530, Debarshi 'Rishi' Ray wrote: Please find attached a patch to incorporate the persistent enable/disable of repositories by editing the .repo files. Repositories mentioned in yum.conf are still not supported. This is done using the following two methods: YumRepository.enablePersistent(self) YumRepository.disablePersistent(self) This is just a proof of concept and your comments are awaited. the only thing I've noticed from your patch is that the following behavior, which works now will no longer work: /etc/yum/repos.d/bar.repo [bar] name=bar /etc/yum/repos.d/foo.repo baseurl=url://bar/repo enabled=1 [foo] name=foo /etc/yum/repos.d/quux.repo baseurl=url://foo/repo enabled=0 [quux] name=quux baseurl=url://quux/repo enabled=1 currently we concatenate all the .repo files then parse them (also we end up with a single parser instance) In your patch we'd have a parser instance for each of them and they would not be concatenated. now, I don't really have a problem with losing that behavior b/c I'm betting it is next to never used since most people who had not looked at that section of the code would never know how it happened anyway. :) However, What does everyone else think? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Besides the problems Seth already has found, There is 2 problem with writing repo back to disk. 1. The order of the options, they will be kind of mixed. i should be. [foorepo]' name=this is the foo repo baseurl= or mirrorlist= enabled=0/1 otheroptions. 2. out commented options and comments will be lost. 1. and the problems Seth talked about i have solved in system-config-repo 2. is solved in repoman. I will try to cook something together there there fits into the current yum config code, so it can save stuff in the right place and order without losing comments Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Persistent enable/disable of repositories.
Debarshi 'Rishi' Ray wrote: Sorry I did notice this before, but these problems in ConfigParser seem to be well discussed at http://wiki.python.org/moin/ConfigParserShootout I will try to cook something together there there fits into the current yum config code, so it can save stuff in the right place and order without losing comments Personally I did not like the way repoman mucks around with the file parsing. I saw RUM (the original one written by Ximian) use the ConfigParser way to handle things, which seemed more cleaner. I agree. In any case I will re-write this using some other parsing module. Let me try. Happy hacking, Debarshi Your welcome Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Persistent enable/disable of repositories.
Tim Lauridsen wrote: Debarshi 'Rishi' Ray wrote: In any case I will re-write this using some other parsing module. Let me try. Done, using cfgparse (http://pages.cs.wisc.edu/~param/software/cfgparse/) which preserves the ordering of the options and the comments. Good thing is that cfgparse provides an additional interface backward compatible with ConfigParser. So something like this is possible: try: from cfgparse.compat import ConfigParser except ImportError: from ConfigParser import ConfigParser without affecting the remaining code, although the absence of cfgparse will result in loss of comments and ordering of options. Will send the patch after some more testing. Happy hacking, Debarshi Look fine, the only issue to solve is to keep track of of witch section (repos) is stored in witch .repo file, so if on repo is enabled/disabled, all other section was to written to the same file. in system-config-repo is use some dictionaries to keep track of the section (repo) to file relation. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel No voodoo magic, witch should have been which :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Persistent enable/disable of repositories.
Debarshi 'Rishi' Ray wrote: It's a little concerning that there's only one release (0.1) and that was in 2004 and apparently nothing since. I wonder if it's worth sort of taking and building on within yum proper rather than adding the dependency. I posted an older link. The latest one is above, and the latest version is 1.2. But the good thing is that I tested it out against the 0.1 release and it worked absolutely fine. Hoping that version 1.2 would be even better. ;-) There are actually two modules by the same name. The 0.1 is by Paramjit Oberoi (http://pages.cs.wisc.edu/~param/software/cfgparse/), while the v1.2 one is by Dan Gass (http://cfgparse.sourceforge.net/) Among all the alternatives at http://wiki.python.org/moin/ConfigParserShootout, the unmaintained module by Paramjit Oberoi seems to be the most appropriate for our use. A ConfigParser compatible interface, which respects comments and the ordering of the options. Every thing else seems to be either an overkill, or too complicated. So Jeremy are you suggesting that we copy Paramjit Oberoi's code verbatim into the YUM code base? Since the parser code is only 3 files, will someone be interested in maintaining it? I took a look at the code, it looks nice, i agree with Jeremy that pull the code into yum code base is the best way to go. I will be glad to maintain it. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [RFC][PATCH] cfgparse
I have created a patch for adding cfgparse to yum base. Does it look sane to everybody. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] cfgparse
Paramjit Oberoi wrote: Hi all, I'm the author of the 'cfgparse' library that is being discussed here. Debarshi brought the discussion to my attention. I'm referring to the library at www.cs.wisc.edu/~param/... - the same which that Tim Lauridsen wants to add to the codebase. I haven't worked on this library much recently, but given the interest---and Debarshi's offer to help with the maintainence---I'm thinking of resurrecting it and fixing a handful of bugs that I've gotten email about over the last 1-2 years. I am planning to move it to a publically accessible repository and do some more active maintainence. Sounds good. I would also like to resolve the naming problem. Since there is another project on sourceforge with the same name, and very similar functionality, I think the best way out might be for me to pick a different name. Some names I was thinking about: config cfgfile inifile iniparser iniparse I like 'iniparse' best. What do you all think about the overall plan, and about the naming issue? I sounds good to me and thanks for your contribution. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [RFC][PATCH] cfgparse (This time the patch is attached)
seth vidal wrote: On Fri, 2007-07-06 at 16:57 +0200, Tim Lauridsen wrote: I have created a patch for adding cfgparse to yum base. Does it look sane to everybody. Tim Tim, 1. web links are welcome - if you need space you can drop it in the path on your linux.duke.edu account. 2. Do we really need to have the full html docs included? Can't we just count on pydoc? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Here is a link to a new patch without the html docs, it can be generated by pydoc. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [RFC][PATCH] cfgparse
Jeremy Katz wrote: On Fri, 2007-07-06 at 16:53 +0200, Tim Lauridsen wrote: I have created a patch for adding cfgparse to yum base. Does it look sane to everybody. Looks empty ;-) Just to see if anybody is awake out there :-) :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [RFC][PATCH] cfgparse (This time the patch is attached)
Tim Lauridsen wrote: seth vidal wrote: On Fri, 2007-07-06 at 16:57 +0200, Tim Lauridsen wrote: I have created a patch for adding cfgparse to yum base. Does it look sane to everybody. Tim Tim, 1. web links are welcome - if you need space you can drop it in the path on your linux.duke.edu account. 2. Do we really need to have the full html docs included? Can't we just count on pydoc? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Here is a link to a new patch without the html docs, it can be generated by pydoc. Tim Yes and here is the missing link :-) http://www.yum-extender.org/dnl/yum/patches/add-cfgparse-patch2.txt Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] protect-packages plugin - compatibility with yum 2.4
Greg Swallow wrote: I got the protect-packages plugin to work with yum 2.4 in EL4 by renaming the two instances of TYPE_INTERACTIVE to TYPE_INTERFACE and changing requires_api_version = '2.4' to requires_api_version = '2.1'. It seems to work fine like that. Just wondering if there is a way to change it to work with _both_ versions of yum, as it doesn't seem to really require yum 3.0? Thanks, Greg ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel This should do the tricks. *from* yum.plugins *import* TYPE_INTERACTIVE, TYPE_CORE, API_VERSION, TYPE_INTERFACE ** plugin_type = (API_VERSION = 2.3 *and* TYPE_INTERFACE *or* TYPE_INTERACTIVE, TYPE_CORE) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] protect-packages plugin - compatibility with yum 2.4
Greg Swallow wrote: Michael E Brown wrote: On Mon, Jul 09, 2007 at 10:35:53AM -0700, Greg Swallow wrote: No luck...When using yum 2.4 (yum-2.4.3-4.el4.centos) I still get the error: ImportError: cannot import name TYPE_INTERACTIVE You can trivially wrap each import in a try: ... except ImportError:... Import the new names, and on import error, fall back to the old names. Thanks for the pointer - the patch below makes works without error on yum-2.4 and I don't have a box with yum-3.0 on it to test, but I assume it would work with that as well. Greg --- protect-packages.py.orig2007-07-09 15:37:14.0 -0700 +++ protect-packages.py 2007-07-09 15:33:51.0 -0700 @@ -33,15 +33,20 @@ use the --override-protection command-line option. - -from yum.plugins import TYPE_CORE, TYPE_INTERACTIVE, PluginYumExit +try: +from yum.plugins import TYPE_CORE, TYPE_INTERACTIVE, PluginYumExit +except ImportError: +from yum.plugins import TYPE_CORE, TYPE_INTERFACE, PluginYumExit import sys import os import string import glob -requires_api_version = '2.4' -plugin_type = (TYPE_CORE, TYPE_INTERACTIVE) +requires_api_version = '2.1' +try: +plugin_type = (TYPE_CORE, TYPE_INTERACTIVE) +except NameError: +plugin_type = (TYPE_CORE, TYPE_INTERFACE) def config_hook(conduit): parser = conduit.getOptParser() ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel It will work, but i like the attached patch better, please try it out. Tim ### Eclipse Workspace Patch 1.0 #P yum-utils Index: plugins/protect-packages/protect-packages.py === RCS file: /home/groups/yum/cvs/yum-utils/plugins/protect-packages/protect-packages.py,v retrieving revision 1.2 diff -u -r1.2 protect-packages.py --- plugins/protect-packages/protect-packages.py22 Jun 2007 16:01:23 - 1.2 +++ plugins/protect-packages/protect-packages.py10 Jul 2007 06:41:07 - @@ -34,14 +34,21 @@ -from yum.plugins import TYPE_CORE, TYPE_INTERACTIVE, PluginYumExit +from yum.plugins import TYPE_CORE, PluginYumExit, API_VERSION import sys import os import string import glob -requires_api_version = '2.4' -plugin_type = (TYPE_CORE, TYPE_INTERACTIVE) +requires_api_version = '2.1' + +if API_VERSION = 2.3: +from yum.plugins import TYPE_INTERFACE +plugin_type = (TYPE_CORE, TYPE_INTERFACE) +else: +from yum.plugins import TYPE_INTERACTIVE +plugin_type = (TYPE_CORE, TYPE_INTERACTIVE) + def config_hook(conduit): parser = conduit.getOptParser() ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] iniparse (was: cfgparse)
seth vidal wrote: On Fri, 2007-07-13 at 10:00 +0200, Tim Lauridsen wrote: Now that cfgparse has been resurrected and renamed to iniparse [1], how do we handle it. 1. Include it in the yum code as a iniparse module. 2. submit it for Fedora as a separate package and add it as a dependency (It could be useful for other projects). Let me know what you think. 2 Ok, i will do the following: 1. Create a spec file and get it includes upstream [Done] 2. Wait for upstream to do a release. ( Sometime next week) 3. Submit for inclusion in Fedora. 4. built it for (F7, Rawhide, EPEL). 5. Added to yum.spec as a requirement and make it use compat.ConfigParser from iniparse, insted of default ConfigParser. Does it make sense. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] iniparse (was: cfgparse)
Tim Lauridsen wrote: seth vidal wrote: On Fri, 2007-07-13 at 10:00 +0200, Tim Lauridsen wrote: Now that cfgparse has been resurrected and renamed to iniparse [1], how do we handle it. 1. Include it in the yum code as a iniparse module. 2. submit it for Fedora as a separate package and add it as a dependency (It could be useful for other projects). Let me know what you think. 2 Ok, i will do the following: 1. Create a spec file and get it includes upstream [Done] 2. Wait for upstream to do a release. ( Sometime next week) 3. Submit for inclusion in Fedora. 4. built it for (F7, Rawhide, EPEL). 5. Added to yum.spec as a requirement and make it use compat.ConfigParser from iniparse, insted of default ConfigParser. Does it make sense. Tim iniparse-0.2 has now been released upstream [1] (Thanks to Paramjit Oberoi for his great work). I have submitted it for package review in Fedora[2]. Tim [1] : http://code.google.com/p/iniparse/ [2] : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248991 ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] yum-security backtrace fix and huge speed improvement
James Antill wrote: Sometime recently yum-security in list updates mode[1] has started causing backtraces and taking a huge amount of time. For those that don't know the way plugins exclude items frfom list updates is to use the exclude_hook and call conduit.getPackages and the conduit.delPackage for any that they don't want. The speed problem seems to be that conduit.delPackage() now takes about a quarter of a second or so, combined with having to remove most/all of the pacakges on the system. The traceback is due to the fact that yum-security just did: for pkg in conduit.getPackages(): ...and this recurses into the function that calls the exclude plugins, YumBase._getSacks(), and is protected from that being a problem by doing: if self._pkgSack and thisrepo is None: ...but if you remove _all_ of the packages the above fails. This can be fixed by just moving the getPackages to a variable before the for loop like: pkgs = conduit.getPackages() for pkg in pkgs: ...however I fixed that and the speed problem by instead doing: upds = conduit._base.doPackageLists(pkgnarrow='updates') pkgs = upds.updates ...this feels a little hacky, but it takes the runtime on my machine from about an hour to 5 seconds (so I feel a little justified :). Another way to go is if we could test if the package is an update/installed etc, like: pkgs = conduit.getPackages() for pkg in pkgs: if pkg isn't installed already: # Do our normal work, incl. likely delPackage() ...but I don't think that's available at this point. Full patch against yum-utils is attached. [1] Ie. yum list updates --security I have added the patch. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] yum-utils 1.1.6 released (Yum = 3.1.1 Only)
Hi. yum-utils 1.1.6 has been released. The yum-utils-1.1.x branch only works with yum = 3.1.1 Changes: - Added protect-packages plugin by Svetlana Anissimova and Matthew Miller - Lot of bug fixes ( Check the ChangeLog[1] for details). Tarball: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.1.6.tar.gz SRPM: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.1.6-1.src.rpm Regards, Tim [1]: http://devel.linux.duke.edu/gitweb/?p=yum-utils.git;a=blob_plain;f=ChangeLog;hb=5a3dc43ea2695619dcc6c6e813706d3379cdb2fa ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Re: [yum-cvs] yum-utils: Makefile
Jeremy Katz wrote: On Tue, 2007-07-24 at 04:24 -0400, Tim Lauridsen wrote: commit 1d15dc62cc1696e99c07642d6184373b352645f8 Author: Tim Lauridsen [EMAIL PROTECTED] Date: Tue Jul 24 10:23:39 2007 +0200 Remove .git directory from tarball You might want to look at using git-archive to create the tarball instead of rolling by hand now. Something like the following should do the trick: git-archive --format=tar --prefix=$(NAME)-$(VERSION)/ HEAD | gzip -9v Thanks, i will try it out Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Updated repository/Next refactoring steps/Request for review
Florian Festi wrote: Hi! I synced my personal repository to the new, shiny, yum git repository. The web interface can still be found at: http://www.jur-linux.org/git/?p=yum-ffesti.git;a=summary It now contains tree branches: * master - this is yum upstream - ffesti - this contains my search/depcheck changes - resolveDeps - experimental next step - see below I was working creating a common yumguicore[1][2] and had some problem with dependencies not being resolved right when i rerun the depsolving a second time. (yum-3.2.2), the i tried it agaist the current yum.git head with the changes from the ffesti branch that Seth has merged recently. An now all the problems are gone. Thanks. Tim [1] : http://fedoraproject.org/wiki/TimLauridsen/YumGuiBackBone [2] : http://repo.or.cz/w/yumguicore.git ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [PATCH] : Make a RPMBaseCallback class to reduce duplicated code.
I have made a RPMBaseCallback class in rpmtrans.py to reduce duplicated
code and make it easier to a lazy yum api user to create a
RPMCallback handler. :-)
Tim
diff --git a/output.py b/output.py
index 073cb0c..095dd07 100644
--- a/output.py
+++ b/output.py
@@ -30,6 +30,7 @@ from rpmUtils.miscutils import checkSignals
from yum.constants import *
from yum import logginglevels
+from yum.rpmtrans import RPMBaseCallback
class YumTextMeter(TextMeter):
def update(self, amount_read, now=None):
@@ -454,26 +455,10 @@ class CacheProgressCallback:
def progressbar(self, current, total, name=None):
progressbar(current, total, name)
-class YumCliRPMCallBack:
+class YumCliRPMCallBack(RPMBaseCallback):
def __init__(self):
-self.action = { TS_UPDATE : 'Updating',
-TS_ERASE: 'Erasing',
-TS_INSTALL: 'Installing',
-TS_TRUEINSTALL : 'Installing',
-TS_OBSOLETED: 'Obsoleted',
-TS_OBSOLETING: 'Installing',
-TS_UPDATED: 'Cleanup',
-'repackaging': 'Repackaging'}
-
-self.fileaction = { TS_UPDATE: 'Updated',
-TS_ERASE: 'Erased',
-TS_INSTALL: 'Installed',
-TS_TRUEINSTALL: 'Installed',
-TS_OBSOLETED: 'Obsoleted',
-TS_OBSOLETING: 'Installed',
-TS_UPDATED: 'Cleanup'}
+RPMBaseCallback.__init__(self)
self.lastmsg = None
-self.logger = logging.getLogger('yum.filelogging.RPMInstallCallback')
self.lastpackage = None # name of last package we looked at
self.output = True
@@ -507,14 +492,6 @@ class YumCliRPMCallBack:
if te_current == te_total:
print
-def errorlog(self, msg):
-print sys.stderr, msg
-
-def filelog(self, package, action):
-# check package object type - if it is a string - just output it
-msg = '%s: %s' % (self.fileaction[action], package)
-self.logger.info(msg)
-
def _makefmt(self, percent, ts_current, ts_total, progress = True):
l = len(str(ts_total))
size = %s.%s % (l, l)
diff --git a/yum/rpmtrans.py b/yum/rpmtrans.py
index 0a14927..0206262 100644
--- a/yum/rpmtrans.py
+++ b/yum/rpmtrans.py
@@ -52,8 +52,10 @@ class NoOutputCallBack:
action is also the same as in event()
pass
-
-class SimpleCliCallBack:
+class RPMBaseCallback:
+'''
+Base class for a RPMTransaction display callback class
+'''
def __init__(self):
self.action = { TS_UPDATE : 'Updating',
TS_ERASE: 'Erasing',
@@ -70,19 +72,20 @@ class SimpleCliCallBack:
TS_OBSOLETED: 'Obsoleted',
TS_OBSOLETING: 'Installed',
TS_UPDATED: 'Cleanup'}
-self.lastmsg = None
self.logger = logging.getLogger('yum.filelogging.RPMInstallCallback')
-self.lastpackage = None # name of last package we looked at
def event(self, package, action, te_current, te_total, ts_current,
ts_total):
-# this is where a progress bar would be called
-msg = '%s: %s %s/%s [%s/%s]' % (self.action[action], package,
- te_current, te_total, ts_current, ts_total)
-if msg != self.lastmsg:
-print msg
-self.lastmsg = msg
-self.lastpackage = package
-
+package is a yum package object or simple string of a package name
+ action is a yum.constant transaction set state or in the obscure
+ rpm repackage case it could be the string 'repackaging'
+ te_current: current number of bytes processed in the transaction
+ element being processed
+ te_total: total number of bytes in the transaction element being
processed
+ ts_current: number of processes completed in whole transaction
+ ts_total: total number of processes in the transaction.
+
+raise NotImplementedError()
+
def errorlog(self, msg):
print sys.stderr, msg
@@ -91,6 +94,22 @@ class SimpleCliCallBack:
# check package object type - if it is a string - just output it
msg = '%s: %s' % (self.fileaction[action], package)
self.logger.info(msg)
+
+
+class SimpleCliCallBack(RPMBaseCallback):
+def __init__(self):
+RPMBaseCallback.__init__(self)
+self.lastmsg = None
+self.lastpackage = None # name of last package we looked at
+
+def event(self, package, action, te_current, te_total, ts_current,
ts_total):
+# this is where a progress bar would be called
+msg = '%s: %s
Re: [Yum-devel] post 3.2.0 things to think about
seth vidal wrote: On Fri, 2007-05-04 at 09:07 +0200, Tim Lauridsen wrote: This is why i think something like yum list vendors could be nice, i could show something like this foo-1.0-1.fc7.i386 Vendor X bar-1.0-2.fc7.noarch Vendor Y is there a sensible situation when a single repo will have more than one vendor contributing the same package name/arch? or are you meaning only for installed pkgs? Only for installed packages, i want a easy way to show the source of the packages, the same info that a repotag will give you, but there is no repo info in the rpmdb, the best available info is the vendor field. If yum contained some kind of transaction database, it could be a place to store the source of each package. This sounds like the kind of info we'd want to store in an installed-pkg persistent yumdb like I mentioned last week. Yes, it will be the perfect place to put it. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] ssl_cert auth patches
seth vidal wrote: Tim, A while back when we were talking about 3.2.0 and beyond features you mentioned a patch for yum from someone at ibm to use ssl_certs with urlgrabber to auth to our repos. I don't see this applied anywhere. Do you still have it? Would you be willing to commit it if it still works? I still got it, but it need some changes to Urlgrabber to work, i never got any comments on the UG patches. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] ssl_cert auth patches
seth vidal wrote: On Wed, 2007-08-15 at 09:10 +0200, Tim Lauridsen wrote: seth vidal wrote: Tim, A while back when we were talking about 3.2.0 and beyond features you mentioned a patch for yum from someone at ibm to use ssl_certs with urlgrabber to auth to our repos. I don't see this applied anywhere. Do you still have it? Would you be willing to commit it if it still works? I still got it, but it need some changes to Urlgrabber to work, i never got any comments on the UG patches. Could you repost them - I'll see what I can do to get the UG maintainer to come back to talk to us. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Here is the patches. [UG] : https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003600.html [YUM] : https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003601.html Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] ssl_cert auth patches
Tim Lauridsen wrote:
seth vidal wrote:
On Wed, 2007-08-15 at 09:10 +0200, Tim Lauridsen wrote:
seth vidal wrote:
Tim,
A while back when we were talking about 3.2.0 and beyond features you
mentioned a patch for yum from someone at ibm to use ssl_certs with
urlgrabber to auth to our repos. I don't see this applied anywhere. Do
you still have it? Would you be willing to commit it if it still works?
I still got it, but it need some changes to Urlgrabber to work, i never
got any comments on the UG patches.
Could you repost them - I'll see what I can do to get the UG maintainer
to come back to talk to us.
-sv
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Here is the patches.
[UG] :
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003600.html
[YUM] :
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003601.html
Tim
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Here is the patches as attachments
Tim
--- urlgrabber-3.1.0/urlgrabber/grabber.py.orig 2006-12-26 13:48:26.0 -0500
+++ urlgrabber-3.1.0/urlgrabber/grabber.py 2006-12-26 13:49:02.0 -0500
@@ -809,6 +809,7 @@
self.urlparser = URLParser()
self.quote = None
self.ssl_ca_cert = None
+self.ssl_client_cert = None
self.ssl_context = None
class URLGrabber:
@@ -1045,7 +1046,7 @@
# ---
ssl_factory = sslfactory.get_factory(self.opts.ssl_ca_cert,
-self.opts.ssl_context)
+self.opts.ssl_client_cert, self.opts.ssl_context)
if need_keepalive_handler:
handlers.append(HTTPHandler())
--- urlgrabber-3.1.0/urlgrabber/sslfactory.py.orig 2006-12-26 13:33:48.0 -0500
+++ urlgrabber-3.1.0/urlgrabber/sslfactory.py 2006-12-26 14:51:13.0 -0500
@@ -34,21 +34,24 @@
class M2SSLFactory:
-def __init__(self, ssl_ca_cert, ssl_context):
-self.ssl_context = self._get_ssl_context(ssl_ca_cert, ssl_context)
+def __init__(self, ssl_ca_cert, ssl_client_cert, ssl_context):
+self.ssl_context = self._get_ssl_context(ssl_ca_cert, ssl_client_cert, ssl_context)
-def _get_ssl_context(self, ssl_ca_cert, ssl_context):
+def _get_ssl_context(self, ssl_ca_cert, ssl_client_cert, ssl_context):
-Create an ssl context using the CA cert file or ssl context.
+Create a ssl context using the CA cert file and/or the client cert file or ssl context.
-The CA cert is used first if it was passed as an option. If not,
-then the supplied ssl context is used. If no ssl context was supplied,
+The CA cert and client cert are used first if either or both are passed as an options.
+If not, then the supplied ssl context is used. If no ssl context was supplied,
None is returned.
-if ssl_ca_cert:
+if ssl_ca_cert or ssl_client_cert:
context = SSL.Context()
-context.load_verify_locations(ssl_ca_cert)
-context.set_verify(SSL.verify_peer, -1)
+if ssl_ca_cert:
+context.load_verify_locations(ssl_ca_cert)
+context.set_verify(SSL.verify_peer, -1)
+if ssl_client_cert:
+context.load_cert(ssl_client_cert)
return context
else:
return ssl_context
@@ -76,10 +79,10 @@
-def get_factory(ssl_ca_cert = None, ssl_context = None):
+def get_factory(ssl_ca_cert = None, ssl_client_cert = None, ssl_context = None):
Return an SSLFactory, based on if M2Crypto is available.
if have_m2crypto:
-return M2SSLFactory(ssl_ca_cert, ssl_context)
+return M2SSLFactory(ssl_ca_cert, ssl_client_cert, ssl_context)
else:
# Log here if someone provides the args but we don't use them.
if ssl_ca_cert or ssl_context:
--- yum-3.1.6/yum/config.py.orig 2007-04-20 05:10:46.0 -0400
+++ yum-3.1.6/yum/config.py 2007-04-20 05:56:16.0 -0400
@@ -500,6 +500,7 @@
proxy = UrlOption(schemes=('http', 'ftp', 'https'), allow_none=True)
proxy_username = Option()
proxy_password = Option()
+client_cert = Option()
installonlypkgs = ListOption(['kernel', 'kernel-bigmem',
'kernel-enterprise','kernel-smp', 'kernel-modules', 'kernel-debug',
'kernel-unsupported', 'kernel-source', 'kernel-devel'])
@@ -553,6 +554,7 @@
proxy_password = Inherit(YumConf.proxy_password)
retries = Inherit(YumConf.retries
Re: [Yum-devel] things that suck
Tim Lauridsen wrote: seth vidal wrote: writing a program that downloads pkgs and runs the transaction w/o duplicating a bunch of code from cli.doTransaction(). this clearly needs to be fixed. The standard operating set: 1. download pkgs 2. sig check pkgs 3. test transaction 4. rpm_check_debug transaction 5. ts.check() 6. ts.order() 7. self.runTransaction(cb) yes, this needs to be much simpler. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Yes, it sucks, and there is even more step for the time you have populates self.tsInfo with the actions you want to perform. 1. Solve dependencies. 2. Ask the user for confimation. 3. Download packages. 4. Check signatures. 5 Ask user for gpg key import confimation if needed. 6. Do a test transaction 7. Do the real transaction But how do we make it better ?. Add a generic 'processTransaction' to YumBaseCli with some kind of callback, so it can be extended ?? See the attached pseudo kode. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel I have made a prof of concept to how it could work. Tim diff --git a/yum/__init__.py b/yum/__init__.py index 33a0e76..ec0ee1b 100644 --- a/yum/__init__.py +++ b/yum/__init__.py @@ -51,6 +51,7 @@ warnings.simplefilter(ignore, Errors.YumFutureDeprecationWarning) from packages import parsePackages, YumAvailablePackage, YumLocalPackage, YumInstalledPackage from constants import * +from yum.rpmtrans import RPMTransaction,SimpleCliCallBack __version__ = '3.2.2' @@ -2166,3 +2167,137 @@ class YumBase(depsolve.Depsolve): numleft -= 1 map(lambda x: self.tsInfo.addErase(x), toremove) + +def processTransaction(self, callback=None,rpmTestDisplay=None, rpmDisplay=None): +''' +Process the current Transaction +- Download Packages +- Check GPG Signatures. +- Run Test RPM Transaction +- Run RPM Transaction + +callback.event method is called at start/end of each process. + +@param callback: callback object (must have an event method) +@param rpmTestDisplay: Name of display class to use in RPM Test Transaction +@param rpmDisplay: Name of display class to use in RPM Transaction +''' + +action = Download Packages +if callback: callback.event(action=action, state=Start) +pkgs = self._downloadPackages() +if callback: callback.event(action=action, state=End) +action = Checking Signatures +if callback: callback.event(action=action, state=Start) +self._checkSignatures(pkgs) +if callback: callback.event(action=action, state=End) +action = Test Transaction +if callback: callback.event(action=action, state=Start) +self._doTestTransaction(display=rpmTestDisplay) +if callback: callback.event(action=action, state=End) +action = Run Transaction +if callback: callback.event(action=action, state=Start) +self._doTransaction(display=rpmDisplay) +if callback: callback.event(action=action, state=End) + +def _downloadPackages(self): +''' Download the need packages in the Transaction ''' +# This can be overloaded by a subclass. +dlpkgs = map(lambda x: x.po, filter(lambda txmbr: +txmbr.ts_state in (i, u), +self.tsInfo.getMembers())) + +try: +probs = self.downloadPkgs(dlpkgs) + +except IndexError: +raise yum.Errors.YumBaseError, [Unable to find a suitable mirror.] +if len(probs.keys()) 0: +errstr = [Errors were encountered while downloading packages.] +for key in probs.keys(): +errors = yum.misc.unique(probs[key]) +for error in errors: +errstr.append(%s: %s %(key, error)) + +raise yum.Errors.YumBaseError, errstr +return dlpkgs + +def _checkSignatures(self,pkgs): +''' The the signatures of the downloaded packages ''' +# This can be overloaded by a subclass. +for po in pkgs: +result, errmsg = self.sigCheckPkg(po) +if result == 0: +# Verified ok, or verify not req'd +continue +elif result == 1: + self.getKeyForPackage(po, self._askForGPGKeyImport) +else: +raise yum.Errors.YumBaseError, errmsg + +return 0 + +def _askForGPGKeyImport(self, po, userid, hexkeyid): +''' +Ask for GPGKeyImport
Re: [Yum-devel] things that suck
Tim Lauridsen wrote: seth vidal wrote: writing a program that downloads pkgs and runs the transaction w/o duplicating a bunch of code from cli.doTransaction(). this clearly needs to be fixed. The standard operating set: 1. download pkgs 2. sig check pkgs 3. test transaction 4. rpm_check_debug transaction 5. ts.check() 6. ts.order() 7. self.runTransaction(cb) yes, this needs to be much simpler. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Yes, it sucks, and there is even more step for the time you have populates self.tsInfo with the actions you want to perform. 1. Solve dependencies. 2. Ask the user for confimation. 3. Download packages. 4. Check signatures. 5 Ask user for gpg key import confimation if needed. 6. Do a test transaction 7. Do the real transaction But how do we make it better ?. Add a generic 'processTransaction' to YumBaseCli with some kind of callback, so it can be extended ?? See the attached pseudo kode. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Look like my last post was eaten by the list size limit, so i try again without attachments. I have made a prof of concept to how it could work. Patch to YumBase. http://timlau.fedorapeople.org/yum/yum-processTransaction.patch Test Program. http://timlau.fedorapeople.org/yum/test.py Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] things that suck
seth vidal wrote: On Fri, 2007-08-17 at 14:31 +0200, Tim Lauridsen wrote: Look like my last post was eaten by the list size limit, so i try again without attachments. I have made a prof of concept to how it could work. Patch to YumBase. http://timlau.fedorapeople.org/yum/yum-processTransaction.patch Test Program. http://timlau.fedorapeople.org/yum/test.py Like we talked about on irc - this looks good - commit it. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Committed Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [PATCH] Extra Yum Error Exceptions
After adding prepareTransaction helpers to YumBase a YumBaseError
exception is raised if any thing goes wrong.
but i would be nice to see, if it was Download or GPGCheck or
TestTransaction there went wrong.
So i have created a patch with some extra Yum Exception and make the
different step cast a custom exception.
Just want to know if the naming look sane, before committing.
Tim
diff --git a/yum/Errors.py b/yum/Errors.py
index 22902bf..0f87079 100644
--- a/yum/Errors.py
+++ b/yum/Errors.py
@@ -25,6 +25,9 @@ class YumBaseError(exceptions.Exception):
self.value = value
def __str__(self):
return %s %(self.value,)
+
+YumDownloadError = YumGPGCheckError = YumTestTransactionError =\
+ YumRPMCheckError= YumBaseError
class LockError(YumBaseError):
def __init__(self, errno, msg):
diff --git a/yum/__init__.py b/yum/__init__.py
index ec0ee1b..377fd0f 100644
--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -2219,7 +2219,7 @@ class YumBase(depsolve.Depsolve):
for error in errors:
errstr.append(%s: %s %(key, error))
-raise yum.Errors.YumBaseError, errstr
+raise yum.Errors.YumDownloadError, errstr
return dlpkgs
def _checkSignatures(self,pkgs):
@@ -2233,7 +2233,7 @@ class YumBase(depsolve.Depsolve):
elif result == 1:
self.getKeyForPackage(po, self._askForGPGKeyImport)
else:
-raise yum.Errors.YumBaseError, errmsg
+raise yum.Errors.YumGPGCheckError, errmsg
return 0
@@ -2255,7 +2255,7 @@ class YumBase(depsolve.Depsolve):
retmsgs = ['ERROR with rpm_check_debug vs depsolve:']
retmsgs.extend(msgs)
retmsgs.append('Please report this error in bugzilla')
-raise yum.Errors.YumBaseError,retmsgs
+raise yum.Errors.YumRPMCheckError,retmsgs
tsConf = {}
for feature in ['diskspacecheck']: # more to come, I'm sure
@@ -2280,7 +2280,7 @@ class YumBase(depsolve.Depsolve):
errstring = 'Test Transaction Errors: '
for descr in tserrors:
errstring += ' %s\n' % descr
-raise yum.Errors.YumBaseError, errstring
+raise yum.Errors.YumTestTransactionError, errstring
del self.ts
# put back our depcheck callback
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Extra Yum Error Exceptions
Jeremy Katz wrote:
On Mon, 2007-08-20 at 15:41 +0200, Tim Lauridsen wrote:
After adding prepareTransaction helpers to YumBase a YumBaseError
exception is raised if any thing goes wrong.
but i would be nice to see, if it was Download or GPGCheck or
TestTransaction there went wrong.
So i have created a patch with some extra Yum Exception and make the
different step cast a custom exception.
Just want to know if the naming look sane, before committing.
Naming seems fine -- it's worth making the new exceptions distinct
classes rather than equal, though, so that you can actually distinguish
between them when they're raised
Yes, offcause the make a lot of sense :-) .
New patch added.
Tim
diff --git a/yum/Errors.py b/yum/Errors.py
index 22902bf..d2472aa 100644
--- a/yum/Errors.py
+++ b/yum/Errors.py
@@ -26,6 +26,26 @@ class YumBaseError(exceptions.Exception):
def __str__(self):
return %s %(self.value,)
+class YumGPGCheckError(YumBaseError):
+def __init__(self, value=None):
+YumBaseError.__init__(self)
+self.value = value
+
+class YumDownloadError(YumBaseError):
+def __init__(self, value=None):
+YumBaseError.__init__(self)
+self.value = value
+
+class YumTestTransactionError(YumBaseError):
+def __init__(self, value=None):
+YumBaseError.__init__(self)
+self.value = value
+
+class YumRPMCheckError(YumBaseError):
+def __init__(self, value=None):
+YumBaseError.__init__(self)
+self.value = value
+
class LockError(YumBaseError):
def __init__(self, errno, msg):
YumBaseError.__init__(self)
diff --git a/yum/__init__.py b/yum/__init__.py
index ec0ee1b..377fd0f 100644
--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -2219,7 +2219,7 @@ class YumBase(depsolve.Depsolve):
for error in errors:
errstr.append(%s: %s %(key, error))
-raise yum.Errors.YumBaseError, errstr
+raise yum.Errors.YumDownloadError, errstr
return dlpkgs
def _checkSignatures(self,pkgs):
@@ -2233,7 +2233,7 @@ class YumBase(depsolve.Depsolve):
elif result == 1:
self.getKeyForPackage(po, self._askForGPGKeyImport)
else:
-raise yum.Errors.YumBaseError, errmsg
+raise yum.Errors.YumGPGCheckError, errmsg
return 0
@@ -2255,7 +2255,7 @@ class YumBase(depsolve.Depsolve):
retmsgs = ['ERROR with rpm_check_debug vs depsolve:']
retmsgs.extend(msgs)
retmsgs.append('Please report this error in bugzilla')
-raise yum.Errors.YumBaseError,retmsgs
+raise yum.Errors.YumRPMCheckError,retmsgs
tsConf = {}
for feature in ['diskspacecheck']: # more to come, I'm sure
@@ -2280,7 +2280,7 @@ class YumBase(depsolve.Depsolve):
errstring = 'Test Transaction Errors: '
for descr in tserrors:
errstring += ' %s\n' % descr
-raise yum.Errors.YumBaseError, errstring
+raise yum.Errors.YumTestTransactionError, errstring
del self.ts
# put back our depcheck callback
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Extra Yum Error Exceptions
Florian Festi wrote: Tim Lauridsen wrote: Jeremy Katz wrote: On Mon, 2007-08-20 at 15:41 +0200, Tim Lauridsen wrote: After adding prepareTransaction helpers to YumBase a YumBaseError exception is raised if any thing goes wrong. but i would be nice to see, if it was Download or GPGCheck or TestTransaction there went wrong. So i have created a patch with some extra Yum Exception and make the different step cast a custom exception. Just want to know if the naming look sane, before committing. Naming seems fine -- it's worth making the new exceptions distinct classes rather than equal, though, so that you can actually distinguish between them when they're raised Yes, offcause the make a lot of sense :-) . New patch added. Hmm, why do all these exception classes have a __init__ method that (semantically) equals that of their base class... We could save a lot of lines by reducing the class bodies to just pass Never thought of that, i will remove the __init__ methods. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [PATCH] processTransaction cleanup and added file with callback classes
Hi,
I have cleaned up processTransaction a little and added yum/callbacks.py
with some callback classes to use with processTransaction
I have attached the patch and a test program.
Tim
diff --git a/yum/__init__.py b/yum/__init__.py
index 377fd0f..823ac5a 100644
--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -45,6 +45,7 @@ import depsolve
import plugins
import logginglevels
import yumRepo
+import callbacks
import warnings
warnings.simplefilter(ignore, Errors.YumFutureDeprecationWarning)
@@ -2183,22 +2184,21 @@ class YumBase(depsolve.Depsolve):
@param rpmDisplay: Name of display class to use in RPM Transaction
'''
-action = Download Packages
-if callback: callback.event(action=action, state=Start)
+if not callback:
+callback = callbacks.ProcessTransNoOutputCallback()
+
+# Download Packages
+callback.event(callbacks.PT_DOWNLOAD)
pkgs = self._downloadPackages()
-if callback: callback.event(action=action, state=End)
-action = Checking Signatures
-if callback: callback.event(action=action, state=Start)
+# Check Package Signatures
+callback.event(callbacks.PT_GPGCHECK)
self._checkSignatures(pkgs)
-if callback: callback.event(action=action, state=End)
-action = Test Transaction
-if callback: callback.event(action=action, state=Start)
+# Run Test Transaction
+callback.event(callbacks.PT_TEST_TRANS)
self._doTestTransaction(display=rpmTestDisplay)
-if callback: callback.event(action=action, state=End)
-action = Run Transaction
-if callback: callback.event(action=action, state=Start)
+# Run Transaction
+callback.event(callbacks.PT_TRANSACTION)
self._doTransaction(display=rpmDisplay)
-if callback: callback.event(action=action, state=End)
def _downloadPackages(self):
''' Download the need packages in the Transaction '''
diff --git a/yum/callbacks.py b/yum/callbacks.py
new file mode 100644
index 000..10a2c43
--- /dev/null
+++ b/yum/callbacks.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python -tt
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Library General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+# imports
+
+import logging
+
+# ProcessTransaction States
+
+PT_DOWNLOAD= 0
+PT_GPGCHECK= 1
+PT_TEST_TRANS = 2
+PT_TRANSACTION = 3
+
+PT_MESSAGES = { PT_DOWNLOAD: Downloading Packages,
+PT_GPGCHECK: Check Package Signatures,
+PT_TEST_TRANS : Running Test Transaction,
+PT_TRANSACTION : Running Transaction}
+
+
+
+class ProcessTransBaseCallback:
+
+def __init__(self):
+self.logger = logging.getLogger('yum.verbose.ProcessTrasactionBaseCallback')
+
+def event(self,state):
+self.logger.info(PT_MESSAGES[state])
+
+class ProcessTransNoOutputCallback:
+def __init__(self):
+pass
+
+def event(self,state):
+pass
+
from utils import YumUtilBase
from yum.callbacks import ProcessTransBaseCallback
import output
import yum
name = 'test'
ver = '0.1'
usage = 'test [options] [args]'
yb = YumUtilBase(name,ver,usage)
yb.doUtilConfigSetup()
txmbr = yb.install(name='yum-utils')
if txmbr:
print Installing : %s % str(txmbr[0].po)
rc,msgs = yb.buildTransaction()
if rc !=2:
print Dep Errors
print \n.join(msgs)
else:
try:
yb.processTransaction(callback=ProcessTransBaseCallback(),
rpmDisplay=output.YumCliRPMCallBack())
except yum.Errors.YumBaseError, msgs:
print Error in Transaction Processing
print \n.join(msgs)
else:
print nothing to do
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Extra Yum Error Exceptions
Florian Festi wrote: Tim Lauridsen wrote: Florian Festi wrote: Tim Lauridsen wrote: Jeremy Katz wrote: On Mon, 2007-08-20 at 15:41 +0200, Tim Lauridsen wrote: After adding prepareTransaction helpers to YumBase a YumBaseError exception is raised if any thing goes wrong. but i would be nice to see, if it was Download or GPGCheck or TestTransaction there went wrong. So i have created a patch with some extra Yum Exception and make the different step cast a custom exception. Just want to know if the naming look sane, before committing. Naming seems fine -- it's worth making the new exceptions distinct classes rather than equal, though, so that you can actually distinguish between them when they're raised Yes, offcause the make a lot of sense :-) . New patch added. Hmm, why do all these exception classes have a __init__ method that (semantically) equals that of their base class... We could save a lot of lines by reducing the class bodies to just pass Never thought of that, i will remove the __init__ methods. I really don't want to be picky but what about the __init__ methods of all (most) of the other exceptions...? Ok, i cleaned up the other exceptions too Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] Current yum git desolver is a little slow
I did some basic testing of the current yum git HEAD vs. yum 3.2.2. I did a simple time echo n | yum update (yum 3.2.2) real0m3.396s user0m2.965s sys 0m0.370s time echo n | ./yummain.py update (git HEAD) real0m5.707s user0m4.997s sys 0m0.651s Dependencies Resolved = Package Arch Version RepositorySize = Updating: alsa-libi386 1.0.14-3.fc7 updates 409 k glest-data noarch 2.0.0-5.fc7 updates62 M gstreamer-plugins-base i386 0.10.13-1.fc7updates 741 k libvolume_idi386 113-11.fc7 updates52 k procps i386 3.2.7-15.fc7 updates 210 k smartmontools i386 1:5.37-3.1.fc7 updates 301 k spamassassini386 3.2.3-1.fc7 updates 1.0 M udevi386 113-11.fc7 updates 316 k Transaction Summary = Install 0 Package(s) Update 8 Package(s) Remove 0 Package(s) The transaction result was the same, but yum 3.2.2 seams a lot faster. Now i tries the worstcase senario: time echo n | ./yummain.py --enablerepo=development update Error: Missing Dependency: kernel-i686 = 2.6.22.1-41.fc7 is needed by package kmod-madwifi Error: Missing Dependency: libmpcdec.so.3 is needed by package mplayer Error: Missing Dependency: libmpcdec.so.3 is needed by package vlc real3m51.676s user3m17.966s sys 0m33.452s time echo n | ./yum --enablerepo=development update Error: Unresolveable requirement libmpcdec.so.3 for mplayer Error: Unresolveable requirement libmpcdec.so.3 for vlc real3m12.441s user2m58.993s sys 0m13.251s The relative change is not so big, but yum git head is still slower, but it i does a better job, it detcts more errors. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Current yum git desolver is a little slow
Florian Festi wrote: Tim Lauridsen wrote: I did some basic testing of the current yum git HEAD vs. yum 3.2.2. Yes, current git head is a bit slower than 3.2.2. There is a simple reason for that: Linear searches on disk are even slower than linear searches in memory. In other words: We are still missing some indexes in the sqlite database to really gain speed from the changes. For performance runs you can temporary remove patch 3c2621ba8f8070f24ad3e979f6bd1699f6f6b394 or readd 42283902f929ac131cda7b3497ae047b497e02bc. There are two possible permanent solutions: Readd the patch mentions above and extend it that all indexes are created if they are not present yet. I posted timings for creating these indexes some weeks ago (2. Aug Sqlite DB Indexes). As alternative or in addition we could patch yum-metadata-parser to just add the needed indexes. I can provide patches for both as soon as there is a decision with way(s) we want to go. I added this http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=42283902f929ac131cda7b3497ae047b497e02bc It speed up things a lot, but makes yum load the metadata every time, because the index creation changes the checksum i think. I we want to create the indexes locally, how do we know when to download the sqlite tarball from the repo ? Tim Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] processTransaction cleanup and added file with callback classes
Tim Lauridsen wrote: Hi, I have cleaned up processTransaction a little and added yum/callbacks.py with some callback classes to use with processTransaction I have attached the patch and a test program. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel I missed the yum 3.2.3 with this one :-\ , It changes the processTransaction callback API a little, but nobody uses it yet, so it will not hurt anyone, so i have committed it. Then i can keep processTransaction a Secret until 3.2.4 gets out. :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Re: [yum-cvs] 2 commits - yum/yumRepo.py
seth vidal wrote: Git People: On Fri, 2007-08-31 at 00:48 -0400, Seth Vidal wrote: yum/yumRepo.py |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) okay - this one is me. New commits: commit 3401ba6c332e676f838d2e419e59ae3da5085c41 Merge: 564fd27... 003ef7e... Author: Seth Vidal [EMAIL PROTECTED] Date: Fri Aug 31 00:44:54 2007 -0400 Merge branch 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum * 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum: * Added extra processTransaction callback event PT_DOWNLOAD_PKGS called with packages to download. But this isn't me. When I'm out of sync with whatever is in the origin and I don't remember it - I'll do a git pull, it merges, then I do a git push and it shows like I've done a commit from what I've had before - it even reads odd like that in the changelog. Is there something else I should be doing? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel If you are out of sync with the public git repo, then do this git fetch git rebase origin It will pull the changes and add your local commits on top and the you get rid of the Merge branch 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum lines. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Re: [yum-cvs] 2 commits - yum/yumRepo.py
seth vidal wrote: On Fri, 2007-08-31 at 08:02 +0200, Tim Lauridsen wrote: seth vidal wrote: Git People: On Fri, 2007-08-31 at 00:48 -0400, Seth Vidal wrote: yum/yumRepo.py |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) okay - this one is me. New commits: commit 3401ba6c332e676f838d2e419e59ae3da5085c41 Merge: 564fd27... 003ef7e... Author: Seth Vidal [EMAIL PROTECTED] Date: Fri Aug 31 00:44:54 2007 -0400 Merge branch 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum * 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum: * Added extra processTransaction callback event PT_DOWNLOAD_PKGS called with packages to download. But this isn't me. When I'm out of sync with whatever is in the origin and I don't remember it - I'll do a git pull, it merges, then I do a git push and it shows like I've done a commit from what I've had before - it even reads odd like that in the changelog. Is there something else I should be doing? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel If you are out of sync with the public git repo, then do this git fetch git rebase origin It will pull the changes and add your local commits on top and the you get rid of the Merge branch 'master' of ssh://login.linux.duke.edu/home/groups/yum/git/yum lines. thanks! Odd that when it tells me I'm not in sync it suggests I do a pull. -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Yes, git sometime works in mysterious ways :) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] repoquery: silence progress bars in pipes
Thanks, commited. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] repo priorities
seth vidal wrote: On Wed, 2007-09-05 at 08:27 +0200, Tim Lauridsen wrote: simple-local-repo-priority - allows you to setup a local repo that has SOME of the pkgs from another repo and know that the ones in the local (or better priority repo) will be used. This only works for nevra-exact pkgs from one to the other. This is useful for anaconda, mock, mash, etc to let it know to use a closer copy of some of the files rather than a remote one. This is more like a repo cost to me, if more packages exist with the same nevra the take the cheapest one. Very nice and useful, but it have a different purpose that the other ones. You and jantill have said more or less the same thing. I think you both have a point. I've been referring to this incorrectly. Maybe 'cost' could be implemented as a plugin and/or in core which would handle the case of 2 locations offering the exact same pkg but the more expensive one is excluded. +1, for inclusion in core. something like cost=5 in the repo file. the default value for cost should be '10' or something like that. What about this one. repo-group packages is only updated by packages from the same repo group. [base] ... ... group=base [updates] ... ... group=base [foo] ... group=foo [bar] ... group=bar packages installed from base updates is only updated by packages from base update. packakges installed from foo is only updated from foo. packages installed from bar is only updated from bar. I know we can't do that before we have some way of storing the source of the installed packages. This would solve most repo mixing screw ups. It would solve them - it would also create a number of headaches. An example: user has: fedora 3rdpartyrepo fedora-upates the user installs something from 3rdpartyrepo which they don't have installed yet on their system from fedora. The version in 3rdpartyrepo is newer/better/something. Then 2 months later the version from 3rdpartyrepo is now incorporated into fedora-updates. Then the user is more or less screwed for getting that legitimate update. -sv Look like the this priority stuff cant be done in a sane way :-( , all the approaches have some problems one way or another. I rest my case, leave it out of core and in plugins like today. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] repo priorities
seth vidal wrote: On Thu, 2007-09-06 at 15:37 -0400, seth vidal wrote: On Thu, 2007-09-06 at 08:26 +0200, Tim Lauridsen wrote: +1, for inclusion in core. something like cost=5 in the repo file. the default value for cost should be '10' or something like that. So here's an interesting twist. cost is really an attribute of a package. Since there's nothing saying a package in repodata has to be at the same url as the repo. So if we're working along those lines we make cost be listed in the repo config but we add it as an attribute of all the pkgs in that repo. This opens up new angles for plugins. so arguably a plugin could do: for pkg in allpkgs: if pkg.basepath.startswith(ftp://): pkg.cost = 8 ... it also makes comparisons in the future easier: if all other things about these pkgs are the same: pkg.cost pkg.cost... What do y'all think? Does that make sense? -sv ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel slight hang up here - to make it functional as an attribute of a package it has to be persistent. We CAN dynamically create pkgs from the sqlitesack and they won't necessarily persist. It seems like we'd want to keep a cost dictionary in each repository/sack that let's us re-add that attribute if we make a new object on the fly. Then if we're going to do that it would make more sense to have a generic ability to add attributes to a package that would persist w/i the session independent of the destruction/construction of any given package object. Obviously the values should not persist across destruction/construction of a packageSack but it's an interesting concept to me. I would be very nice to have a way to add extra attributes to the package objects. In yumex i create some kind of weird packagewrapper around the yum package object to be able add extra attributes. it would be much better if there was a generic way to add extra attributes. Tim Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] repo priorities
seth vidal wrote: On Thu, 2007-09-06 at 08:26 +0200, Tim Lauridsen wrote: +1, for inclusion in core. something like cost=5 in the repo file. the default value for cost should be '10' or something like that. So here's an interesting twist. cost is really an attribute of a package. Since there's nothing saying a package in repodata has to be at the same url as the repo. So if we're working along those lines we make cost be listed in the repo config but we add it as an attribute of all the pkgs in that repo. This opens up new angles for plugins. so arguably a plugin could do: for pkg in allpkgs: if pkg.basepath.startswith(ftp://): pkg.cost = 8 ... it also makes comparisons in the future easier: if all other things about these pkgs are the same: pkg.cost pkg.cost... What do y'all think? Does that make sense? Sound like very nice idea. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] yum-utils 1.1.7 released (Yum = 3.1.1 Only)
Hi. yum-utils 1.1.7 has been released. The yum-utils-1.1.x branch only works with yum = 3.1.1 Changes: - New basearchonly plugin by Adel Gadllah - New --repofrompath=repotag,path/URL option to specify local repos to repoquery - Lot of bug fixes ( Check the ChangeLog[1] for details). Tarball: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.1.7.tar.gz SRPM: http://linux.duke.edu/projects/yum/download/yum-utils/yum-utils-1.1.7-1.src.rpm Regards, Tim [1]: http://devel.linux.duke.edu/gitweb/?p=yum-utils.git;a=blob_plain;f=ChangeLog;hb=953199285e9df2cd304e255942861db1e3f23aa9 ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] Re: [yum-cvs] 2 commits - yum/__init__.py yum/rpmtrans.py
Jeremy Katz wrote: yum/__init__.py |2 +- yum/rpmtrans.py |5 - 2 files changed, 5 insertions(+), 2 deletions(-) New commits: commit ac87ad138493036b6dbfec4cbfabf9daa3313f81 Author: Jeremy Katz [EMAIL PROTECTED] Date: Wed Sep 12 10:41:20 2007 -0400 event() only takes one argument diff --git a/yum/__init__.py b/yum/__init__.py index 39121e2..de4f1ca 100644 --- a/yum/__init__.py +++ b/yum/__init__.py @@ -,7 +,7 @@ class YumBase(depsolve.Depsolve): if len(dlpkgs) == 0: return None # make callback with packages to download -callback.event(callbacks.PT_DOWNLOAD_PKGS,dlpkgs) +callback.event(callbacks.PT_DOWNLOAD_PKGS) try: probs = self.downloadPkgs(dlpkgs) my fault, event should take two argument (the last one is optional) , but i forgot to add to add it to the base classes. I will fix it. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] RFC: Capturing scriptlet output during transaction
Jeremy Katz wrote: With the new transaction handling stuff, we can actually start to get to where grabbing the output of scriptlets is pretty doable so that it can be more easily consumed by tools sitting on top of yum. anaconda has been redirecting the bits to a file roughly forever (and thus, that's the API that rpm exposes). So we can use a pipe with only minimal pain. This adds a new scriptout() method that callbacks can implement to get the output on a per-package basis. I've made it so the command-line can have the same behavior it's always had. Graphical callers can then grab to show the errors later. Thoughts? Jeremy ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Look great to me, I have wanted this kind of functionality in yumex for a long time, but i never found a sane way to do it :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] yum-utils package-cleanup -- exit with error if problems found
Matthew Miller wrote: This would be handy for scripting an automatic package database problem check --- package-cleanup.200709172007-07-06 13:32:06.0 -0400 +++ package-cleanup 2007-09-17 16:17:44.0 -0400 @@ -101,8 +101,12 @@ # Store the resolve_sack so that we can re-use it if another # package has the same requirement providers[(req,rflags,ver)] = resolve_sack -if not errors and reportProblems: -print No problems found +if reportProblems: +if errors: +sys.exit(1) +else: +print No problems found +sys.exit(0) return provsomething def findDupes(my): Thanks, Commited Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Allow metadata_expire = -1 to imply never expire
Jeremy Katz wrote: For repos on physical media, they're never going to change, so it'd be nice to be able to express that. Allow metadata_expire=-1 to imply that they should never expire. Jeremy ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Looks sane to me. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Disable media only repos for non-media-aware frontends
Jeremy Katz wrote: With the mediaid/mediafunc bits being opt-in for API users, if there's a repo which is media _only_, we should probably just disable it if you're not using a media-aware frontend. Attached implements. This will make it so that we can stick a dvd.repo on the top-level of the Fedora DVDs which includes a mediaid line. Then, pirut will be able to get packages off of the DVD (if it's available) and yum will just happily fall back. And it keeps us from having to figure out when creating dvd.repo what the actual end baseurl will be Jeremy ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Looks fine to me too. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] RFC: Plugin to output compact search results
seth vidal wrote: On Tue, 2007-09-18 at 15:42 -0400, James Antill wrote: then it's just changing the output for a search, right? That seems like a much better solution to me, yeh. I just wasn't sure about what the opinion was on breaking backwards compatability on the UI like that. Yah - I'm not sure that we've made in promises on the screen-scraping output of any of the cli. :) :-) :-) :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Yum test script
Florian Festi wrote: Hi! I realized that the yum release test have to be done by hand some weeks ago. I now had the time to start translating the wiki page into shell code. The script requires root privileges. It doesn't have full coverage yet and the tests that everything is really OK are still a bit weak. May be this can end up in the tests directory or as make release-test. Comments, suggestions and additions are welcome! Florian ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel I tested the script with the current yum git master branch it gives a lot of FAILED (See attached file) Tim [EMAIL PROTECTED] ~]# sh /data/udv/git/yum/test/yum-release-test.sh Using /tmp/tmp.pIHaGP4437 yum groupinstall Base Core Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED Check for vim-minimal FAILED yum remove vim-minimal Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED Check if vim-minimal is removed OK yum install vim-minimal | cat Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again OK Check vim-minimal FAILED yum install bash (already installed) Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum install fOObAr (not available) Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum groupinstall Graphics Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED Check gimp FAILED yum groupremove Graphics Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED Check if gimp is removed OK yum makecache Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum clean all OK yum --version 3.2.5 OK yum search kernel Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum provides kernel Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum info kernel Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum groupinfo Core Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum deplist bash Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum grouplist Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum list updates Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum list obsoletes Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum list available Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED yum list installed OK yum check-update Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again FAILED Deleting /tmp/tmp.pIHaGP4437 [EMAIL PROTECTED] ~]# ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] yum-security fix for info-security command
James Antill wrote: With the recent generation of updateinfo.xml it's become obvious that info-security is doing the wrong thing, as it displays the entire updateinfo metadata for each package (when multiple packages can refferr to the same metadata). This means you can get spammed with the exact same information multiple times, for instance using: yum info-security FEDORA-2007-2214 This is the obvious fix to stop that. You can pull it from: git pull http://people.redhat.com/jantill/gits/yum-utils yum-sec-upmd-info-uniq ...or just apply the attached patch. ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Committed. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] Yum test script
Florian Festi wrote: Tim Lauridsen wrote: Tim Lauridsen wrote: Florian Festi wrote: Tim Lauridsen wrote: I tested the script with the current yum git master branch it gives a lot of FAILED (See attached file) Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again Hmm, the script currently uses the system's yum config. May be your yum configuration or the server it is pointing to is broken. (There was this F7 updates problem quite recently...) FYI: Expect an updated version soon. Florian ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Found the problem. yum --installroot=/tmp/ somecommand don't work with repos there includes $releasever in the mirrorurl= baseurl=, because a package providing 'redhat-release' need to be installed in the install root so yum can detect what version the system has. You must be running with some locale repos mirrorlists, if you are not getting any error. *Argl* yes, should have thought of this. My yum.conf is hard coded to avoid exactly this problem. There is no way in yum to tell the $ARCH and $RELVER when installing a fresh buildroot. These steps make it work: yumdownloader fedora-release rpm -ivh --root=/tmp/yum-release-test fedora-release-7-3.noarch.rpm OK, added a new config var. Default is using the yum config from the release-notes. One may switch to the local config if that helps. Have fun Florian ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Now it is working :-) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] minor improvement to yumdownloader manpage
Neal Becker wrote: yumdownloader man doesn't mention that many (all?) yum options can be used. For example, I was pleased to find that --enablerepo works fine. ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel It is because it inherits all yum's commanline option, so they are descriped in the yum page, but it need to be mentioned in the yumdownloader man page that it inherits all yum command line options. Tim P.S Patches are always welcome :) ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
[Yum-devel] [PATCH] Custom Download callback base class
I have created a Yum Download Base Callback class to make it easier for
3. party users to create custom download progress bars in a simple
ways.
Comments ?
Tim
diff --git a/yum/callbacks.py b/yum/callbacks.py
index e126f54..c1513a5 100644
--- a/yum/callbacks.py
+++ b/yum/callbacks.py
@@ -47,4 +47,113 @@ class ProcessTransNoOutputCallback:
def event(self,state,data=None):
pass
+
+class DownloadBaseCallback( BaseMeter ):
+
+This is class is a base class to use by implement a download progress
+handler to be used with YumBase.repos.setProgressBar.
+
+Example:
+
+from yum.callbacks import DownloadBaseCallback
+
+class MyDownloadCallback( DownloadBaseCallback ):
+
+def updateProgress(self,name,frac,fread,ftime):
+'''
+ Update the progressbar
+@param name: filename
+@param frac: Progress fracment (0 - 1)
+@param fread: formated string containing BytesRead
+@param ftime : formated string containing remaining or elapsed time
+'''
+pct = int( frac*100 )
+print %s : %s % (name,pct)
+
+
+if __name__ == '__main__':
+my = YumBase()
+my.doConfigSetup()
+dnlcb = MyDownloadCallback()
+my.repos.repos.setProgressBar( dnlcb )
+for pkg in my.pkgSack:
+print pkg.name
+
+
+
+def __init__(self):
+BaseMeter.__init__( self )
+self.totSize =
+self.oldName = None
+self.lastPct = 0
+self.totalPct = 0
+self.pkgs = None
+self.numPkgs=0
+self.bump = 0.0
+
+def setPackages(self,pkgs,startPct,numPct):
+self.pkgs = pkgs
+self.numPkgs = len(self.pkgs)
+self.bump = numPct/self.numPkgs
+self.totalPct = startPct
+
+def _getPackage(self,name):
+name = name.split('-')[0]
+if self.pkgs:
+for pkg in self.pkgs:
+if pkg.name == name:
+return pkg
+return None
+
+def update( self, amount_read, now=None ):
+BaseMeter.update( self, amount_read, now )
+
+def _do_start( self, now=None ):
+name = self._getName()
+self.updateProgress(name,0.0,,)
+if not self.size is None:
+self.totSize = format_number( self.size )
+
+def _do_update( self, amount_read, now=None ):
+fread = format_number( amount_read )
+name = self._getName()
+if self.size is None:
+# Elapsed time
+etime = self.re.elapsed_time()
+fetime = format_time( etime )
+frac = 0.0
+self.updateProgress(name,frac,fread,fetime)
+else:
+# Remaining time
+rtime = self.re.remaining_time()
+frtime = format_time( rtime )
+frac = self.re.fraction_read()
+self.updateProgress(name,frac,fread,frtime)
+
+
+def _do_end( self, amount_read, now=None ):
+total_time = format_time( self.re.elapsed_time() )
+total_size = format_number( amount_read )
+name = self._getName()
+self.updateProgress(name,1.0,total_size,total_time)
+
+def _getName(self):
+'''
+Get the name of the package being downloaded
+'''
+if self.text and type( self.text ) == type( ):
+name = self.text
+else:
+name = self.basename
+return name
+
+def updateProgress(self,name,frac,fread,ftime):
+'''
+ Update the progressbar (Overload in child class)
+@param name: filename
+@param frac: Progress fracment (0 - 1)
+@param fread: formated string containing BytesRead
+@param ftime : formated string containing remaining or elapsed time
+'''
+pass
___
Yum-devel mailing list
Yum-devel@linux.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] remove RPMDBPackageSack.installed()
Florian Festi wrote: Hi! While creating the new test frame work I came across several minor issues. One problem is the existence of the RPMDBPackageSack.installed() method. It is currently only supported by the RPMDBPackageSack class. This doesn't allow to replace the rpmdb with an inmemory PackageSack. Seth already rejected the idea of just moving the method to the base class as installed doesn't make any sense for non RpmDB sacks. As I really dislike inconsistent APIs I'd like to suggest to just remove the usage of that method from the code. There are just 7 places in yum and one place in yum-utils where it is used and it is nothing more than a tiny convenience wrapper. In fact it can be replaced quite easily by .searchNevra() - one of our work horse methods. The attached patches remove the usage of the method and add an deprecation warning (feel free to ignore that if we want to keep the method). Florian PS: The patch also fixes a small issue when running without repositories which simplifies setting up the test cases. ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel RPMDBPackageSack.installed() make the code look better and make it easier to understand. self.rpmdb.installed(po) Look much better then self.rpmdb.searchNevra(po.name, po.epoch, po.version, po.release, po.arch) Removing the installed() method is a API breakage and there is other API users out there (yumex, pirut, pungi, revisor, PackageKit etc) and api users (like me) hate this kind of breakage :) from an API users point of view, he/she want to simple and easy to use API, and in this case 'installed(po)' is much better than 'self.rpmdb.searchNevra(n,e,v,r,a)', there have also been done a lot of work to replace n,e,v,r,a tuples with po object, this is a step backwards. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Code cleanup / preparation for test cases
Florian Festi wrote: Hi! More testing fun: The .whatProvides() method is provided by the RpmSack only. In fact that method should be used anymore anyway. And - ta ta - I still had some patches fixing that issue. It also moves the cheaterlookup to contain package objects insted of pkgtups. Can someone please have a short look at them and commit them? TIA Florian ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Looks fine to me and i don't look like it is breaking something, so i have commited the patches. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] remove RPMDBPackageSack.installed()
Panu Matilainen wrote: On Thu, 4 Oct 2007, Tim Lauridsen wrote: Panu Matilainen wrote: The problem with installed() is just that it's the wrong term for this - make it exists() and it'll make sense for all the package sack types. Whether a package is installed or not is just a question whether it exists in rpmdb or not, if you want to keep API compat just make rpmdb.installed() a wrapper for exists(). Sound like a good idea, it still keeps the api simple. Somewhat related, IMO the installed() method belongs to the package, not sack object. So something like for pkg in installable: if self.rpmdb.installed(po=pkg): # do stuff would become for pkg in installable: if pkg.installed(): # do stuff ..but that's another story, dunno how feasible it'd be within yum currently (sorry I haven't been paying that much attention lately) Sound like a great idea, but can be tricky to implement. a YumInstalledPackage know it is installed, but a YumAvailablePackage dont know if it is installed, I know it is available in a repo, but it dont know if it is installed on the system. Yup, the package object would have to know about rpmdb then which is probably not that clean. A simple solution would be to move the installed() method to a higher level object that knows about rpmdb, such as YumBase. Basically class YumBase: ... def installed(self, po): return self.rpmdb.exists(po) and the above example would become for pkg in installable: if self.installed(po): # ... do stuff Sound like a good idea. Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Code cleanup / preparation for test cases
seth vidal wrote: On Thu, 2007-10-04 at 12:07 +0200, Tim Lauridsen wrote: Florian Festi wrote: Hi! More testing fun: The .whatProvides() method is provided by the RpmSack only. In fact that method should be used anymore anyway. And - ta ta - I still had some patches fixing that issue. It also moves the cheaterlookup to contain package objects insted of pkgtups. Can someone please have a short look at them and commit them? TIA Florian ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel Looks fine to me and i don't look like it is breaking something, so i have commited the patches. one minor problem. Since cheaterlookup isn't protected as semi-private by a _ or a __ then we could have consumers of it as what they are now: pkgtups. Thoughts? -sv Yes, that is a possibility, but can't think of a issue where it could be useful outside the depsolver, so i should have been named _cheaterlookup. I you want then i will reverse the patch ? Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] remove RPMDBPackageSack.installed()
seth vidal wrote: On Thu, 2007-10-04 at 13:23 +0200, Tim Lauridsen wrote: Panu Matilainen wrote: On Thu, 4 Oct 2007, Tim Lauridsen wrote: Panu Matilainen wrote: The problem with installed() is just that it's the wrong term for this - make it exists() and it'll make sense for all the package sack types. Whether a package is installed or not is just a question whether it exists in rpmdb or not, if you want to keep API compat just make rpmdb.installed() a wrapper for exists(). Sound like a good idea, it still keeps the api simple. Somewhat related, IMO the installed() method belongs to the package, not sack object. So something like for pkg in installable: if self.rpmdb.installed(po=pkg): # do stuff would become for pkg in installable: if pkg.installed(): # do stuff ..but that's another story, dunno how feasible it'd be within yum currently (sorry I haven't been paying that much attention lately) Sound like a great idea, but can be tricky to implement. a YumInstalledPackage know it is installed, but a YumAvailablePackage dont know if it is installed, I know it is available in a repo, but it dont know if it is installed on the system. Yup, the package object would have to know about rpmdb then which is probably not that clean. A simple solution would be to move the installed() method to a higher level object that knows about rpmdb, such as YumBase. Basically class YumBase: ... def installed(self, po): return self.rpmdb.exists(po) and the above example would become for pkg in installable: if self.installed(po): # ... do stuff Sound like a good idea. -1 We don't need to pollute the top level name space for this. If installed is only a mode of something in the rpmdb then why are we moving it outside of the rpmsack? I see you point, and i agree :) When Florian proposed this whole thing on irc originally I said: 1. it breaks the api if we move installed() 2. installed() makes no sense on PackageSackBase 3. if you want to check to see if a package exists inside whatever sack object you have then we should wrap installed() in the rpmdb around something like exists() in PackageSackBase and have exists take the same args that installed() takes now. Finally, unless there is a compelling reason we need to I do not want to break the api right before we're finished with Fedora 8 and while folks are still thinking about 3.2.X for rhel5/centos5 future releases. +100 Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
Re: [Yum-devel] [PATCH] Code cleanup / preparation for test cases
I you want then i will reverse the patch ? I = if :) Tim ___ Yum-devel mailing list Yum-devel@linux.duke.edu https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
