Re: [Yum-devel] [PATCH] Adds and modifies documentation for the yum/failover module.

On Fri, 2011-07-29 at 15:38 -0400, Nick Jacek wrote: > --- > yum/failover.py | 82 > +-- > 1 files changed, 61 insertions(+), 21 deletions(-) Committed. Although I have to say that 10 minutes ago I would have bet $5 that this didn't exist :)

[Yum-devel] [PATCH] Adds and modifies documentation for the yum/failover module.

--- yum/failover.py | 82 +-- 1 files changed, 61 insertions(+), 21 deletions(-) diff --git a/yum/failover.py b/yum/failover.py index bca9651..00c17ad 100644 --- a/yum/failover.py +++ b/yum/failover.py @@ -19,51 +19,80 @@ # worry about callin

Re: [Yum-devel] yum-cron and handling errors and warnings

On Fri, 2011-07-29 at 12:57 -0400, Matthew Miller wrote: > Where does the update from rpm _itself_ go? That's just spit out to > stdout/stderr by the rpm library, right? There are a few things we "get" from rpm: r1. Call back data. r2. scriptlet errors (goes to a file that yum can then read).

Re: [Yum-devel] [PATCH 04/10] Minor changes to default yum-cron settings.

On Fri, Jul 29, 2011 at 12:59:41PM -0400, James Antill wrote: > No need to unless you are desperate to get it upstream ASAP. Shouldn't > take too long to work out what to do with this. I'm going to do it so I don't forget later. :) -- Matthew Miller mat...@mattdm.org

[Yum-devel] [PATCH] Set MAILTO to root by default.

This sets MAILTO to root by default, instead of empty. The script still checks for the presence of the mail program, so it doesn't add an additional dependency, and basic behavior is the same (since cron sends mail to root by default anyway), but the meaningful subject line is just _better_. --- y

[Yum-devel] [PATCH] Set MAILTO to root by default.

This sets MAILTO to root by default, instead of empty. The script still checks for the presence of the mail program, so it doesn't add an additional dependency, and basic behavior is the same (since cron sends mail to root by default anyway), but the meaningful subject line is just _better_. --- y

Re: [Yum-devel] yum shell and exit codes and plugins

On Fri, 2011-07-29 at 11:17 -0500, Jason L Tibbitts III wrote: > > "MM" == Matthew Miller writes: > > MM> Can you send me what you're patching it to be? > > I haven't patched it into F15 yet (still preparing the rollout) but this > is what I used in the F13 version: > > --- 0yum.cron.quiet

Re: [Yum-devel] [PATCH 04/10] Minor changes to default yum-cron settings.

On Fri, 2011-07-29 at 12:42 -0400, Matthew Miller wrote: > On Fri, Jul 29, 2011 at 12:12:15PM -0400, James Antill wrote: > > I pushed everything but this patch. > > Cool, thanks. > > > > This sets MAILTO to root by default, instead of empty. The script still > > This seems fine, to me. > > Do

Re: [Yum-devel] Should yum-cron upgrade rpm and glibc before other packages?

On Fri, Jul 29, 2011 at 12:45:36PM -0400, James Antill wrote: > ...I think it'd be great to call whatever solution we go with from > yum-cron ... but apart from that I don't think yum-cron should do > anything special. Well, that's easy, then. I'll just leave it alone. :) -- Matthew Miller

Re: [Yum-devel] yum-cron and handling errors and warnings

On Fri, Jul 29, 2011 at 12:21:38PM -0400, James Antill wrote: > > This is used to generate a helpful subject line and (perhaps more > > importantly) to generate meaningful log messages. > > This all actually works very well, but makes me wince. Is there a better way > > in these modern times? > Th

Re: [Yum-devel] Should yum-cron upgrade rpm and glibc before other packages?

On Thu, 2011-07-28 at 21:03 -0400, Matthew Miller wrote: > In the past, I've been bitten by problems where a big update may contain > both RPM and glibc. I'm sure there's other exciting adventures waiting to be > found along these lines. > > Should yum-cron include magic to update yum, rpm, python

Re: [Yum-devel] [PATCH 04/10] Minor changes to default yum-cron settings.

