similar to: Debug file for -42.0.2 i686 MD5 NOT OK

Being new at distro SOPs, I don't know if this is an unusual thought. With a kernel debug package (or any such debug package) would it be prudent in todays world to have a checksum or signature process to assure the downloaded file is untampered with and complete? What prompts this is I just downloaded the kernel packages that Johnny put up. I had not realized they were so large and thought

Well, there's so few going right now that I'm showing 38 days to get the DVD. My normal dnld from a mirror travels appx. 600Mb/sec. I'll wait until most of the U.S. goes home before I give up and use the normal download though. Here's hoping... -- Bill

On 12 March 2008, "William L. Maltby" <CentOS4Bill at triad.rr.com> wrote: > Message: 95 > Date: Wed, 12 Mar 2008 07:56:42 -0400 > From: "William L. Maltby" <CentOS4Bill at triad.rr.com> > Subject: [CentOS] CentOS 5 Evolution Update errors. > To: CentOS General List <centos at centos.org> > Message-ID: <1205323003.5338.6.camel at

I'm going to bugz this if no one tells me I made another brain-damaged error here. Also, if I can get one confirmation, it'll let me breath easier. I ran a version searching for ".cmd" and ".c" just trying to convince myself I'm not *that* brain-damaged. You'd think after all these years that regex compilation would be pretty darn stable... Oh! Forgot it was

Hello, I ftp'ed the binary RPM for samba from us6.samba.org, and when I tried to verify it, rpm said that MD5 was NOT OK. Has anyone else reported this behavior? Thanks, Hiten Sonpal sonpal@ciholas.com Engineer, CIHOLAS Enterprises Voice: 812 476 2721 x 102 2626 Kotter Ave, Unit #D Fax: 812 476 2881 Evansville, IN 47715 http://www.ciholas.com

Ran yum update this A.M. Got this. Is it a problem for rpmforge, CentOS or just me? Maybe not a problem at all? /etc/ld.so.conf.d files are "box stock", so there were no clues there. TIA for any insight. =================================================== Running Transaction Updating : cups-libs [ 1/10] /sbin/ldconfig: /usr/lib/liblzo.so.1 is

I sometimes receive e-mails I post to this list, like I did the bug I reported about X problems, but other times not, like my first post about that before I reported the bug. That one appeared in gmane, but Evolution never picked it up. And today I've not seen either of my posts but I know it got there because I did see a reply to my post about the flash plugin and it had a snippet of my post

Hi list, Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think). The RPMs on our internal mirror are in-tact and pass a 'rpm -- checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check. This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget

On 2015-04-04, Bill Maltby (C4B) <centos4bill at gmail.com> wrote: > On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote: >> 100% with Digimer here. <snip> > >> All this energy should be put into contributing towards to the >> project, testing, helping out community. > > Well, I used to agree. But when a bug report filed in December goes > untouched entering

I need to start running a dual head on one of my machines. Eventual target is CentOS 5.x. Decided to test first on my 4.6 setup (eventually it will achieve 5.x). Both machines are fully up to date. The test machine is 4.6, 2 radeon video cards. Searched the web, CentOS site, even bugzilla. This bugzilla entry from a 4.2 system), http://bugs.centos.org/view.php?id=1875 had only a WFM response.

As the subject says. Just an FYI. -- Bill

Anybody have tricks to write the i386 ISO image to DVD? I've tried DVD+-RW, DVD+R, DVD-RW, DVD-R in both Windows 7 (two different writers) and rebooted into CentOS 6 (x86_64) and tried cdrecord (now called wodim). On wodim I've tried overburn, reducing speeds, etc. All give the same results: the same number of bytes are written - indicating the disc is full (according to my calculations)

Alle, Has anyone gotten Zimbra to work on an installation of CentOS4.3, x86_64 architecture? I have tried to install the RHEL4 3.1.4 32-bit version with the following error: Found zimbra-core Error: attempting to install i386 packages on a x86_64 OS. Exiting... Shouldn't this work with 32-bit compat? I've also tried to install RHEL4_64 4.0.0.RC1 but post installation fails when

I thought I'd install the binary RPM for Red Hat 7.1. Following the advice from the ReadMe I checked the GPG signature (sorry, I have very little idea what it is) of the .rpm files. Here is what I got. % rpm --checksig *.rpm R-base-1.3.1-3.i386.rpm: md5 GPG NOT OK R-recommended-1.3.1-1.i386.rpm: md5 (GPG) OK (MISSING KEYS: GPG#97D3544E) Does it indicate any problem? Thanks, Vadim

Looks like Firefox may be getting another update soon, if my problem is not atypical. Prior to the latest, had NP for *months*. Anyone else seeing any problems? BTW, running the recent Java console from sun that was detailed in another thread a week or two back with Firefox. Had NP prior to the latest update, if that offers any useful info. Would like to test the openjdk for us if it's

Folks, Evo update on my 4.x worked just fine. 5.0 generated a bunch of parsing errors preceded and followed by a couple of I/O errors that appear related to an unavailable URL. I first figured corruption on my node, so I yum erased evo, its - connector and -webcal units. The data-server removal looked as if it might remove half my Gnome desktop, so I left it in place. Then I did a selective

Johnny, Thought I'd try these out for you. Looks like a prerequisite is missing? yum --enablerepo=c5-testing install java-1.6.0-openjdk\* <snip the usual gobbledygook> 330 packages excluded due to repository priority protections Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package

I had the electricity go out the other day. When my Centos 4.3 workstation came up, I said yes when it got to the prompt "Unclean shutdown, force filesystem check?" prompt. It ground away for awhile and then said something about a bad superblock. Yikes! I thought, that's a bad sign. After a reboot, I got nothing but a grub> prompt. I tried booting into rescue mode using the

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: screen defaults to not using Unix98 ptys Advisory ID: RHSA-1999:042-01 Issue date: 1999-10-20 Updated on: Keywords: Cross references: screen unix98 pty permissions --------------------------------------------------------------------- 1. Topic: Screen uses ptys with world

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: New majordomo packages available Advisory ID: RHSA-2000:005-05 Issue date: 2000-01-20 Updated on: 2000-05-31 Product: Red Hat Powertools Keywords: majordomo Cross references: N/A