rawhide report: 20060405 changes
by Build System
Removed package Guppi
Removed package oaf
Removed package gal
Removed package gnome-print
Removed package gnome-libs
Updated Packages:
a2ps-4.13b-50
-------------
* Tue Apr 04 2006 Tim Waugh <twaugh(a)redhat.com> 4.13b-50
- Use sort correctly in make_font_map.sh (bug #187884).
anaconda-11.1.0.3-1
-------------------
* Tue Apr 04 2006 Chris Lumens <clumens(a)redhat.com> 11.1.0.3-1
- Fix up for rhpxl Modes changes.
- Fix handling of video driver if there's no list of drivers available.
- Add modes files and libuser to images.
- Allow updates to contain entire directories that may be missing.
- Clean up deprecation warnings.
at-spi-1.7.7-5
--------------
* Tue Apr 04 2006 Matthias Clasen <mclasen(a)redhat.com> - 1.7.7-5
- Fix a missing declaration
- Fix segfaults on x86_64
* Tue Apr 04 2006 Matthias Clasen <mclasen(a)redhat.com> - 1.7.7-1
- Update to 1.7.7
atk-1.11.4-2
------------
* Tue Apr 04 2006 Matthias Clasen <mclasen(a)redhat.com> - 1.11.4-2
- Update to 1.11.4
bash-3.1-11
-----------
* Tue Apr 04 2006 Tim Waugh <twaugh(a)redhat.com> 3.1-11
- Patchlevel 16.
bind-30:9.3.2-20.FC6
--------------------
* Tue Apr 04 2006 Jason Vas Dias <jvdias(a)redhat.com> - 30:9.3.2-20
- fix resolver.c ncache_adderesult segfault reported in addenda to bug 173961
(upstream bugs #15642, #15528 ?)
- allow named ability to generate core dumps after setuid (upstream bug #15753)
cups-1:1.2-0.2.rc1.6
--------------------
* Tue Apr 04 2006 Tim Waugh <twaugh(a)redhat.com> 1:1.2-0.2.rc1.6
- Tweak to allow 'usb:/dev/usb/lp0'-style URIs again.
dasher-4.0.2-2
--------------
* Tue Apr 04 2006 Matthias Clasen <mclasen(a)redhat.com> - 4.0.2-2
- Update to 4.0.2
eclipse-changelog-1:2.0.1_fc-26
-------------------------------
* Tue Apr 04 2006 Andrew Overholt <overholt(a)redhat.com> 2.0.1_fc-26
- Add ia64.
eclipse-pydev-1:0.9.3_fc-15
---------------------------
* Tue Apr 04 2006 Andrew Overholt <overholt(a)redhat.com> 0.9.3_fc-15
- Add ia64.
elfutils-0.120-2
----------------
* Tue Apr 04 2006 Roland McGrath <roland(a)redhat.com> - 0.120-2
- Update to 0.120
- License changed to GPL, with some exceptions for using
the libelf, libebl, libdw, and libdwfl library interfaces.
Red Hat elfutils is an included package of the Open Invention Network.
- dwarf.h updated for DWARF 3.0 final specification.
- libelf: Fix corruption in ELF_C_RDWR uses (#187618).
- libdwfl: New function dwfl_version; fixes for offline.
firstboot-1.4.8-1
-----------------
* Tue Apr 04 2006 Chris Lumens <clumens(a)redhat.com> 1.4.8-1
- Allow firstboot to run in kadischi (#186870).
- Updated for rhpxl changes.
gnucash-1.9.3-2
---------------
* Tue Apr 04 2006 Bill Nottingham <notting(a)redhat.com> - 1.9.3-2
- fix conflict with qof (#187267)
gphoto2-2.1.99-10
-----------------
* Tue Apr 04 2006 Radek Vokál <rvokal(a)redhat.com> 2.1.99-10
- fix crash in ptp2 module
* Tue Mar 14 2006 Than Ngo <than(a)redhat.com> 2.1.99-9
- fix gphoto2-config
hplip-0.9.10-4
--------------
* Tue Apr 04 2006 Tim Waugh <twaugh(a)redhat.com> 0.9.10-4
- Use case-insensitive matching. 0.9.8 gave all-uppercase in some
situations.
- Last known working hpijs comes from 0.9.8, so use that.
kdeaccessibility-1:3.5.2-1
--------------------------
* Tue Apr 04 2006 Than Ngo <than(a)redhat.com> 1:3.5.2-1
- update to 3.5.2
kdegames-6:3.5.2-1
------------------
* Tue Apr 04 2006 Than Ngo <than(a)redhat.com> 6:3.5.2-1
- update to 3.5.2
kdemultimedia-6:3.5.2-1
-----------------------
* Tue Apr 04 2006 Than Ngo <than(a)redhat.com> 6:3.5.2-1
- update to 3.5.2
kernel-2.6.16-1.2121_FC6
------------------------
* Tue Apr 04 2006 Dave Jones <davej(a)redhat.com>
- Reenable non-standard serial ports. (#187466)
- Reenable snd-es18xx for x86-32 (#187733)
- Map x86 kernel to 4MB physical address.
librsvg2-2.14.3-2
-----------------
* Tue Apr 04 2006 Matthias Clasen <mclasen(a)redhat.com> 2.14.3-2
- Update to 2.14.3
* Sun Mar 12 2006 Ray Strode <rstrode(a)redhat.com> 2.14.2-1
- Update to 2.14.2
* Sat Mar 11 2006 Bill Nottingham <notting(a)redhat.com> 2.14.1-2
- fix bad libart dep
mkbootdisk-1.5.3-1
------------------
* Wed Apr 05 2006 Peter Vrabec <pvrabec(a)redhat.com> 1.5.3-1
- fix tail command usage (#187876)
* Tue Mar 07 2006 Peter Vrabec <pvrabec(a)redhat.com> 1.5.2-6
- build as noarch
net-snmp-5.3-7
--------------
* Wed Apr 05 2006 Radek Vokál <rvokal(a)redhat.com> 5.3-7
- fix parsing of /proc/diskstats
- fix disman monitor crash
- fix perl vendor name
- fix OID lookup fail
netdump-0.7.14-5
----------------
* Tue Apr 04 2006 Bill Nottingham <notting(a)redhat.com> - 0.7.14-5
- build against glib2
netpbm-10.33-1
--------------
* Wed Apr 05 2006 Jindrich Novy <jnovy(a)redhat.com> 10.33-3
- update to 10.33
- drop upstreamed .ppmdepth patch
- fix segfault in ppmtompeg when encoding jpeg images (#185970)
openssl-0.9.8a-6
----------------
* Tue Apr 04 2006 Tomas Mraz <tmraz(a)redhat.com> - 0.9.8a-6
- fix stale open handles in libica (#177155)
- fix build if 'rand' or 'passwd' in buildroot path (#178782)
- initialize VIA Padlock engine (#186857)
rhpxl-0.19-1
------------
* Tue Apr 04 2006 Chris Lumens <clumens(a)redhat.com> 0.19-1
- Remove obsolete functions in mouse.py.
- Create a new Modes class.
sane-backends-1.0.17-8
----------------------
* Wed Apr 05 2006 Nils Philippsen <nphilipp(a)redhat.com> 1.0.17-8
- don't use automake
* Tue Apr 04 2006 Nils Philippsen <nphilipp(a)redhat.com>
- require gphoto2-devel in sane-backends-devel
* Fri Mar 24 2006 Nils Philippsen <nphilipp(a)redhat.com> 1.0.17-7
- don't include *.la files
scim-qtimm-0.9.4-3
------------------
* Wed Apr 05 2006 Jens Petersen <petersen(a)redhat.com> - 0.9.4-3
- add epoch to obsoletes
selinux-policy-2.2.29-3
-----------------------
* Thu Mar 30 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.29-3
- Get auditctl working in MLS policy
shadow-utils-2:4.0.15-2
-----------------------
* Tue Apr 04 2006 Peter Vrabec <pvrabec(a)redhat.com> 2:4.0.15-2
- properly notify nscd to flush its cache(#186803)
squirrelmail-1.4.6-5.fc6
------------------------
* Tue Apr 04 2006 Warren Togami <wtogami(a)redhat.com> 1.4.6-5
- Fix Chinese and Korean too
subversion-1.3.1-3
------------------
* Tue Apr 04 2006 Joe Orton <jorton(a)redhat.com> 1.3.1-3
- update to 1.3.1
- update to psvn.el r19138 (Stefan Reichoer)
- build -java on s390 again
* Thu Feb 16 2006 Florian La Roche <laroche(a)redhat.com> - 1.3.0-5
- do not package libs within subversion-ruby, these are already
available via the main package
systemtap-0.5.5-2
-----------------
* Tue Apr 04 2006 Roland McGrath <roland(a)redhat.com> - 0.5.5-2
- Rebuilt for devel
* Tue Apr 04 2006 Roland McGrath <roland(a)redhat.com> - 0.5.5-1
- Many changes, affected PRs include: 2068, 2293, 1989, 2334,
1304, 2390, 2425, 953.
* Wed Feb 01 2006 Frank Ch. Eigler <fche(a)redhat.com> - 0.5.4-1
- PRs 1916, 2205, 2142, 2060, 1379
tetex-3.0-20
------------
* Fri Mar 31 2006 Jindrich Novy <jnovy(a)redhat.com> 3.0-20
- define NeedWidePrototypes for xdvi to display Japanese
correctly (#178411)
vim-1:7.0c.000-1
----------------
* Tue Apr 04 2006 Karsten Hopp <karsten(a)redhat.de> 7.0c.000-1
- vim-7.0c BETA
* Wed Mar 22 2006 Karsten Hopp <karsten(a)redhat.de> 7.0aa.000-3
- Rawhide build as vim, opposed to vim7 (prerelease)
- conflict with older man-pages-{it,fr} packages
- cleanup lang stuff
* Thu Mar 16 2006 Karsten Hopp <karsten(a)redhat.de> 7.0aa.000-2
- make it coexist with vim-6 (temporarily)
- new CVS snapshot
xferstats-2.16-14
-----------------
* Fri Apr 14 2006 Bill Nottingham <notting(a)redhat.com> - 2.16-14
- build against glib2
xfig-3.2.4-18
-------------
* Tue Apr 04 2006 Than Ngo <than(a)redhat.com> 3.2.4-18
- no parameter negotiation for xfig, fix #187902
xorg-x11-drv-ati-6.5.7.3-4.cvs20060404
--------------------------------------
* Tue Apr 04 2006 Kristian Høgsberg <krh(a)redhat.com> 6.5.7.3-4.cvs20060404
- Update to CVS snapshot from 20060404.
xorg-x11-drv-i810-1.4.1.3-4.cvs20060322.1
-----------------------------------------
* Tue Apr 04 2006 Kristian Høgsberg <krh(a)redhat.com> 1.4.1.3-4.cvs20060322.1
- Add patch to add missing #include's, specifically assert.h.
xorg-x11-server-1.0.99.2-1
--------------------------
* Tue Apr 04 2006 Kristian Høgsberg <krh(a)redhat.com> 1.0.99.2-1
- Update to 1.0.99.2 snapshot and go back to using mesa-source package.
- Drop xorg-server-1.0.99-composite-visibility.patch.
- Drop xorg-server-1.0.1-backtrace.patch.
- Drop xorg-server-0.99.3-rgb.txt-dix-config-fix.patch.
- Add xorg-server-1.0.99.2-spiffiffity.patch.
* Thu Mar 23 2006 Kristian Høgsberg <krh(a)redhat.com>
- Pass --with-dri-driver-path so we're sure to point it to the right path.
* Wed Mar 22 2006 Soren Sandmann <sandmann(a)redhat.com> 1.0.99.1-2
- Add xorg-server-1.0.99-composite-visibility.patch to get rid of flashing
titlebars in compositing metacity.
xsane-0.99-4
------------
* Wed Apr 05 2006 Nils Philippsen <nphilipp(a)redhat.com> - 0.99-4
- use XSANE.lang instead of xsane.lang to avoid %doc multilib regression
* Tue Apr 04 2006 Nils Philippsen <nphilipp(a)redhat.com> - 0.99-3
- fix medium-definitions patch to not barf on obsolete options in config file
(#185269, by Aldy Hernandez)
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
Broken deps for ia64
----------------------------------------------------------
gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit)
mkbootdisk - 1.5.3-1.noarch requires syslinux
rgmanager - 1.9.31-3.ia64 requires ccs
Broken deps for ppc
----------------------------------------------------------
gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32
mkbootdisk - 1.5.3-1.noarch requires syslinux
Broken deps for ppc64
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit)
geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for s390
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
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 - 1.2.8-2jpp_9fc.s390 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5
Broken deps for s390x
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit)
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit)
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
18 years, 1 month
Re: Asian Squirrelmail trouble
by Warren Togami
Hyde Yamakawa wrote:
> Hello, sir,
>
> I am the one asked to fix the Japanese encoding problem of
> squirrelmail-1.4.6-3.fc4 and thank you again for your fixing.
>
> I have two more concerns about this squirellmail.
> One is the file name in Japanese is mis decoded when save the
> attached file.
> And another is mis decoding part of Japanese in body sometimes.
>
> Should I report these to bugzilla also?
>
> I am just wondering if these are known and inpossible to fix
> because they have been existing quite long time.
>
> I am sorry but if you can speak Japanese so I wrote in English.
> Which is better English or Japanese?
> I am Japanese.
>
> Regards,
> Hyde
>
Sorry, my Japanese language skill is very poor so I must communicate in
English for now.
We are not happy about squirrelmail because it is poorly maintained by
the upstream project and "stuck in the past" with very little progress
and very poor support for non-Western language encodings. I *want* to
replace squirrelmail with something more modern, with strong commercial
and community support behind the project, and well designed
international encoding support. But I don't have time to seek, test,
and package alternatives to squirrelmail currently.
One of our European engineers dwmw2 tried to improve the Unicode
situation in our squirrelmail with the current scripted conversion hack
in an attempt to workaround upstream squirrelmail's horrible
localization policy where their encodings are inconsistently mixed.
This improved things a bit only for some European languages, but not the
Asian languages.
As you may be well aware, it is currently infeasible to expect the Asian
countries to use only Unicode encoding due to the constantly moving
standards and different glyphs in different languages using the same
code-points, among other problems.
In order to support the current reality of language specific encodings
in Asian languages, it would require native developers to "fix" the
problem and submit patches upstream. This however is going to be a
difficult problem because there is no easy agreement among developers
and users in those countries about what exactly is the "best" way of
doing it. To make matters worse, if you look at the current
squirrelmail code it is full of ugly hacks in support of Asian encodings
that bafflingly make little sense. For example, why the heck is the web
interface in EUCJP encoding while e-mail sent and received is
ISO-2022-JP by default?
Within Japan for example, currently users are using mainly ISO-2022-JP,
which is the default encoding in Microsoft Windows XP and below. I
heard that Windows Vista will be UTF-8 by default with support for the
new government mandated JIS X 0213:2004 standard in the private area.
Fedora has been UTF-8 for a long time now.
I suspect this is a cause of "wrong" encodings when saving files from
squirrelmail because some users want the Windows XP default of
ISO-2022-JP encodings and other users want UTF-8 encodings? I don't
know for certain and don't have time to research this myself.
In any case, these encoding troubles for Asian software are difficult to
solve due to the bewildering reality of conflicting requirements and
necessity of supporting both legacy and new systems. Squirrelmail will
probably never be fixed by the current upstream project. If you want it
to be fixed, then native Japanese developers will need to work on it,
then convince the upstream project to accept their patches.
Sorry I cannot be more helpful.
Warren Togami
wtogami(a)redhat.com
18 years, 1 month
Today's rawhide xorg/radeon
by Andy Burns
Since the release of FC5 I've only been keeping up with updates +
updates-testing, until I noticed that rawhide today had xorg/ati updates
So duly installed and restarted X
xorg-x11-drv-ati-6.5.7.3-4.cvs20060404
xorg-x11-server-1.0.99.2-1
With rawhide during the FC5T1/T2/T3 period (before the removal of r300
acceleration from FC5) I never had *any* 3D joy with the opensource
drivers on my X550, they didn't even give me fallback mesa software GL
Am I right in assuming that these drivers contain the recent r300
patches that Dave refers to? http://airlied.livejournal.com/24874.html
I do get some progress, for the first time on this box opensource
drivers don't produce errors with glxinfo/glxgears
I get display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.5)
The GL xscreensavers run, but the (lack of) speed and high CPU usage
lead me to think that I'm not getting h/w 3D, but at least I am now
getting s/w fallback :-)
I am loading DRI/DRM modules in xorg.conf
in /var/log/Xorg.0.log I see drm errors for cards 0 to 254 (which I
think I've always seen)
drmOpenDevice: node name is /dev/dri/card254
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
followed by
(EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
which I think is new to this update
I also see
(EE) AIGLX: Screen 0 is not DRI capable
(II) Loading local sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/lib64/xorg/modules/extensions/libGLcore.so
(II) Module GLcore: vendor="X.Org Foundation"
compiled for 7.0.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) GLX: Initialized MESA-PROXY GL provider for screen 0
It seems harsh to log this progress as a bugzilla entry, so just asking
here first, should I "expect" any more than this at this stage of
development?
18 years, 1 month
rawhide report: 20060407 changes
by Build System
Updated Packages:
alsa-utils-1.0.11-5.rc2
-----------------------
* Thu Apr 06 2006 Martin Stransky <stransky(a)redhat.com> 1.0.11-5.rc2
- fixed rules file (#186494)
- fixed Audigi mixer switch (#187807)
apr-1.2.6-2
-----------
* Thu Apr 06 2006 Joe Orton <jorton(a)redhat.com> 1.2.6-2
- update to 1.2.6
apr-util-1.2.6-2
----------------
* Thu Apr 06 2006 Joe Orton <jorton(a)redhat.com> 1.2.6-2
- update to 1.2.6
- define LDAP_DEPRECATED in apr_ldap.h (r391985, #188073)
audit-1.1.6-1
-------------
* Thu Apr 06 2006 Steve Grubb <sgrubb(a)redhat.com> 1.1.6-1
- New message types
- Support new rule format found in 2.6.17 and later kernels
- Add support for audit by role, clearance, type, sensitivity
cups-1:1.2-0.2.rc1.7
--------------------
* Thu Apr 06 2006 Tim Waugh <twaugh(a)redhat.com> 1:1.2-0.2.rc1.7
- Build requires openldap-devel.
- Sync pstops.c with svn 5372.
gcc-4.1.0-6
-----------
* Thu Apr 06 2006 Jakub Jelinek <jakub(a)redhat.com> 4.1.0-6
- update from gcc-4_1-branch (-r)
- PRs classpath/24752, classpath/27028, libgcj/26625, libgcj/27024,
tree-optimization/26996
- reenable PR c++/19238, c++/21764 fixes, only PR c++/21581 is not
applied
- better fix for Java GC vs. pthread_create (Bryce McKinlay, #,
PR libgcj/13212)
- fix objc_push_parm (#185398)
- fix ICE with -feliminate-dwarf2-dups and using namespace (#187787,
PR debug/27057)
* Wed Apr 05 2006 Jakub Jelinek <jakub(a)redhat.com> 4.1.0-5
- update from gcc-4_1-branch (-r112431:112706)
- PRs bootstrap/26936, bootstrap/27023, classpath/25924, fortran/19303,
fortran/25358, fortran/26816, java/25414, java/26042, java/26858,
libfortran/26735, libgcj/26990, libstdc++/26777, testsuite/25741,
tree-optimization/18527, tree-optimization/26763,
tree-optimization/26830
- merge gomp changes from trunk (-r112602:112603 and -r112618:112619)
- temporarily revert PR c++/21764, c++/19238, c++/21581 fixes (#187399)
ghostscript-8.15.1-8
--------------------
* Thu Apr 06 2006 Tim Waugh <twaugh(a)redhat.com> 8.15.1-8
- Fix pdfwrite (bug #187834).
- CUPS filters go in /usr/lib/cups/filter even on lib64 platforms.
gnome-power-manager-2.15.0-1
----------------------------
* Fri Apr 07 2006 Ray Strode <rstrode(a)redhat.com> - 2.15.0-1
- update to 2.15.0 to get the cool new runtime analysis
graphs.
* Mon Mar 27 2006 Ray Strode <rstrode(a)redhat.com> - 2.14.0-2
- use blank screensaver when lid is closed instead of
of turning off screensaver completly (bug 186849).
httpd-2.2.0-6
-------------
* Thu Apr 06 2006 Joe Orton <jorton(a)redhat.com> 2.2.0-6
- rebuild to pick up apr-util LDAP interface fix (#188073)
kde-i18n-1:3.5.2-1
------------------
* Mon Apr 03 2006 Than Ngo <than(a)redhat.com> 1:3.5.2-1
- update to 3.5.2
kdeaddons-3.5.2-1
-----------------
* Thu Apr 06 2006 Than Ngo <than(a)redhat.com> 3.5.2-1
- update to 3.5.2
kdenetwork-7:3.5.2-1
--------------------
* Thu Apr 06 2006 Than Ngo <than(a)redhat.com> 7:3.5.2-0.1.fc5
- update to 3.5.2
kdepim-6:3.5.2-1
----------------
* Wed Mar 29 2006 Than Ngo <than(a)redhat.com> 6:3.5.2-1
- update to 3.5.2
* Fri Feb 10 2006 Jesse Keating <jkeating(a)redhat.com> - 6:3.5.1-1.2
- bump again for double-long bug on ppc(64)
* Tue Feb 07 2006 Jesse Keating <jkeating(a)redhat.com> - 6:3.5.1-1.1
- rebuilt for new gcc4.1 snapshot and glibc changes
kernel-2.6.16-1.2122_FC6
------------------------
* Thu Apr 06 2006 Dave Jones <davej(a)redhat.com>
- Rebuild without a zillion warnings.
man-pages-pl-0.24-2
-------------------
* Thu Apr 06 2006 Karsten Hopp <karsten(a)redhat.de> 0.24-2
- remove some vim man pages provided by current vim
metacity-2.15.0-3
-----------------
* Thu Apr 06 2006 Soren Sandmann <sandmann(a)redhat.com> - 2.16.0-3
- Bump libcm to 0.0.18.
mkbootdisk-1.5.3-2
------------------
* Thu Apr 06 2006 Peter Vrabec <pvrabec(a)redhat.com> 1.5.3-2
- change noarch back to ExclusiveArch
net-tools-1.60-66
-----------------
* Thu Apr 06 2006 Radek Vokál <rvokal(a)redhat.com> - 1.60-66
- add note about -T to netstat
policycoreutils-1.30.4-4
------------------------
* Thu Apr 06 2006 Karsten Hopp <karsten(a)redhat.de> 1.30.4-4
- added some missing buildrequires
- added Requires: initscripts for /sbin/service
* Thu Apr 06 2006 Karsten Hopp <karsten(a)redhat.de> 1.30.4-3
- use absolute path /sbin/service
scim-1.4.4-13
-------------
* Fri Apr 07 2006 Jens Petersen <petersen(a)redhat.com> - 1.4.4-13
- update to scim-bridge-0.1.4
selinux-policy-2.2.29-4
-----------------------
* Thu Mar 30 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.29-4
- More textrel_shlib_t file path fixes
- Add ada support
subversion-1.3.1-4
------------------
* Thu Apr 06 2006 Joe Orton <jorton(a)redhat.com> 1.3.1-4
- move libsvn_swig_ruby* back to subversion-ruby
system-config-printer-0.6.151.2-1
---------------------------------
* Wed Mar 29 2006 Tim Waugh <twaugh(a)redhat.com> 0.6.151.2-1
- 0.6.151.2:
- Prevent traceback seen in bug #163125.
* Wed Mar 29 2006 Tim Waugh <twaugh(a)redhat.com> 0.6.151.1-1
- 0.6.151.1:
- Don't make the Action->Sharing... menu entry insensitive (bug #187239).
tzdata-2006c-1
--------------
* Thu Apr 06 2006 Petr Machata <pmachata(a)redhat.com> - 2006c-1
- Upstream 2006c
- Time-related changes:
- dozens of historical and commentary changes
- Iran stopped observing DST
- Sri Lanka switches from UTC+6 to UTC+5:30
- America/Thule and America/Edmonton will adopt new US rules,
starting 2007
- Tunisia is adopting regular DST
- Code:
- asctime.c: Chages in format strings to silent gcc warnings
- removing K&R notation from function signatures
- few fixes across the code
* Thu Mar 16 2006 Petr Machata <pmachata(a)redhat.com> - 2006b-2
- Patch for Sri Lanka time zone change (#184514)
wireless-tools-1:28-0.pre16.1.6
-------------------------------
* Thu Apr 06 2006 Dan Williams <dcbw(a)redhat.com> - 1:28-0.pre16.1
- Update to 28 pre16
- Rebuild for WE-20
xorg-x11-server-1.0.99.2-2
--------------------------
* Thu Apr 06 2006 Adam Jackson <ajax(a)redhat.com> 1.0.99.2-2
- Remove LBX to match upstream policy.
- Add Xephyr server.
* Tue Apr 04 2006 Kristian Høgsberg <krh(a)redhat.com> 1.0.99.2-1
- Update to 1.0.99.2 snapshot and go back to using mesa-source package.
- Drop xorg-server-1.0.99-composite-visibility.patch.
- Drop xorg-server-1.0.1-backtrace.patch.
- Drop xorg-server-0.99.3-rgb.txt-dix-config-fix.patch.
- Add xorg-server-1.0.99.2-spiffiffity.patch.
* Thu Mar 23 2006 Kristian Høgsberg <krh(a)redhat.com>
- Pass --with-dri-driver-path so we're sure to point it to the right path.
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
Broken deps for ia64
----------------------------------------------------------
gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit)
mkbootdisk - 1.5.3-1.noarch requires syslinux
rgmanager - 1.9.31-3.ia64 requires ccs
Broken deps for ppc
----------------------------------------------------------
gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32
mkbootdisk - 1.5.3-1.noarch requires syslinux
Broken deps for ppc64
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit)
geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for s390
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2
gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
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 - 1.2.8-2jpp_9fc.s390 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5
Broken deps for s390x
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit)
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
mkbootdisk - 1.5.3-1.noarch requires syslinux
rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit)
gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit)
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
18 years, 1 month
Re: FC 5 libraw1394 as static library
by Warren Togami
Sébastien Sénégas wrote:
> Hi,
>
> I enjoy with the libraw1394 that you support. But i am using now a FC 5
> wich is distributed with the libraw1394 as shared library. So my
> question is what should I do to get the library as static. Should I just
> recompile it or there is a package existing directly built for this
> distrib. I tried to get a package with yum but without any success.
> Could you help me please
> Sébastien
>
It is generally against Fedora policy to ship static libraries in the
distribution so we have been actively removing them over time. In the
vast majority of cases supported by the Fedora distribution, static
libraries are actually not needed and programs that linked them in can
be easily modified to link to the dynamic library.
If you are using the static library for some less usual case like
embedded systems or profiling, then you should build your own static
library from source manually.
Warren Togami
wtogami(a)redhat.com
18 years, 1 month
Re: [Fwd: Fedora Foundation]
by Rahul Sundaram
Hi
> However some development cycles need tighter release control -- like
> the Kernel for example (not that I am picking on any one particular
> portion of this past FC5 testing cycle.) Are people running FC
> installations truly in earnest of implementing software so quickly?
Everytime any version as been withheld as updates there have been
requests for it. So I assume they are. Kernel is one of top five
components getting the largest number of bug reports for a long time
simply because it is critical and covers a large amount of core aspects
of the system and all these updates fix a ton of them.
> Seems like another software outfit liked to push testing of their core
> OpSys out onto the end users shoulders.
What is OpSys? Core development and testing is to be done within the
external community too and that needs to be much more than what is
present currently. Development pace within a project improves when the
line between end users and developers blurs.
> But, maybe I have become
> blinded to the greater SDLC.
What is SDLC?
>
> > > The most important promise about Fedora -- once free, always free -- still
> > > stands. We aim to set the standard for open source innovation. A truly
> > > open Fedora Project is what makes that possible.
>
> Free until the "best of breed" projects are pulled into RHEL and then
> what?
Not necessarily all the best of breed components but what fits into RHEL
product space. RHEL is open source too. So its Free in that aspect
> A code split?
Branches off into RHEL and then Red Hat starts maintaining it as a
product.
> Maybe this is where my understanding of Fedora's
> relationship to RHEL breaks down...
If you got any specific questions, let me know especially if that
understanding is relevant to Fedora.
Rahul
18 years, 1 month
[Fwd: Fedora Foundation]
by Mike Chambers
Just in case any of you aren't on the Announce or Fedora lists, you can
read this for yourself.
Sorry for cross posting or if most have already read this, but didn't
see anyone from either list (or I missed it) really commenting much on
it.
Mike
-------- Forwarded Message --------
> From: Max Spevack <mspevack(a)redhat.com>
> Reply-To: fedora-list(a)redhat.com
> To: fedora-announce-list(a)redhat.com
> Subject: Fedora Foundation
> Date: Tue, 4 Apr 2006 22:55:32 -0400 (EDT)
>
> To my fellow Fedora community members:
>
> As many of you are aware, FUDCon Boston is this Friday. One of the most
> important topics that we will be discussing there is the future of the
> Fedora Project, specifically with regard to the Fedora Foundation.
>
> I'd like to ask you all to read the document that follows this note. It
> reviews Red Hat's intentions in initially announcing the Fedora
> Foundation, and outlines the problems that have led us to the decision to
> move in a different direction. It also discusses the plan that we are
> implementing instead, and the steps that we are taking to ensure that the
> Fedora Project continues to thrive and grow.
>
> It is as complete, honest, and transparent as we can make it. If you feel
> that there are places in which it lacks those qualities, call us on it,
> and we will respond.
>
> This document represents the work of many people both inside of Red Hat
> and within the Fedora community. It is a long read, but a very worthwhile
> one.
>
> So take a look, read, digest, and share your thoughts. I look forward to
> discussing this in great detail on email, and also with as many of you as
> possible in person at LinuxWorld and at FUDCon over the next few days.
> Many of Red Hat's most active Fedora folks will be at those two shows, so
> please come and talk with us.
>
> Sincerely,
> Max Spevack
>
> =========================
>
> Last June, Red Hat announced its intention to launch the Fedora
> Foundation. We've had a lot of smart people working hard to make this
> Foundation happen, but in the end, it just didn't help to accomplish our
> goals for Fedora. Instead, we are restructuring Fedora Project, with
> dramatically increased leadership from within the Fedora community.
>
> The next obvious question -- "Why no Foundation?" -- deserves a detailed
> explanation.
>
> ===
>
> WHY NO FOUNDATION?
>
> When we announced the Foundation, it was with a very specific purpose, and
> in a very specific context. The announcement was made by Mark Webbink,
> who has been the intellectual property guru at Red Hat for a long time
> now. His stated goal for the Foundation: to act as a repository for
> patents that would protect the interests of the open source community.
>
> Once we announced the intention to form a Foundation, people inside and
> outside of Red Hat were interested in working beyond the stated purpose --
> an intellectual property repository -- and instead saw this new Foundation
> as a potential tool to solve all sorts of Fedora-related issues. Every
> Fedora issue became a nail for the Foundation hammer, and the scope of the
> Foundation quickly became too large for efficient progress.
>
> A team moved forward to create the Foundation itself. We created the
> legal entity, came up with some very basic and flexible bylaws, and
> appointed a board to run it temporarily. This all happened pretty
> quickly, because this was the easy part. We had articles of incorporation
> in September 2005.
>
> Then came the hard part: articulating the precise responsibilities of the
> Foundation. This conversation took months, but ultimately it came back
> around, again and again, to a single question: "What could a Fedora
> Foundation accomplish that the Fedora Project, with strong community
> leadership, could not accomplish?"
>
> So here, in order, were the possible answers to that question -- and why
> we found, in every single case, that the Fedora Foundation was not the
> right answer.
>
> ONE: The Fedora Foundation could be an entity for the development of an
> open source patent commons.
>
> This was the obvious starting place, and what we actually announced. One
> of the lurking concerns of the open source community is the threat of
> software patents. The Fedora Foundation could have been an ideal
> repository for defensive patents. We envisioned soliciting patentable
> ideas from businesses and/or individuals, paying for the prosecution of
> these patents, and then guaranteeing open source developers the
> unrestricted right to code against these patents using a similar mechanism
> to the Red Hat patent promise.
> (http://www.redhat.com/legal/patent_policy.html).
>
> What we weren't counting on was the rapid progress of the Open Invention
> Network (http://www.openinventionnetwork.com/press.html), which serves a
> similar purpose for businesses in a much more compelling way. Without
> going into too much detail, it became clear to us that OIN is going to be
> the 800-pound gorilla in the patent commons space, and we were eager to
> join forces.
>
> OK, so much for soliciting patents from businesses. What about
> individuals? If we were to focus the Fedora Foundation's efforts on
> soliciting patentable ideas from individuals, how many could we get? Our
> gut decision: not many. Most developers who actually work for a living
> have agreements with their employers that prevent them from pursuing
> patents independently. Many university students who pursue patents are
> required to grant them to the university.
>
> After putting a lot of work into the idea of a Fedora Foundation patent
> commons, in the end it just didn't seem compelling. So we shelved the
> idea.
>
> TWO: The Fedora Foundation could act as a single point of standing for
> legal issues.
>
> The Free Software Foundation serves this purpose for the GNU projects.
> We thought that the Fedora Foundation might successfully serve the same
> purpose for Fedora projects. Have you ever noticed that the GNU projects
> all require contributors to assign copyright to the FSF? That's because
> there's this legal idea called "standing" that matters deeply to lawyers
> and judges. Here's a little skit that helps to explain why standing is
> important:
>
> BAILIFF: Come to order for case Z-38-BB-92. Plaintiff is Small Software
> Project. Defendant is Great Big Computer Corporation.
>
> JUDGE: OK, have a seat, folks. The docket is busy today, and I've got a
> doctor's appointment in two hours. Plaintiff, what's this all about?
>
> PLAINTIFF'S COUNSEL: Well, your honor, there's this license called the GPL
> that the defendant is *totally* violating. Basically, they stole the
> plaintiff's code and put it into their software program.
>
> DEFENDANT'S COUNSEL: Hold it right there. Your Honor, plaintiff doesn't
> have standing in this case. There's 100 different developers that wrote
> this code, and the plaintiff only represents six of them. Plaintiff
> clearly doesn't even have the legal right to sue us, Your Honor.
>
> JUDGE: Looks like this case could be Pretty Hard, and this whole
> "standing" thing gives me a perfect excuse not to think about it.
> Counsel, get back to me when you've got the other 94 plaintiffs.
>
> So, standing is a big concern. In the world of lawyers, it's one of the
> big potential unknowns around defending open source projects, especially
> projects that have lots of contributors.
>
> The obvious problem with establishing standing in this way, though, is
> that a single entity *must* own *everything* in your project. That's why
> the FSF *requires* copyright assignment.
>
> What Fedora projects currently exist where copyright assignment makes
> sense?
>
> Well... none, as it turns out. Let's look at some of the current Fedora
> projects as examples.
>
> At present, the two most successful Fedora projects are Core and Extras --
> which, together, basically constitute a big Linux distribution. And what
> is a distribution? Ideally, it's a high-quality repackaging and
> integration of content owned by others. That's the whole point. In such
> cases, copyright assignment makes no sense at all.
>
> Then there's the Fedora Documentation project, which produces
> documentation and makes it available under the Open Publication License
> (http://opencontent.org/openpub/) without options. Given the liberal
> nature of this license, it just doesn't seem all that useful to ask
> contributors to assign copyright for defense of these works.
>
> Then there's the Fedora Directory Server, which Red Hat purchased and open
> sourced. No question who holds standing there; it's Red Hat. The time
> may come when the Fedora Directory Server project is ready to incorporate
> lots of changes from the community, but until that time comes, the
> question of copyright assignment is pretty much a theoretical question.
>
> Which is what a lot of this comes down to -- the question of legal
> standing is either an open or theoretical question at best, and probably
> better left to an organization such as the FSF that focuses a great deal
> more attention on these types of questions.
>
> Put another way: we have a finite amount of resources to make Fedora
> better. How much of that cash should be going to expensive lawyers --
> especially if Red Hat already has lawyers who have a strong incentive to
> defend Fedora, should such a defense prove to be necessary?
>
> So the Fedora Foundation didn't seem compelling as a mechanism for
> copyright assignment, either.
>
> THREE: The Fedora Foundation could act as an entity for funding
> Fedora-related activities that Red Hat didn't have great interest in
> funding.
>
> Funny thing, that. We asked some of our closest friends this question:
> "Would you donate to an independent Fedora Foundation?" The answers were
> very interesting, and ran the gamut. Some people were incredibly
> enthusiastic: "We'd love to give money!" Some were neutral: "Thanks, but
> we'd rather contribute code." And some were less enthusiastic: "Red Hat
> is a successful, profitable company. Why are you asking *me* for money?"
>
> Here's another funny thing: if you choose to incorporate as a non-profit
> entity in the United States, then you subject yourself to a number of
> rigorous IRS tax tests. One of these tests is the "public support test."
> If you say you're a public charity, well by golly, you have to prove it.
> If, within four years, you aren't collecting fully one third of your money
> from public sources, then you're not actually a public charity.
>
> People are always shocked when we tell them how many resources Red Hat
> puts into Fedora. If we were to make the Fedora Foundation a truly
> independent entity, then we'd have to track every dime of that expense as
> "in-kind contributions". That means we'd have to track:
>
> * The cost of bandwidth for distributing Fedora to the world;
>
> * Every hour that Red Hat engineers spend working on Fedora, whether that
> is the actual writing of code, release engineering, testing, etc.;
>
> * Legal expenses of running a Foundation;
>
> * Administrative expenses of running a Foundation.
>
> As an intellectual exercise, let's ignore all of those numbers for now
> except for bandwidth. Back in the day, when Red Hat would release a
> distro, we would regularly get angry calls from network admins at big
> datacenters, complaining that we were eating all of their bandwidth. If
> you ever meet any of our IT guys over a beer, be sure to ask them about
> the time we melted a switch at UUNet.
>
> The demand for Fedora is every bit as high, and the March 20 release of
> Fedora Core 5 was no exception. So let's take a conservative guess and
> say that the bandwidth cost for distributing Fedora comes to $1.5 million
> a year. Yes, even though we have BitTorrent trackers and Fedora mirror
> sites worldwide.
>
> That means that a public Fedora Foundation would have to raise $750k in
> public funds -- remember the one-third public support test -- every single
> year, just to pay for *bandwidth*, assuming no growth and no other
> expenses.
>
> So what would happen, under such a scenario, if Red Hat were to decide to
> spend more money on Fedora? Because that's exactly what Red Hat wants to
> do.
>
> There were alternatives to the public charity angle. We could have set up
> a private operating foundation, and we explored this avenue -- but then it
> wouldn't really be an independent entity. It would be a shell. The fact
> that Red Hat would still likely bear the legal risk of Foundation
> decisions, and the complication of raising public funds, made any 501(c)
> less attractive.
>
> In short: the fund raising burden for a truly independent Fedora
> Foundation would be terrifying. So the Fedora Foundation clearly wasn't
> compelling as a fund raising entity -- if anything, it represented an
> impediment to building a better Fedora Project.
>
> FOUR: The Fedora Foundation could provide mechanisms for more community
> participation in key decision-making processes.
>
> >From the day the Fedora Project was started over two years ago, it's been
> our goal to build these mechanisms, Foundation or no Foundation. How
> successful have we been?
>
> Initially, we had some problems. In the last year, though, we've had some
> pretty clear successes. The Fedora Extras project is a good example here.
> When we officially launched it in February 2005 at FUDCon Boston, we put
> together a steering committee that consisted of a pretty even mix of Red
> Hat and community packagers. At FUDCon Germany last summer, we
> strengthened the group with more European members. Earlier this year, we
> successfully handed off leadership of the committee to a community member.
> Red Hat continues to provide logistical and legal support, but Fedora
> Extras policy is determined by the community.
>
> So what happens when the Fedora Extras Steering Committee (also known as
> FESCO) runs into difficulty? Well, they escalate the issue to "the
> Board." And who is "the Board?" It's been the people running the Fedora
> Foundation -- but it's also been the people running the Fedora Project.
> Whenever "the Board" had been asked to make a decision, there's been no
> practical distinction between "Project" and "Foundation."
>
> What *is* vital, whether we're talking about "The Foundation" or "The
> Project," is the actual presence of community members on the board -- but
> more on that later.
>
> FIVE: The Fedora Foundation could serve as a truly independent entity,
> providing the ability for Fedora to grow separately from Red Hat's
> interests.
>
> This is the real heart of the matter. This is what some people want to
> see: a more independent Fedora. This is The Question That Must Be
> Answered.
>
> The simple and honest answer: Red Hat *must* maintain a certain amount of
> control over Fedora decisions, because Red Hat's business model *depends*
> upon Fedora. Red Hat contributes millions of dollars in staff and
> resources to the success of Fedora, and Red Hat also accepts all of the
> legal risk for Fedora. Therefore, Red Hat will sometimes need to make
> tough decisions about Fedora. We won't do it often, and when we do, we
> will discuss the rationale behind such decisions as openly as we can -- as
> we did with the recent Mono decision.
>
> But just because Red Hat has veto power over decisions, it does not follow
> that Red Hat wants to use that power. Nor does it follow that Red Hat
> must make all of the important decisions about Fedora. In fact, effective
> community decision making is one of the most direct measures of Fedora's
> success.
>
> The most important promise about Fedora -- once free, always free -- still
> stands. We aim to set the standard for open source innovation. A truly
> open Fedora Project is what makes that possible.
>
> ===
>
> THE NEW FEDORA PROJECT LEADERSHIP MODEL
>
> Since Fedora's inception two years ago, a diverse global community has
> developed around Fedora -- and, as in any open source project, natural
> leaders have emerged. The time has come to reward some of these leaders
> with the opportunity to define the direction of the Fedora Project at the
> highest level.
>
> Therefore, we've reconstituted the Fedora Project Board to include these
> community leaders directly.
>
> Initially, there are nine board members: five Red Hat members and four
> Fedora community members. This Board is responsible for making all of the
> operational decisions of the greater Fedora project, including decisions
> about budget and strategic direction.
>
> In addition to the nine board members, there is also be a chairman
> appointed by Red Hat, who has veto power over any decision. It's our
> expectation that this veto power will be used infrequently, since we're
> all aware of the negative consequences that could arise from the use of
> such power in a community project.
>
> The chairman of the Fedora Project is Max Spevack. Max has been with Red
> Hat since 2004, previously as a QA engineer and QA team lead for Red Hat
> Network. He is a member of the Fedora Ambassadors steering committee, and
> has been a Linux user since 1999.
>
> The Fedora Project board members from Red Hat are Jeremy Katz, Bill
> Nottingham, Elliot Lee, Chris Blizzard, and Rahul Sundaram.
>
> Jeremy Katz is a Red Hat engineer. He is the longtime maintainer for
> Anaconda, and a founding member of the Fedora Extras steering committee.
>
> Bill Nottingham joined Red Hat in May of 1998, working on projects ranging
> from the initial port of Red Hat Linux to ia64, booting and hardware
> detection, multilib content definition and fixing, and is currently doing
> work related to stateless Linux. He's also been involved in various
> technical lead details, such as package CVS infrastructure and
> distribution content definition.
>
> Elliot Lee has been a software engineer at Red Hat since 1996. His open
> source contributions include release engineering for Fedora Core,
> co-founding the GNOME project, and maintaining assorted open source
> libraries and utilities. He is a founding member of the Fedora Extras
> steering committee. Elliot current leads the Fedora infrastructure team,
> making it easier and enjoyable for contributors to get more done.
>
> Chris Blizzard is an engineering manager for Red Hat. He has served on
> the board of the Mozilla Foundation, and is currently leading the One
> Laptop Per Child project for Red Hat.
>
> Rahul Sundaram is a Red Hat associate based in Pune, India. He is a
> longstanding contributor to multiple Fedora projects, a Fedora Ambassador
> for India, and a member of the Fedora Ambassadors steering committee.
>
> The Fedora Project board members from the community are Seth Vidal, Paul
> W. Frields, Rex Dieter, and a fourth board member to be named as soon as
> possible.
>
> Seth Vidal is the project lead for yum, which is one of the key building
> blocks for software management in Fedora. He also maintains mock, the
> basis for the Fedora Extras build system. He is a founding member of the
> Fedora Extras steering committee, and he was one of the people chiefly
> responsible for the first ever release of Fedora Extras packages in 2005.
> Seth is also the lead administrator of the infrastructure at
> fedoraproject.org, which includes the Fedora project wiki, RSS feed
> aggregator, and bittorrent server.
>
> Paul W. Frields has been a Linux user and enthusiast since 1997, and
> joined the Fedora Documentation Project in 2003, shortly after the launch
> of Fedora. As contributing writer, editor, and a founding member of the
> Documentation Project steering committee, Paul has worked on a variety of
> tasks, including the Documentation Guide, the Installation Guide, the
> document building infrastructure, and the soon-to-emerge RPM packaging
> toolchain. Paul is also a Fedora Extras package maintainer.
>
> Rex Dieter works as Computer System Administrator in the Mathematics
> Department at the University of Nebraska Lincoln. Rex is a KDE advocate
> and founded the KDE Red Hat project. He is also an active contributor to
> Fedora Extras. Rex lives in Omaha, Nebraka, with his wife, 2 children,
> and 4 cats.
>
> It's true that a lot of the key governance details -- term length, board
> composition, election or appointment process -- have yet to be resolved.
> One of the first responsibilities of the new board will be to work with
> the Fedora community to answer these questions.
>
> ===
>
> Red Hat has been supporting a free Linux distribution for over ten years,
> and Red Hat will *always* support a free Linux distribution. We want to
> work together with the Fedora community to make Fedora better. We want a
> Fedora that is a true partnership between Red Hat and the community. We
> want to build effective models to make that partnership real. We want to
> see the folks at MySQL managing MySQL in Fedora. We want to see the folks
> from kde.org managing KDE in Fedora. We want to see the folks at Planet
> CCRMA managing audio production applications in Fedora. We want Fedora to
> be a launching pad not just for open source software, but for open content
> of all kinds. We want the Fedora Project to be a way to fill the
> community with high quality software and content, and we want to empower
> the Fedora community to innovate in ways we'd never even considered.
>
> The new Fedora Project Board has a strong mandate to make these things
> happen, and has the full support of Red Hat. We ask that you, the members
> of the Fedora community, give them your full support as well, and we thank
> you for all the support you've given us so far. We would not have made it
> nearly this far without your patience, your friendship, and your tireless
> help.
18 years, 1 month
Lock up after resume from S3 suspend when ide dma is enabled (FC5)
by k.healy
Hello,
This follows on from a post on the fedora-list...
https://www.redhat.com/archives/fedora-list/2006-April/msg00581.html
Quick summary -- S3 suspend works, system resumes ok, then
after about 20-60 secs it locks up completely.
I've tracked this down to ide dma - booting the kernel with
ide=nodma removes the problem.
I appreciate this is is more than likely an upstream kernel
issue, but hopefully people here could help me confirm this,
and identify the problem in more detail, before taking
things there.
I assume this is somewhat hardware specific, since it
doesn't seem to have been reported already.
I've got a Samsung SP1614N (160GB) PATA disk, running off an
nForce 2 chipset with integrated graphics (GF4MX). (Its a
Soltek SL7-BA-F mainboard with an Athlon XP Barton CPU).
Test case to reproduce on stock FC5 (both 2.6.15-1.2054 and
2.6.16-1.2080 kernels)
1. Reboot, and hit 'a' at the grub prompt to edit the kernel
parameters
2. Add 'apm=off ide=nodma init=/bin/bash', and then boot
(I'm not sure if the apm=off is really necessary)
3. Enter 'echo "mem" > /sys/power/state'
...system should suspend...
4. Wake system
(At this point I have no video (see note below), so I have
to type blind, and toggle the caps lock key to check the
system is still responding)
5. Type some commands, toggle caps lock, wait a few mins.
Confirm the system is still alive.
6. Repeat as above, but remove 'ide=nodma' from the kernel
parameters, and confirm that the system locks up after a
minute or two.
(For me, with dma enabled, once I hit the power button to
resume, the system disk activity LED also comes on and stays
on indefinitely)
Note on video --- Without the nvidia driver loaded, the
video doesn't come back for me after a resume. I'm bypassing
the loading of this, and pretty much everything else using
the init=/bin/bash kernel parameter to give a minimal system
to help isolate this issue. But just to confirm - using the
Nvidia driver rpms from atrpms as described in the
fedora-list post, the system suspends and resumes from X
successfully.
I'd appreciate it if anyone who has a Samsung PATA disk
and/or an nForce 2 chipset could try out this test case.And
any suggestions for getting more information on the lock-up
would be helpful.
There are some kernel messages showing up before it hangs,
but they don't get written to the log because of the ide
issues. I'm going to see if I can dump them to a usb flash
drive.
I've tried sysrq without success, but this is probably
because the video is locked up. Maybe sysrq over a serial
console - is this possible with the stock Fedora kernels?
Even with DMA disabled, some ide error messages show up in
the log...I don't know if they are significant or not
----------------------
hda: status error: status=0x51 { DriveReady SeekComplete
Error }
hda: status error: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE_EXT
hda: status error: status=0x51 { DriveReady SeekComplete
Error }
hda: status error: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE_EXT
done
hda: status error: status=0x51 { DriveReady SeekComplete
Error }
hda: status error: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE_EXT
hda: status error: status=0x51 { DriveReady SeekComplete
Error }
hda: status error: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE_EXT
ide0: reset: success
----------------------
Regards,
Ken
18 years, 1 month
Re: '-Wunused-param' in kernel compiles?
by Petr Vandrovec
[Sorry for breaking threading, but I just copy&pasted this from web archive as I'm
not subscribed to fedora-devel-list]
> On Tue, 2006-04-04 at 19:14 -0700, Tom London wrote:
>> The last few kernels appear to be compiled with '-Wunused-param'. That right?
>>
>> Is this a 'going forward' feature?
>>
>> Appears to break vmware.
>
> I'm not sure that -Wunused-param is what broke VMware. I just tried to
> configure VMware server beta 2 (build 22874) with kernel
> 2.6.16-1.2118_FC6 and found this error buried in the output:
>
> In file included from /tmp/vmware-config0/vmmon-only/linux/driver.h:20,
> from /tmp/vmware-config0/vmmon-only/linux/driver.c:49:
> /tmp/vmware-config0/vmmon-only/./include/compat_wait.h: At top level:
> /tmp/vmware-config0/vmmon-only/./include/compat_wait.h:60: error: conflicting types for ‘poll_initwait’
> include/linux/poll.h:62: error: previous declaration of ‘poll_initwait’ was here
>
> It wouldn't surprise me if the Linux kernel developers changed an API
> that broke VMware.
Yes, it is broken due to -Wunused-param. We attempt to compile (vmmon-only/autoconf/epoll.c)
(Hm, I see a problem that we are using return in function returning void, but as gcc allows
this...)
#include <linux/poll.h>
void poll_test(void) {
struct poll_wqueues test;
return poll_initwait(&test);
}
and if this builds without warning it means that poll_initwait() takes 'struct poll_wqueues*'
as its argument. If it emits warning (that poll_wqueues pointer had to be converted to
poll_table pointer) then code decides that this is pre-epoll kernel. And with current 2.6.16-1.2118
this test fails as even in correct case linux/poll.h emits warnings...
We can probably rewrite this test in the way compat_wait.h uses to reverify it (redeclare
prototype in a form we expect, we added this later as if pre-epoll code is built with epoll
kernel it emits just warning during build, but crashes at runtime), but there are other
tests (one testing type of last argument of nopage vma handler) which I do not know how
to rewrite without using -Werror:
#include <linux/mm.h>
static struct page *LinuxDriverNoPage(struct vm_area_struct *vma, unsigned long address, int *type) {
(void)vma;
(void)address;
*type = VM_FAULT_MINOR;
return NULL;
}
struct vm_operations_Struct vmuser_mops = {
.nopage = LinuxDriverNoPage
};
If you can tell me how to rewrite this detection without relying on -Werror, then we can probably
stop doing that.
Petr
18 years, 1 month
Qt 4 RPM poke
by Simon Perreault
Hi,
You posted on March 13 a spec for Qt 4 that needed just a little bit of work
before being submitted to Fedora Extras. What is the status on that RPM? I'm
very interested in that package. I would be willing to submit it and maintain
it myself if you wish.
18 years, 1 month