On Fri, Jul 29, 2011 at 12:12:15PM -0400, James Antill wrote: > I pushed everything but this patch. Cool, thanks. > > This sets MAILTO to root by default, instead of empty. The script still > This seems fine, to me. Do you want a separate small patch for just this change? > > Second, DEBUG_LE

[Yum-devel] [PATCH 2/2] Use pkg_warn in groupinstall, so we don't get 666 error messages.

--- yum/__init__.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/yum/__init__.py b/yum/__init__.py index d93fe8f..2149d77 100644 --- a/yum/__init__.py +++ b/yum/__init__.py @@ -2941,7 +2941,7 @@ class YumBase(depsolve.Depsolve): self.verbose_logger.log

[Yum-devel] [PATCH 1/2] Add a pkg_warn to install, for groupinstall.

--- yum/__init__.py | 28 1 files changed, 20 insertions(+), 8 deletions(-) diff --git a/yum/__init__.py b/yum/__init__.py index f97378c..d93fe8f 100644 --- a/yum/__init__.py +++ b/yum/__init__.py @@ -3447,6 +3447,18 @@ class YumBase(depsolve.Depsolve):

Re: [Yum-devel] yum shell and exit codes and plugins

On Fri, 2011-07-29 at 11:17 -0500, Jason L Tibbitts III wrote: > > "MM" == Matthew Miller writes: > > MM> Can you send me what you're patching it to be? > > I haven't patched it into F15 yet (still preparing the rollout) but this > is what I used in the F13 version: > > --- 0yum.cron.quiet

Re: [Yum-devel] yum-cron and handling errors and warnings

On Fri, 2011-07-29 at 10:16 -0400, Matthew Miller wrote: > In bulinux-autoupdate, which is approaching a decade in age, we check for > errors and warnings from yum update transactions by saving standard error > and standard output to files. And then, if there is output on stderr, > awesomely, we do

Re: [Yum-devel] [PATCH] rework introduction to yum.8

On Fri, 2011-07-29 at 13:09 +0200, tim.laurid...@gmail.com wrote: > On Fri, Jul 29, 2011 at 12:56 PM, tim.laurid...@gmail.com > wrote: > > On Fri, Jul 29, 2011 at 12:43 PM, Andrew Ford > > wrote: > >> tim.laurid...@gmail.com wrote: > > It is similar to other high level package manager

Re: [Yum-devel] yum shell and exit codes and plugins

> "MM" == Matthew Miller writes: MM> Can you send me what you're patching it to be? I haven't patched it into F15 yet (still preparing the rollout) but this is what I used in the F13 version: --- 0yum.cron.quiet 2010-02-10 13:42:47.0 -0600 +++ 0yum.cron 2010-05-21 15:54:50.303

Re: [Yum-devel] [PATCH 04/10] Minor changes to default yum-cron settings.

I pushed everything but this patch. On Thu, 2011-07-28 at 21:54 -0400, Matthew Miller wrote: > This sets MAILTO to root by default, instead of empty. The script still > checks for the presence of the mail program, so it doesn't add an additional > dependency, and basic behavior is the same (since

Re: [Yum-devel] yum shell and exit codes and plugins

On Fri, Jul 29, 2011 at 10:03:22AM -0500, Jason L Tibbitts III wrote: > Well, that's exactly how I use it. I install /etc/yum/yum-daily.yum as > part of my kickstart %post that updates yum, rpm, glibc, etc., then > updates everything, then does a bunch of groupinstall calls depending on > what the

Re: [Yum-devel] yum shell and exit codes and plugins

> "sv" == seth vidal writes: sv> so the goal of the yum shell script came from me, I suspect. sv> It meant you could let the admin edit the shell file to do whatever sv> they needed (groupinstall, groupupdate, etc) Well, that's exactly how I use it. I install /etc/yum/yum-daily.yum as part

Re: [Yum-devel] yum shell and exit codes and plugins [was Re: Reorganize yum-cron...]

On Fri, Jul 29, 2011 at 10:35:34AM -0400, seth vidal wrote: > > Because the existing yum-cron did it that way, I followed the model of > > having the actions run corresponding yum scripts. The question is: is > > there any real advantage in doing that? Why not just run "yum upgrade" > > and "yum cl

