Updated Packages:
beagle-0.2.1-12 --------------- * Fri Feb 24 2006 Matthias Clasen mclasen@redhat.com 0.2.1-12 - Remove more "run from ." nonsense (#182709) - Don't spew tons of debug output (#182660) - Try to make the trigger more robust (#182679)
fontconfig-2.3.94-1 ------------------- * Fri Feb 24 2006 Matthias Clasen mclasen@redhat.com - 2.3.94-1 - Update to 2.3.94
gdm-1:2.13.0.8-6 ---------------- * Sat Feb 25 2006 Ray Strode rstrode@redhat.com - 1:2.13.0.8-6 - fix a broken link
gnome-icon-theme-2.14.1-1 ------------------------- * Sat Feb 25 2006 Matthias Clasen mclasen@redhat.com 2.14.1-1 - Update to 2.14.1
gnome-utils-1:2.13.93-1 ----------------------- * Sat Feb 25 2006 Matthias Clasen mclasen@redhat.com - 2.13.93-1 - Update to gnome-utils-2.13.93 - Update to gucharmap 1.5.3
librsvg2-2.14.0-1 ----------------- * Sat Feb 25 2006 Matthias Clasen mclasen@redhat.com 2.14.0-1 - Update to 2.14.0
mesa-6.4.2-5 ------------ * Sat Feb 25 2006 Mike A. Harris mharris@redhat.com 6.4.2-5 - Disable the expeimental r300 DRI driver, as it has turned out to cause instability and system hangs for many users.
vte-0.11.19-1.fc5.1 ------------------- * Sat Feb 25 2006 Matthias Clasen mclasen@redhat.com 0.11.19-1 - Update to 0.11.19 - Drop upstreamed patch
xorg-x11-xfs-1:1.0.1-3 ---------------------- * Sat Feb 25 2006 Mike A. Harris mharris@redhat.com 1:1.0.1-3 - Redirect output of "rm -rf fonts.dir" to /dev/null in xfs.init
Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4
Broken deps for ia64 ---------------------------------------------------------- libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0)
Broken deps for ppc ---------------------------------------------------------- libbtctl - 0.6.0-5.ppc requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4
Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0)
Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4
Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4
Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit) libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4
Build System wrote:
mesa-6.4.2-5
- Sat Feb 25 2006 Mike A. Harris mharris@redhat.com 6.4.2-5
- Disable the expeimental r300 DRI driver, as it has turned out to cause instability and system hangs for many users.
2 questions: 1) disable as in not enable by default / need manual config edit to enable, or disable as in needs recompile to enable? 2) if disable as in needs recompile, does it cause problems even when turned of by default. If not then why the disable? In my box the r300 drivers is one of the major features of the new X (if and only if it works, agreed there)
Regards,
Hans
Hans de Goede wrote:
Build System wrote:
mesa-6.4.2-5
- Sat Feb 25 2006 Mike A. Harris mharris@redhat.com 6.4.2-5
- Disable the expeimental r300 DRI driver, as it has turned out to cause instability and system hangs for many users.
2 questions:
- disable as in not enable by default / need manual config edit to
enable, or disable as in needs recompile to enable?
Disable as in, r300_dri.so is no longer included in the binary packages.
- if disable as in needs recompile, does it cause problems even when
turned of by default.
Yes, it causes hangs on many systems, in particular X300 and higher ATI hardware even if just the dri extension module is loaded and no OpenGL software has been ran.
If not then why the disable?
Because it was turned on for a short time as an experiment, with the goal being to disable it completely if there were any signs of severe instability caused by it. That instability has been observed and confirmed, so it is now disabled.
In my box the r300 drivers is one of the major features of the new X (if and only if it works, agreed there)
That is one of the reasons the experiment was tried to begin with. A number of people have requested r300 DRI support for a long time now, and finally a very highly experimental driver was created by reverse engineering. The upstream developers of the r300 driver claim straight out that it is very experimental, and not ready for mainstream use, and ATI has confirmed this as well.
There are a handful of people who have installed and tried the driver and it has worked for them. The exact set of circumstances in which the driver actually works, is not fully known, and so shipping a driver that crashes or otherwise screws up one's display or locks up their system by default, is not an acceptable thing to do.
Part of the experiment of including it in Fedora development was to try and gauge just how well it worked, if at all, and also to see the extent of instability it might cause. Since it /is/ experimental, the intention was always that if we did decide to ship it, DRI would be disabled by default on all of the chips it supports, requiring manual override to enable it.
Unfortunately, the number of people it actually works for is very small compared to the variety of hardware it attempts to cover, and the majority of reports coming back are of the "my system is screwed" nature. Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system.
In order to resolve the remaining "My r300 or better class card locks up when X starts if 'Load "dri"' is present in the xorg.conf, and the problem does not go away if I use 'Option "nodri"', nor even if I delete the r300_dri.so driver, but the problem goes away if I comment 'Load "dri"' out of the config file.", it looks like we're going to have to debug what is causing the hang, and I have a good suspicion that the kernel DRM is being loaded even if DRI gets disabled, and that the kernel DRM is probably hanging the system.
Hardware support that is this buggy/unstable does not belong in the OS until it is stabilized upstream *first*. I'm going to see if removal of the r300 DRM kernel module resolves the remaining problem, and if so, we might remove that too for now.
The extremely small subset of users for whom this driver actually works, and is stable, are free to recompile things if they like, but with the obvious caveat that we don't support it at all, and don't support systems that have it loaded any more than we support 3rd party proprietary drivers.
Mike A. Harris wrote:
<snip>
Taking the fact that even if disabled in software this driver causes stability problems, I fully understand the complete removal, thanks for explaining.
So I agree with you except for:
The extremely small subset of users for whom this driver actually works, and is stable, are free to recompile things if they like, but with the obvious caveat that we don't support it at all, and don't support systems that have it loaded any more than we support 3rd party proprietary drivers.
I understand the don't support part, but I have to disagree with the any more then propietary drivers, that is saying sure its open source but it really is no better then a closed driver since its reversed engineered.
I agree reverse engineered is less good then based on specs, but it still beats a closed driver hands down. Especially since specs are almost always not 100% correct so driver writing is always a bit guessing / reverse engineering.
Regards,
Hans
Hans de Goede wrote:
The extremely small subset of users for whom this driver actually works, and is stable, are free to recompile things if they like, but with the obvious caveat that we don't support it at all, and don't support systems that have it loaded any more than we support 3rd party proprietary drivers.
I understand the don't support part, but I have to disagree with the any more then propietary drivers,
You can disagree with me all you like, but we have never supported software that does not ship with the OS. That includes open source kernel modules, X drivers, or any other software. People using drivers that do not ship with the OS, take full responsibility for any problems they may encounter doing so. In particular for kernel modules and X drivers, both of which can cause complete system hangs.
By all means, feel free to install/use whatever drivers you like, but if they break, and we didn't ship them - you get to keep both pieces, wether they are open source or not.
that is saying sure its open source but it really is no better then a closed driver since its reversed engineered.
That's your personal thoughts, not mine. My claim is essentially:
"if we don't ship it, we don't provide maintenance it, wether it is open source or not period."
If you have a driver installed/loaded in your system which we do not support, and you have a system hang, you'll need to reproduce the hang with the unsupported driver removed before we touch the issue.
This is not something new. It's been like this from the beginning of time, I am only restating it to make sure people are fully aware of it.
I agree reverse engineered is less good then based on specs, but it still beats a closed driver hands down.
That depends on your perspective I guess. An open source driver is better than a closed source one from an OSS advocacy perspective, and that is where my personal ideologies are. However many people would argue with you that "a functional driver that allows me to use all of the features of my hardware and actually works" is a better driver, regardless of wether it is open source or closed source.
The fact is, each individual person has different needs/requirements, and different ideologies of "what is better". I strongly prefer open source drivers over proprietary ones - to the point where I have never installed any of the proprietary drivers on my systems. So in that regard I agree with you.
Having said that, an open source driver that is non-functional or which locks up most people's systems is not particularly what I would call "better" in any sense. At least not until the people developing it get it into a useable and reliable state anyway.
devel@lists.stg.fedoraproject.org
-
Build System -
Hans de Goede -
Mike A. Harris