> -----Original Message-----
> From: Marc Schwartz [mailto:MSchwartz@MedAnalytics.com]
> Don't forget to remove the Mesa-LibGL rpm before doing that.
> rpm -e --nodeps XFree86-Mesa-libGL
> You will need to do that before running both of the NVidia install
> processes and will need to repeat that when there are XFree86 and
> Also, I have found that removing the Mesa-libGL will cause some
> dependency issues when using up2date. So be aware that you may need to
> uninstall it again after some updates.
If I may ask, why do I have to remove this? I've always used the NVIDIA
driver, before fedora, and never had a problem.
I decided to update one of my test systems to rawhide but there seems to
be a problem with python:
.package redhat-config-mouse needs /usr/bin/python2.2 (not provided)
package redhat-config-network-tui needs /usr/bin/python2.2 (not provided)
package redhat-config-nfs needs /usr/bin/python2.2 (not provided)
package redhat-config-samba needs /usr/bin/python2.2 (not provided)
package redhat-config-securitylevel needs /usr/bin/python2.2 (not provided)
package redhat-config-bind needs /usr/bin/python2.2 (not provided)
package redhat-config-date needs /usr/bin/python2.2 (not provided)
package redhat-config-keyboard needs /usr/bin/python2.2 (not provided)
package redhat-config-kickstart needs /usr/bin/python2.2 (not provided)
package redhat-config-language needs /usr/bin/python2.2 (not provided)
package redhat-config-rootpassword needs /usr/bin/python2.2 (not provided)
package redhat-config-soundcard needs /usr/bin/python2.2 (not provided)
package redhat-config-users needs /usr/bin/python2.2 (not provided)
package redhat-config-xfree86 needs /usr/bin/python2.2 (not provided)
For those running rawhide, did you just remove all the redhat-config-
programs or was there some other work around?
| Thomas Baker email: tjb(a)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 |
Has anyone attempted to include zeroconf modules info fedora core: either rendezvous or some open source alternative? If not, I would like to ask for some advice...
It seems that OSI has approved the Apple open source license. I believe that rendezvous is released under this license. If someone were to start creating zeroconf modules that work in fedora, would it be preferable to write everything from scratch or use rendezvous?
I know there are a couple of open source implementations of these things out there like zcip and openslp... Are these good projects to start with?
I know these are nebulous questions, but I am curious to know what would be a good direction to start contributing to this technology.
Academia is a little like child | Parrish M. Myers
rearing, it provides a chance at | The Wacked Jester
immortality without the stretch | parrishmyers(a)yahoo.com
marks -- (unknown source) |
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
Awesome - the saga just keeps getting better - now "yum update" instantly
seg-faults. Fedora is "teh roxor"!
Where's my holy water?
> I have also noticed what appear to be reliability problems with the
> webserver that handles the updates-released yum repository.
> TCP sockets
> get timed out or dropped or something happens to corrupt the RPM
> transfers. up2date doesn't know how to recover from it, but
> if I use yum
> instead, it will retry the transfer and eventually succeed.
> Maybe it's possible that you managed to force some package to install
> that was truncated?
> Vanco, Don wrote:
>> Well, I've got me second system in as many weeks that has had
>> something broken by updating it. I cannot get gnome to start, and
>> sadly it gives no error output.
>> Fresh install of FC1 - gnome / X works fine (Compaq DL320, ATI Rage
>> XL Chipset)
>> Tried to update system via up2date - this lead to a cyclical
>> redundancy where the RPMs would not installed because they failed
>> both MD5 check and appropriate key signature (after installing
>> key???), and no combination of --nosignature and/or --nomd5 could
>> satisfy RPM to install.
>> So - "apt-get update" and let it do it's thing.
>> Now the system will not let a user start X. I can run gdm, but if
>> root or a user tries to log in or even launch X via "startx" (where
>> their default session is gnome) they're immediately bounced out.
>> KDE appears fine. Adding a new user or deleting the .gnom* stuff
>> does nothing. Starting X and then trying to use "gnome-session"
>> rewards me with an immediate seg fault.
>> Aside from this gnome mess - when will the update process stop
>> breaking systems? Pretty much all of my peers (and me if it's not
>> obvious) are tiring of Fedora because of it's inability to provide a
>> stable platform...... and relying solely on an apt repository or yum
>> repository is still to immature for Fedora - they're just not a
>> single site I've found that doesn't have issues of some kind...
>> Using multiple apt/yum repositories appears to be disastrous - I've
>> loaded 4 systems with FC1 (after numerous beta machines) and have a
>> "50 percent failure rate" on machines that have been subsequently
>> rendered problematic (at best) or broken (at worst) by the upgrade
>> process in one fashion or another.....
>> Fedora - the new Mandrake!
Now that I've finally got around to upgrading to Fedora Core 1 (had 0.95
before) I've run into the same installation problem I had before, the
installer does not support the ATI All-In-Wonder 9800 Pro. As I posted
last time, the RedHat 9 installer works fine with the card but the
Fedora Installer doesn't. The installer totally locks up and requires a
hard reset and a text installation must be performed, then the new
drivers must be downloaded from ATI's website (at least they did the
first time, they didn't this time but I'm assuming the upgrade didn't
touch my video driver). I've included my lspci report in the hopes that
someone will be able to fix this so that this doesn't happen to other
people (installing the driver from the prompt is a pain).
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo
00:09.0 Communication controller: National Instruments PCI-GPIB (rev 01)
00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
00:0b.1 Input device controller: Creative Labs SB Live! MIDI/Game Port
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 1b)
00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 1b)
00:11.4 USB Controller: VIA Technologies, Inc. USB (rev 1b)
00:14.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350
01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon
What steps do I need to take to get to the current testing version of the
distro. Is it as simple as installing Core 1, and doing a yum or up2date
with the development packages? Any help at all would be much appreciated.