Re: [Yum-devel] yum shell and exit codes and plugins [was Re: Reorganize yum-cron...]

On Fri, 2011-07-29 at 10:31 -0400, Matthew Miller wrote: > > Also, it'd be nice to go straight to having: > > yum-cron update > > yum-cron cleanup > > yum-cron check-updates > > yum-cron download-updates > > ...and then the only things looking in sysconfig/yum-cron would be > > the .cron.sh files.

[Yum-devel] yum shell and exit codes and plugins [was Re: Reorganize yum-cron...]

> Also, it'd be nice to go straight to having: > yum-cron update > yum-cron cleanup > yum-cron check-updates > yum-cron download-updates > ...and then the only things looking in sysconfig/yum-cron would be > the .cron.sh files. But I'm not going to NAK it for that. Because the existing yum-cron d

[Yum-devel] yum-cron and handling errors and warnings

In bulinux-autoupdate, which is approaching a decade in age, we check for errors and warnings from yum update transactions by saving standard error and standard output to files. And then, if there is output on stderr, awesomely, we do stuff like `egrep -iq '(error|not signed)'` to decide whether it

[Yum-devel] [PATCH] Get the version number for the documentation from yum.__version__.

--- docs/sphinxdocs/conf.py |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/sphinxdocs/conf.py b/docs/sphinxdocs/conf.py index b9f2e1d..867d323 100644 --- a/docs/sphinxdocs/conf.py +++ b/docs/sphinxdocs/conf.py @@ -30,7 +30,7 @@ sys.path.insert(0, os.path.normpat

Re: [Yum-devel] [PATCH] Adds documentation for the yum.depsolve module.

The version is wrong because I set it to the wrong thing in the conf.py file. ;) Patch to use the value in yum.__version__ incoming. --- Nick Jacek - Original Message - From: "James Antill" To: "yum development" Sent: Thursday, 28 July, 2011 5:32:33 PM Subject: Re: [Yum-devel] [PATCH]

Re: [Yum-devel] [PATCH 3/3] Implement getPackageAsync() and getPackageDone()

> There is no way to get progress data out, AFAICS. I can feed the progress through pipe to yum, and handle it in getIdleProcess(). (multiplexing progress with errorlevels). > The API both returns before what you've requested is downloaded _and_ can block for an indeterminate amount of time. N

Re: [Yum-devel] [PATCH] Make yum-cron code and config files prettier.

On Fri, Jul 29, 2011 at 09:06:32AM +0300, Ville Skyttä wrote: > > In a couple of places, yes. And then I figured it was better to make them > > all be that way to be consistent > Speaking only wrt bash, if portability to other shells is not a concern, > I personally prefer [[ over [. Off the top o

Re: [Yum-devel] [PATCH] rework introduction to yum.8

On Fri, Jul 29, 2011 at 12:56 PM, tim.laurid...@gmail.com wrote: > On Fri, Jul 29, 2011 at 12:43 PM, Andrew Ford wrote: >> tim.laurid...@gmail.com wrote:  It is similar to other high level package managers, such as apt-get +and smart\&.  There are some GUI applications that in

Re: [Yum-devel] [PATCH] rework introduction to yum.8

On Fri, Jul 29, 2011 at 12:43 PM, Andrew Ford wrote: > tim.laurid...@gmail.com wrote: >>> >>>  It is similar to other high level package managers, such as >>> apt-get >>> +and smart\&.  There are some GUI applications that interface directly to >>> the >>> +\fByum\fP code, but more recent graphica

Re: [Yum-devel] [PATCH] rework introduction to yum.8

tim.laurid...@gmail.com wrote: It is similar to other high level package managers, such as apt-get +and smart\&. There are some GUI applications that interface directly to the +\fByum\fP code, but more recent graphical interface development is happening +with PackageKit and the gnome-packagekit

Re: [Yum-devel] [PATCH] rework introduction to yum.8

> It is similar to other high level package managers, such as > apt-get > +and smart\&.  There are some GUI applications that interface directly to > the > +\fByum\fP code, but more recent graphical interface development is > happening > +with PackageKit and the gnome-packagekit application\&. > +.