Hello,
The latest version of yum doesn't seem to use the local cache. If for some reason, yum -y update has to be restarted (dependency problem, conflicts), it begins to download all the files from the top, including those were previously downloaded. Is this a bug or a feature?
On Fri, 2004-09-10 at 10:42 +0300, Alin Osan wrote:
Hello,
The latest version of yum doesn't seem to use the local cache. If for some reason, yum -y update has to be restarted (dependency problem, conflicts), it begins to download all the files from the top, including those were previously downloaded. Is this a bug or a feature?
1. what version of yum 2. why do you say it's downloading things over and over again?
-sv
On Friday 10 September 2004 10:57, seth vidal wrote:
- what version of yum
yum-2.1.3-1
- why do you say it's downloading things over and over again?
I say it because it happens. First time, it stopped with "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and after I manually installed xorg-x11-font-utils yum -y update started to download all the files from the beginning. I noticed this on a PC at home, it was not a problem since bandwidth is plenty but I'm doing the same thing on a machine at work where I have 512 kbps. I don't want to think about dial-up users...
- why do you say it's downloading things over and over again?
I say it because it happens. First time, it stopped with "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and after I manually installed xorg-x11-font-utils yum -y update started to download all the files from the beginning. I noticed this on a PC at home, it was not a problem since bandwidth is plenty but I'm doing the same thing on a machine at work where I have 512 kbps. I don't want to think about dial-up users...
What files is it that you're seeing it redownload.
A LOT of people have been confused by the ####### progess bar.
that is ONLY Reading information in.
it is NOT downloading ANYTHING
the '====' progress bar is for downloads
'####' - not downloading, just reading.
-sv
On Friday 10 September 2004 11:20, seth vidal wrote:
the '====' progress bar is for downloads
I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download.
On 2004 09 10 (Friday) 11:44, Alin Osan wrote:
On Friday 10 September 2004 11:20, seth vidal wrote:
the '====' progress bar is for downloads
I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download.
Same with lftp: Removing old file `RPMS/glib-1.2.10-15.i386.rpm' Transferring file `RPMS/glib-1.2.10-15.i386.rpm' Removing old file `RPMS/glib-devel-1.2.10-15.i386.rpm' Transferring file `RPMS/glib-devel-1.2.10-15.i386.rpm' ... Maybe they 'touch'-ed them all?
On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote:
On Friday 10 September 2004 11:20, seth vidal wrote:
the '====' progress bar is for downloads
I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download.
the only download that happens every time is the repomd.xml file.
that's a <1000byte file.
-sv
On Friday 10 September 2004 15:55, seth vidal wrote:
the only download that happens every time is the repomd.xml file.
that's a <1000byte file.
No, it's not. Believe me, I know what I'm talking about. How else can I prove it?
On Fri, 2004-09-10 at 16:06 +0300, Alin Osan wrote:
On Friday 10 September 2004 15:55, seth vidal wrote:
the only download that happens every time is the repomd.xml file.
that's a <1000byte file.
No, it's not. Believe me, I know what I'm talking about. How else can I prove it?
file a bug and post the output you're seeing in multiple runs.
-sv
On Fri, 10 Sep 2004 08:55:23 -0400, seth vidal skvidal@phy.duke.edu wrote:
On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote:
On Friday 10 September 2004 11:20, seth vidal wrote:
the '====' progress bar is for downloads
I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download.
the only download that happens every time is the repomd.xml file.
that's a <1000byte file.
As a comparison... i did a full update to rawhide last night...and i just reverted to an older s-c-printer package and used yum to install the newer again. I know the packages and headers for s-c-printer are cached via visual inspection of the cache directories. /var/cache/yum/development/packages/system-config-printer-0.6.112-1.i386.rpm /var/cache/yum/development/headers/system-config-printer-0.6.112-1.i386.hdr
yum did not redownload the s-c-printer header nor the s-c-printer package, so from where I'm sitting, things look like they are working correctly from the cache to me.
-jef"is thinking the rawhide yum should default to -d6 just to save time asking for people to run d5 or d6"spaleta
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Jeff Spaleta Sent: Friday, September 10, 2004 8:15 AM To: Development discussions related to Fedora Core Subject: Re: yum and local cache
On Fri, 10 Sep 2004 08:55:23 -0400, seth vidal skvidal@phy.duke.edu wrote:
On Fri, 2004-09-10 at 11:44 +0300, Alin Osan wrote:
On Friday 10 September 2004 11:20, seth vidal wrote:
the '====' progress bar is for downloads
I didn't know the difference before, but I've got '=========', I even checked with tcpdump, so it's definitely download.
the only download that happens every time is the repomd.xml file.
that's a <1000byte file.
As a comparison... i did a full update to rawhide last night...and i just reverted to an older s-c-printer package and used yum to install the newer again. I know the packages and headers for s-c-printer are cached via visual inspection of the cache directories. /var/cache/yum/development/packages/system-config-printer-0.6.112- 1.i386.rpm /var/cache/yum/development/headers/system-config-printer-0.6.112- 1.i386.hdr
yum did not redownload the s-c-printer header nor the s-c-printer package, so from where I'm sitting, things look like they are working correctly from the cache to me.
-jef"is thinking the rawhide yum should default to -d6 just to save time asking for people to run d5 or d6"spaleta
--
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I can't be sure what it is. I do know that it failed at a particular repository that it work for before.
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I can't be sure what it is. I do know that it failed at a particular repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I
can't
be sure what it is. I do know that it failed at a particular repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
I agree, I was merely confirming the problem. There appears to be an effort to say that it is working and it is not. I didn't do the necessary footwork to describe it because I used another method. Also 'yum upgrade' is no longer an option, which is fine.
I agree, I was merely confirming the problem. There appears to be an effort to say that it is working and it is not. I didn't do the necessary footwork to describe it because I used another method. Also 'yum upgrade' is no longer an option, which is fine.
No, The effort is to say that if it is not working then I need more information.
-sv
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I
can't
be sure what it is. I do know that it failed at a particular repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
So, as the guy who wrote yum I can say w/almost complete certainty yum does not fail quietly.
if something 'failed' there was an error message.
if there was an error message and it is not explained by the content of the error message or the situation then it should probably be filed as a bug.
-sv
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:51 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
and actually it is. It says that if yours is working properly and mine
and
the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some
of
the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
So, as the guy who wrote yum I can say w/almost complete certainty yum does not fail quietly.
if something 'failed' there was an error message.
if there was an error message and it is not explained by the content of the error message or the situation then it should probably be filed as a bug.
-sv
It didn't fail quietly, It failed as has been described in this thread, I just didn't want to continue repeating the same error message. The description of the problem is valid.
fre, 10.09.2004 kl. 16.58 skrev seth vidal:
It didn't fail quietly, It failed as has been described in this thread, I just didn't want to continue repeating the same error message. The description of the problem is valid.
Nothing has been described in this thread.
no output, no error messages, NOTHING.
-sv
But a long thread it is :P
On Fri, 2004-09-10 at 09:58, seth vidal wrote:
It didn't fail quietly, It failed as has been described in this thread, I just didn't want to continue repeating the same error message. The description of the problem is valid.
Nothing has been described in this thread.
no output, no error messages, NOTHING.
-sv
this is the preleminary output I got the error on
[root@c515816-a etc]# yum update
Setting up Update Process Setting up Repo: core repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: freshrpms repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: updates repomd.xml 100% |=========================| 843 B 00:00 Setting up Repo: livna-stable repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found Cannot open/read repomd.xml file for repository: livna-stable failure: repodata/repomd.xml from livna-stable: [Errno 256] No more mirrors to t ry. [r
On Fri September 10 2004 17:58, seth vidal wrote:
Nothing has been described in this thread.
no output, no error messages, NOTHING.
Wrong (again) :-) In my first mail of this thread I described the problem. Here are my posts (again):
###
Hello,
The latest version of yum doesn't seem to use the local cache. If for some reason, yum -y update has to be restarted (dependency problem, conflicts), it begins to download all the files from the top, including those were previously downloaded. Is this a bug or a feature?
###
And the second one, with required informations:
###
On Friday 10 September 2004 10:57, seth vidal wrote:
- what version of yum
yum-2.1.3-1
- why do you say it's downloading things over and over again?
I say it because it happens. First time, it stopped with "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3" and after I manually installed xorg-x11-font-utils yum -y update started to download all the files from the beginning. I noticed this on a PC at home, it was not a problem since bandwidth is plenty but I'm doing the same thing on a machine at work where I have 512 kbps. I don't want to think about dial-up users...
### If and only if yum gets an error like the one before, it will download again all files, will just ignore the files allready downloaded. I'm absolutely sure about this, it happen on two distict machines, both with rawide, I even checked with tcdump to see if there is any bits flow. Otherwise, yum uses the files in cache, but it does not if you get a conflict (like the one that I had, "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3"). Meanwhile, yum is a great tool and you are doing a great job. I'm just trying to help.
On Fri, 10 Sep 2004 23:10:29 +0300, Alin Osan al@casa.org.ro wrote:
If and only if yum gets an error like the one before, it will download again all files, will just ignore the files allready downloaded. I'm absolutely sure about this, it happen on two distict machines, both with rawide, I even checked with tcdump to see if there is any bits flow. Otherwise, yum uses the files in cache, but it does not if you get a conflict (like the one that I had, "Error: xorg-x11-font-utils conflicts: xorg-x11-base-fonts<= 6.7.99.903-3"). Meanwhile, yum is a great tool and you are doing a great job. I'm just trying to help.
I just created two very small test packages... that conflict... and I do not see yum redownloading anything after recieving the conflict error. yum install barapp foolib <snip> Excluding Packages from Local Test Resolving Dependencies barapp-0.1-2.i386.rpm 100% |=========================| 1.7 kB 00:00 foolib-0.2-1.i386.rpm 100% |=========================| 1.6 kB 00:00 Error: barapp conflicts: foolib= 0.2-1
let me point out to you that what you just saw downloaded were the HEADERS as found in /var/cache/yum/<reponame>/headers In my test package case /var/cache/yum/local/headers: -rw-r--r-- 1 root root 1716 Sep 10 16:58 barapp-0.1-2.i386.hdr -rw-r--r-- 1 root root 1600 Sep 10 16:59 foolib-0.2-1.i386.hdr /var/cache/yum/local/packages: is empty No packages are downloaded if a detected conflict causes yum to error out.
Now I go back and just install foolib by itself yum install foolib <snip> Excluding Packages from Local Test Resolving Dependencies
Dependencies Resolved [i] foolib.i386 0:0.2-1 - user Is this ok [y/N]: y foolib-0.2-1.i386.rpm 100% |=========================| 1.9 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction foolib 100 % done 1/1 Complete! That download was the download of the actual package. The headers were NOT re-downloaded! after this second attempt to install foolib without the conflicting barapp package, I now have a cached package. /var/cache/yum/local/packages: -rw-r--r-- 1 root root 1987 Sep 10 16:59 foolib-0.2-1.i386.rpm
to recap..... if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. yum downloads headers from the packages during depresolution. Packages are only downloaded if depresolution clears successfully. you are NOT seeing redownloading of anything. The cache IS working, the header files in the cache ARE being reused.
-jef"happy friday afternoon.... time to go kick a puppy"spaleta
On Sat September 11 2004 00:15, Jeff Spaleta wrote:
yum install barapp foolib
What version of yum do you have? With yum-2.1.3-1 you don't get any headers, just repomd.xml and primary.xml.gz. And the error was reported doing an update of the rawhide (development) version from an official Fedora development mirror.
to recap..... if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. yum downloads headers from the packages during depresolution. Packages are only downloaded if depresolution clears successfully. you are NOT seeing redownloading of anything. The cache IS working, the header files in the cache ARE being reused.
No, it's not. The test is irrelevant, as, I believe, it was not done with the version of yum that caused the problems. It definitely downloads the rpm packages again if you have an error (conflict) like I had, I checked this on two separat machines, I even checked with tcpdump to see the real volume of traffic, it took me almoust 2 hours to download all the updated packages, it stoped with the error that I have described before, manually fixed the conflict and then it took me another 2 hours to download all the packages again. I don't know why is so hard to believe it. Do I need to add my system engineer signature? ;-)
On Sat September 11 2004 00:15, Jeff Spaleta wrote:
to recap..... if yum errors out due to a conflict NO PACKAGES WERE DOWNLOADED. yum downloads headers from the packages during depresolution. Packages are only downloaded if depresolution clears successfully. you are NOT seeing redownloading of anything. The cache IS working, the header files in the cache ARE being reused.
You may be right, I tried to reproduce the error, I have the same situation you described and after a second yum -y update does not download anything again, like it happend to me before. I can't reproduce it, since I can't revert to an older development version and then do the update. The info I gave to Seth was from the console's buffer, I don't have it anymore... I'll go thru yum sources when I'll have the time and I'll see if I'll come up with something. I've been suggested by someone who runs this list that fedora-test-list is more appropriate for this, so I'll continue on that list if something has to add up. Thank you, guys, you're the best.
On Fri, 10 Sep 2004 09:55:22 -0500, Otto Haliburton ottohaliburton@comcast.net wrote:
It didn't fail quietly, It failed as has been described in this thread, I just didn't want to continue repeating the same error message. The description of the problem is valid.
I have NOT seen a full or detailed error message from yum in this thread from anyone who thinks they are seeing a problem with yum's caching behavior.
Its very important... to be as accurate as possible... when reporting problems. And that means giving error messages VERBATIM. All i see in this thread is talk about the error messages being seen, i have not seen the actually yum output reproduced. No one in this thread has actually submitted the actually messages yum was producing in context with the actions being performed. No one has gone through the trouble of running yum in a higher debug level and logging the output.
Now, I don't expect a novice tester to know where to look for yum's cache information like I did to visually inspect that cache files are being stored. I don't expect a novice tester to automatically know they should perhaps maybe look to turn on higher verbosity and debuging output. But what I do expect, and I would dare say most developers would expect from competent testers even novice ones to give accurate and full error and log messages that the programs are producing when trying to communicate a problem.
-jef"if you can't cut and paste, get a digital camera and take a picture of the screen with the yum message text..do whatever it takes to get accurate error messages into the bug report...you did file a bug report right?"spaleta
On Fri, 2004-09-10 at 09:46 -0500, Otto Haliburton wrote:
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but I
can't
be sure what it is. I do know that it failed at a particular repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
livna works fine. the urls have changed which could be causing your problems:
[livna-stable] name=Livna.org for FC$releasever ($basearch) (stable) baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable gpgcheck=1
[livna-unstable] name=Livna.org for FC$releasever ($basearch) (unstable) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable gpgcheck=1
[livna-testing] name=Livna.org for FC$releasever ($basearch) (testing) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing gpgcheck=1
All anyone is saying is that you've got to provide more info than 'it doesn't work'.
tjb
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Thomas J. Baker Sent: Friday, September 10, 2004 9:55 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
On Fri, 2004-09-10 at 09:46 -0500, Otto Haliburton wrote:
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't investigate further. There is something wrong with the new yum, but
I
can't
be sure what it is. I do know that it failed at a particular
repository
that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
and actually it is. It says that if yours is working properly and mine
and
the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some
of
the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
livna works fine. the urls have changed which could be causing your problems:
[livna-stable] name=Livna.org for FC$releasever ($basearch) (stable) baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable gpgcheck=1
[livna-unstable] name=Livna.org for FC$releasever ($basearch) (unstable) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable gpgcheck=1
[livna-testing] name=Livna.org for FC$releasever ($basearch) (testing) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing gpgcheck=1
All anyone is saying is that you've got to provide more info than 'it doesn't work'.
tjb
======================================================================= | Thomas Baker email: tjb@unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | =======================================================================
Look I was just confirming the problem, I had used the yum 2.0... and everything work, immediately after manually installing the new yum if failed on the livna repository and didn't proceed past that point. I wasn't complaining just confirming. I can wait until it is fixed it is no BFD.
On Fri, 2004-09-10 at 10:01 -0500, Otto Haliburton wrote:
livna works fine. the urls have changed which could be causing your problems:
[livna-stable] name=Livna.org for FC$releasever ($basearch) (stable) baseurl= http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable gpgcheck=1
[livna-unstable] name=Livna.org for FC$releasever ($basearch) (unstable) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.unstable gpgcheck=1
[livna-testing] name=Livna.org for FC$releasever ($basearch) (testing) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.testing gpgcheck=1
Look I was just confirming the problem, I had used the yum 2.0... and everything work, immediately after manually installing the new yum if failed on the livna repository and didn't proceed past that point. I wasn't complaining just confirming. I can wait until it is fixed it is no BFD.
I had the same problem. It seems that livna changed the URLs at the same time they started making yum 2.1 compatible repodata. So unless you fix your yum.conf, it's not going to get fixed.
tjb
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't
investigate further. There is something wrong with the new yum, but I can't
be sure what it is. I do know that it failed at a particular
repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
Yep, this bit me also. What happened is that the location of the repo changed. Below is how I have it now.
[livna-stable] name=Livna.org Fedora Compatible Packages (stable) #baseurl= http://rpm.livna.org/fedora/2/$basearch/yum/stable baseurl= http://rpm.livna.org/fedora/2/$basearch/RPMS.stable gpgcheck=1
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Brian Millett Sent: Friday, September 10, 2004 10:01 AM To: fedora-devel-list@redhat.com Subject: RE: yum and local cache
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Friday, September 10, 2004 9:25 AM To: Development discussions related to Fedora Core Subject: RE: yum and local cache
FYI, I had a problem similar to the description here but I didn't
investigate further. There is something wrong with the new yum, but I can't
be sure what it is. I do know that it failed at a particular
repository that it work for before.
'something wrong'
That's not terribly helpful for bugfixing.
-sv
--
and actually it is. It says that if yours is working properly and mine and the others is not working properly, then something is happening in the installation of the new yum that is causing a problem or in my case some of the repositories have something different that is causing a problem. My failed on the livna(sp) repository.
Yep, this bit me also. What happened is that the location of the repo changed. Below is how I have it now.
[livna-stable] name=Livna.org Fedora Compatible Packages (stable) #baseurl= http://rpm.livna.org/fedora/2/$basearch/yum/stable baseurl= http://rpm.livna.org/fedora/2/$basearch/RPMS.stable gpgcheck=1
-- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn
--
I'm going to make the changes now and see if they work. I assume they will. Thanks.
-
Alin Osan -
Brian Millett -
Doncho N. Gunchev -
Jef Spaleta -
Kyrre Ness Sjobak -
Otto Haliburton -
seth vidal -
Thomas J. Baker