suddenly "yum update" fails on all my FC5 machines
by Joachim Backes
Hi,
since wednesday morning, on all my machines with FC5 "yum update" fails:
yum update
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
core [1/3]
Cannot find a valid baseurl for repo: core
Error: Cannot find a valid baseurl for repo: core
OR:
===
yum update
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
extras [1/3]
Cannot find a valid baseurl for repo: extras
Error: Cannot find a valid baseurl for repo: extras
I don't know, why!!
--
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
University of Kaiserslautern,Computer Center [RHRK],
Systems and Operations, High Performance Computing,
D-67653 Kaiserslautern, PO Box 3049, Germany
--------------------------------------------------
Phone: +49-631-205-2438, FAX: +49-631-205-3056
http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html
17 years, 10 months
Fetchmail problems
by Anne Wilson
From time to time I get fetchmail problems, and don't understand what the
error messages are telling me:
fetchmail -a
fetchmail: socket error while fetching from pop3.tiscali.co.uk
fetchmail: Query status=2 (SOCKET)
fetchmail: Query status=2 (SOCKET)
Frequently this is followed by:
fetchmail: another foreground fetchmail is running at 18351.
Is this a Tiscali problem, or is there something I can do about it?
Anne
17 years, 10 months
Building RPMs for multiple distributions on one machine
by Mark
Hi,
I have started out with FC1, later FC3 and am now on FC4 and just started downloading FC5. I have not migrated all the older
production FC1/FC3 machines to FC3 / FC4 etc, because I did not want to risk breaking them. So I have different machines on
different versions of Fedora
In between, I have made a bunch of RPMs myself.
However, with each version of fedora, sometimes even each version of a kernel, it seems like I need a different build environment.
Instead of using the production machines to build the RPMs on them, am using separate build machines (older machines that have been
phased out).
Since more and more versions need to be supported, it seems to be irrational to set up yet another one of those machines for each
new version that needs to be supported.
What is the best way of dealing with this without having to have a separate build machine for each environment? I tried to google
around a bit but have not found much.
I am thinking something along the lines of having one system with multiple partitions per environment, but am not sure about the
details...
Thinking about the minimum partitions a typical system needs I would come up with:
1. Swap
2. /boot
3. / (root)
1. Since only one environment at a time is running on the machine, the SWAP partition can probably be shared!?
2. I assume I could have one "/boot" partition for all environments together with different kernel images in there?
3. I'd probably need a different root partition ("/") for each environment that has to be kept up2date separately
4. /tmp can probably be shared as well in order to reduce the size of each of the respective root partitions?
5. How about the rpm work directory that all the work is done in? Can that be shared? Right now I am inclined to think that it
shoudl be possible, as long as the spec file uses the right variables in the right place and these variables are initialized
properly by each environment at boot time.
Is this how something like this is done?
Thanks,
MARK
17 years, 10 months
Re: Please help: strange rpm upgrade problem:
by Robinson Tiemuqinke
Hi, Guys,
Thanks for a lot helpful suggestions.
I 'fixed' that problem with dirty hack to the default
valgrind.spec and then rebuild it -- the same spec
file works for both i386 and x86_64 platforms. For
i386 platform valgrind-callgrind is
obsoleted(uninstalled), while on x86_64 the orignal
valgrind.i386, and valgrind-callgrind.i386 are
replaced with newly built valgrind.x86_64 and
valgrind-callgrind.x86_64.
The valgrind-callgrind.x86_64 contains no files at all
-- its only purpose is to obsolete the
valgrind-callgrind.i386 automatically. I just came up
the idea since the valgrind.x86_64 could supersede
orignal valgrind.i386 if the valgrind_callgrind.i386
has been uninstalled manually first.
The following is my patch against the orignal
valgrind.spec. It works but I don't know why -- since
normally a .x86_64 package can only upgrade old
version .x86_64 package, not a old version same name
.i386 one.
Please help, if possible, where can I find related
info?
[root@bkupsvr102 SPECS]# diff valgrind.spec_DIST
valgrind.spec
4c4
< Release: 4
---
> Release: 4_stupidHack
12a13
> %ifarch %{ix86}
13a15
> %endif
25a28
>
33a37,44
> %ifarch x86_64 ppc64
> %package -n valgrind-callgrind
> Group: Development/Debuggers
> Summary: trying to remove 32bit valgrind-callgrind
on x86_64 platform
> %description -n valgrind-callgrind
> Trying to remove 32bit version of valgrind-callgrind
on x86_64 platform
> %endif
>
119a131,135
> %ifarch x86_64 ppc64
> %files -n valgrind-callgrind
> %endif
>
> %endif
--- Jeff Johnson <n3npq.jbj(a)gmail.com> wrote:
>
> On Aug 2, 2006, at 7:53 PM, Robinson Tiemuqinke
> wrote:
>
> > Hi,
> >
> > I'm still running 64bit FC4 on a few x86_64
> platform
> > boxes, and trying to upgrade valgrind to 3.2.0
> from
> > the fedora development tree.
> >
> > the valgrind builds without problems but fails
> the
> > command "rpm -Uvh --test
> >
>
/usr/src/redhat/RPMS/x86_64/valgrind-3.2.0-4.x86_64.rpm"
> > with the following error messages:
> >
> > error: Failed dependencies:
> > valgrind = 1:2.4.0 is needed by
> (installed)
> > valgrind-callgrind-0.9.11-1.i386
> >
> > I've changed the line "Obsoletes:
> valgrind-callgrind"
> > to "Obsoletes: valgrind-callgrind.i386" in
> > valgrind.spec file and recompiled the package but
> > still no luck.
> >
>
> Nope, not gonna work.
>
> > The existing valgrind and valgrind-callgrind are
> both
> > .386 packages while the new valgrind 3.2.0 version
> is
> > compiled as a x86_64 package.
> >
> > On 64bit FC4 O/S can x86_64 packages replace and
> > obsolete related i386 packages? if spcified with
> > "Obsoletes" instructions in .spec file?
>
> Nope, there's no secret incantation to upgrade
> valgrind.i386 with
> valgrind.x86_64.
>
> Multilib is *supposed* to work as follows:
> 1) elf32/elf64 libraries are on different paths.
> 2) elf32/elf64 executables should have equivalent
> functionality and
> be interchangeable.
> 3) all other files are either identical or dealt
> with case by case.
>
> Those multilib assumptions fail miserably for the
> class of programs
> like valgrind that are intrinsically
> elf32 or elf64 specific functionality.
>
> So your easiest fix is to rename "valgrind" to, say,
> "valgrind-
> x86_64", and insure
> that no paths collide with the i386 valgrind package
> files.
>
> hth
>
> 73 de Jeff
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
17 years, 10 months
gnome menu at top of screen..
by bruce
hi..
somehow the app menu in gnome is now at the top of the screen when it was at
the bottom.. so, how can i get it back to the bottom..
thanks
17 years, 10 months
Please help: strange rpm upgrade problem:
by Robinson Tiemuqinke
Hi,
I'm still running 64bit FC4 on a few x86_64 platform
boxes, and trying to upgrade valgrind to 3.2.0 from
the fedora development tree.
the valgrind builds without problems but fails the
command "rpm -Uvh --test
/usr/src/redhat/RPMS/x86_64/valgrind-3.2.0-4.x86_64.rpm"
with the following error messages:
error: Failed dependencies:
valgrind = 1:2.4.0 is needed by (installed)
valgrind-callgrind-0.9.11-1.i386
I've changed the line "Obsoletes: valgrind-callgrind"
to "Obsoletes: valgrind-callgrind.i386" in
valgrind.spec file and recompiled the package but
still no luck.
The existing valgrind and valgrind-callgrind are both
.386 packages while the new valgrind 3.2.0 version is
compiled as a x86_64 package.
On 64bit FC4 O/S can x86_64 packages replace and
obsolete related i386 packages? if spcified with
"Obsoletes" instructions in .spec file?
Please help. Thanks a lot.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
17 years, 10 months
upgrading mysql...
by bruce
hi..
i have FC3, with 4.1.13, i also have FC4 with 4.1.20. however, i can't seem
to find 5.0.x RPMs for FC3/4. do i have to go ahead and build this from
source for the FC3/4 boxes that i have...
thanks
-bruce
17 years, 10 months
dir/list of files
by bruce
hi...
simple question.. can't find the answer.. how do i do a list of files/dir,
and get the number of files in the dir ....
thanks
17 years, 10 months
gnome vs vpnclient
by Jack Howarth
Has anyone else run into the following problem. After installing
the Cisco vpnclient on a Fedora Core 4 machine running the latest
kernel, I was able to use 'vpnclient connect' to connect to our
campus vpn network. However, I find that at that point the gnome
desktop is unable to open new terminal windows until I exit the
vpnclient (terminating the vpn session). At that point, all of the
gnome terminals that I tried to launch appear at once. I have the
machine set to use dhcp to obtain its ip address. Our network folks
don't see this problem on their Ubuntu linux boxes. It would appear
that the gnome desktop isn't properly using the localhost to
authenicate new windows but is relying instead of the hostname
obtained by dhcp. I assume this changes when vpn is active and
is causing the problem. Thanks in advance for any advice on
how to fix this.
Jack
17 years, 10 months
Problems with mtpscsih kernel module
by Brian D. McGrew
Running on a Dell PowerEdge 1800 using Fedora Core 3 and a 2.6.16.16
kernel.
I've built up this new kernel to roll out to our production systems and
it's been in test on a PE1800 for a long time and working fine.
However, the machine that it's been testing on has SATA drives.
Yesterday I moved it to a production system, another PE1800 with SCSI
drives and I'm getting an error
Insmod /lib/modules/mptscshih.ko: -l unknown symbol
The only differences I can find between the two machines is that the
original build/test machine has gcc-3.4.4 and the new machine has
gcc-3.4.2; but it looks like all the system libraries are the same and
everything else.
I even went so far as to move the entire source tree to this machine and
do a make clean and rebuild and reinstall and I'm still having the same
problem. What am I missing here???
Thanks! Problems with mtpscsih kernel module
:b!
Brian D. McGrew { brian(a)visionpro.com || brian(a)doubledimension.com }
--
> This is a test. This is only a test!
Had this been an actual emergency, you would have been
told to cancel this test and seek professional assistance!
17 years, 10 months