Bug 219750 - Hotplug script not working in gpsd package.
Hotplug script not working in gpsd package.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gpsd (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Douglas E. Warner
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On: 491018
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-14 23:40 EST by Mikkel L. Ellertson
Modified: 2009-07-15 04:27 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:27:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A small C program to talk to a socket. (992 bytes, text/plain)
2006-12-14 23:40 EST, Mikkel L. Ellertson
no flags Details
lsusb -v listing for PS-360 OEM GPS. (2.27 KB, text/plain)
2007-03-01 15:28 EST, Mikkel L. Ellertson
no flags Details
udev rules for USB GPS devices. (890 bytes, text/plain)
2007-03-22 13:55 EDT, Mikkel L. Ellertson
no flags Details
A small C program to talk to gpsd using a socket. (1.96 KB, text/plain)
2007-04-04 16:44 EDT, Mikkel L. Ellertson
no flags Details
man page for gps-ctrl (804 bytes, text/plain)
2007-04-04 16:46 EDT, Mikkel L. Ellertson
no flags Details
Improved gps control script. (775 bytes, text/plain)
2007-04-04 16:48 EDT, Mikkel L. Ellertson
no flags Details
An add-on package for gpsd. (17.92 KB, application/x-redhat-package-manager)
2007-09-19 14:44 EDT, Mikkel L. Ellertson
no flags Details

  None (edit)
Description Mikkel L. Ellertson 2006-12-14 23:40:27 EST
Description of problem:

The hotplug script from the gpsd package does not execute when you plug in a
Pharos GPS-360 USB. (PS-360 OEM)

How reproducible:

Plug in the GPS. /dev/ttyUSB? is created, but gpsd is not started, or if you
have started it, it is not informed of the added device.

 
Actual results:

/dev/ttyUSB0 is created, but the hotplug script is not run.

Expected results:

/etc/hotplug/usb/gpsd.hotplug to be run, with gpsd started if it is not running,
and gpsd informed of hte added GPS device.


Additional info:

I created these udev rules to run a script that performs the same function as
the hotplug script, using a small C program to talk to the gpsd control socket.

# GPS device.
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", SYSFS{idVendor}=="067b", 
SYSFS{idProduct}=="aaa0", ENV{GPS_DEV}="true", RUN+="/etc/udev/scripts/g

ACTION=="remove", KERNEL=="ttyUSB*", SUBSYSTEM=="tty", ENV{GPS_DEV}=="true",
RUN+="/etc/udev/scripts/gpsd.sh"

The gpsd.sh script:

#!/bin/bash
#
# Script to start/stop gpsd when my GPS is plugged in or removed.
#
CONTROL_SOCKET=/var/run/gpsd.sock
PID_FILE=/var/run/gpsd

GPSD=/usr/sbin/gpsd
GPS_CTRL=/usr/local/sbin/gps-ctrl

if [ $ACTION == add ] && [ $DEVNAME ] ; then
    if [ ! -f $PID_FILE ] ; then
        $GPSD -F $CONTROL_SOCKET -P $PID_FILE > /dev/null
    else
        pid=$(cat $PID_FILE)
        if [ ! -d "/proc/$pid" ] ; then
        $GPSD -F $CONTROL_SOCKET -P $PID_FILE > /dev/null
        fi
    fi
    $GPS_CTRL $CONTROL_SOCKET +$DEVNAME > /dev/null
fi

if [ $ACTION == remove ] && [ $DEVNAME ] ; then
    $GPS_CTRL $CONTROL_SOCKET -$DEVNAME > /dev/null
fi

exit 0

I have attached the C program source as a file.
Comment 1 Mikkel L. Ellertson 2006-12-14 23:40:27 EST
Created attachment 143734 [details]
A small C program to talk to a socket.
Comment 2 Mikkel L. Ellertson 2006-12-14 23:46:29 EST
There is probably a program that does what the C program does, or the Python
code from the supplied hotplug script could be used to do the same thing. The
script checks that gps is realy running, insteadof relying on the pid file
because gpsd does not remove the pid file it created when you kill it. Outside
of that, not much error checking is done. 
Comment 3 Matthew Truch 2006-12-17 11:02:47 EST
Can you try getting the USB id (from lsusb -v), put that into the
/etc/hotplug/usb/gpsd.usermap file as appropriate, restart the hotplug system,
and see if /etc/hotplug/usb/gpsd.hotplug is executed as appropriate when you
plug in your gps?  My guess is that you have a gps with a new enough usb id that
it hasn't made it into the usermap file yet.  
Comment 4 Mikkel L. Ellertson 2006-12-17 11:51:38 EST
(In reply to comment #3)
> Can you try getting the USB id (from lsusb -v), put that into the
> /etc/hotplug/usb/gpsd.usermap file as appropriate, restart the hotplug system,
> and see if /etc/hotplug/usb/gpsd.hotplug is executed as appropriate when you
> plug in your gps?  My guess is that you have a gps with a new enough usb id that
> it hasn't made it into the usermap file yet.  

It is in the stock gpsd.usermap file. (The PS-360 OEM entry.) It works on
systems that use hotplug, but not where udev is handling hotplug events. You can
see that the SYSFS{idVendor} and SYSFS{idProduct} match the values for the
PS-360 OEM line in gpsd.hotplug. There work in the udev rules, so they must
match the device I am using.
 
Comment 5 Gérard Milmeister 2007-02-07 18:42:22 EST
I am sure that the /etc/hotplug does not work any more at all in FC5+.
Hotplugging must be done using udev and hal, so the the hotplug scripts in the
gpsd package are useless.
Comment 6 Mikkel L. Ellertson 2007-02-07 20:22:32 EST
Udev is susposed to be able to run the Hotplug scripts, but I am not sure that
it is working. From /etc/udev/rules.d/51-hotplug.rules:

LABEL="hotplug_comp"                                                            
# compatibility support for the obsolete hotplug.d and dev.d directories        
ENV{UDEVD_EVENT}=="1",  RUN+="/lib/udev/udev_run_hotplugd"                      
RUN+="/lib/udev/udev_run_devd"                                                  

But I am not sure what is susposed to set UDEVD_EVENT to 1.
Comment 7 Gérard Milmeister 2007-02-08 04:29:41 EST
I see. But it seems that /lib/udev/udev_run_hotplugd runs scripts in
/etc/hotplug.d, and not /etc/hotplug.
Comment 8 Matthew Truch 2007-02-27 21:43:08 EST
Sorry I've been ignoring this for so long.  

I've only started to look into getting this to work with native udev, but when I
upgraded gpsd to the most recent version, I did change from hotplug to
hotplug.d, which may let the hotplug compatability scripts run.  Unfortunately,
I don't have a USB GPS, so I've never been able to test this.  

Let me know if gpsd-2.34-1 fixes things for you.  (It was just built; it'll be
on the mirrors in 1-48 hours).  
Comment 9 Gérard Milmeister 2007-03-01 08:36:02 EST
It seems to me that the support for the obsolete hotplug.d doesn't work. After
some testing I found out that udev_run_hotplugd is called without arguments by
udev when the usb device is plugged in. udev_run_hotplugd then looks at
/etc/hotplug.d/default (which doesn't exist). If udev_run_hotplugd is called
(manually) with the argument usb it will effectively look into the
/etc/hotplug.d/usb directory. It then simply executes gpsd.hotplug without
looking at gpsd.usermap.
So I suggest to forget about the obsolete hotplug stuff and do it the right way.
Comment 10 Mikkel L. Ellertson 2007-03-01 15:21:48 EST
It still does not work. In the logs, I get:

Mar  1 14:07:28 mikkel kernel: usb 2-1: new full speed USB device using uhci_hcd
and address 2
Mar  1 14:07:28 mikkel kernel: usb 2-1: configuration #1 chosen from 1 choice
Mar  1 14:07:28 mikkel kernel: usbcore: registered new interface driver usbserial
Mar  1 14:07:28 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for generic
Mar  1 14:07:28 mikkel kernel: usbcore: registered new interface driver
usbserial_generic
Mar  1 14:07:28 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core
Mar  1 14:07:29 mikkel kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for pl2303
Mar  1 14:07:29 mikkel kernel: pl2303 2-1:1.0: pl2303 converter detected
Mar  1 14:07:29 mikkel kernel: usb 2-1: pl2303 converter now attached to ttyUSB0
Mar  1 14:07:29 mikkel kernel: usbcore: registered new interface driver pl2303
Mar  1 14:07:29 mikkel kernel: drivers/usb/serial/pl2303.c: Prolific PL2303 USB
to serial adaptor driver

But gpsd is never started. If I run "/lib/udev/udev_run_hotplugd usb" I get
slightly different results then Gérard Milmeister - the log shows:

Mar  1 14:14:20 mikkel gpsd.hotplug: gpsd.hotplug: exception
exceptions.IndexError yields list index out of range

and gpsd is not started. Are there more tests you would like me to run? It looks
like gpsd.hotplug is not run when the device is plugged in, and running it
manualy does not work. It may be that we need a udev rule to set UDEVD_EVENT to
one for the USB devices.
Comment 11 Mikkel L. Ellertson 2007-03-01 15:28:31 EST
Created attachment 149046 [details]
lsusb -v listing for PS-360 OEM GPS.
Comment 12 Matthew Truch 2007-03-22 12:04:01 EDT
(In reply to comment #10)
> It may be that we need a udev rule to set UDEVD_EVENT to
> one for the USB devices.


Well, what I need are proper UDEV rules to replace the hotplug ones.  But the
udev system makes little sense to me, and I don't have anything to test it with
(my GPS is really old-school plain RS-232).  
Comment 13 Mikkel L. Ellertson 2007-03-22 13:52:51 EDT
I have attached a hotplug rule that will be run when any of the devices in
gpsd.usermap are plugged in or removed. They are set to run a script
"/etc/udev/scripts/gpsd.dev". The ENV{GPS_DEV}="true" causes the remove rule to
be run when the device is removed. I have one script doing both, but you could
use one add and one remove script.

This is necessary because there is not vender/device information to match on
when the device is unplugged.
Comment 14 Mikkel L. Ellertson 2007-03-22 13:55:45 EDT
Created attachment 150680 [details]
udev rules for USB GPS devices.

You may want to double check that I have the vender/device IDs correct.
Comment 15 Mikkel L. Ellertson 2007-04-04 16:44:33 EDT
Created attachment 151711 [details]
A small C program to talk to gpsd using a socket.

A somewhat cleaned up version of the program to talk to gpsd when it was
started using the control socket option. I also added some error checking.
Comment 16 Mikkel L. Ellertson 2007-04-04 16:46:08 EDT
Created attachment 151712 [details]
man page for gps-ctrl

My attempt at creating a man page for gps-ctrl using manedit.
Comment 17 Mikkel L. Ellertson 2007-04-04 16:48:26 EDT
Created attachment 151713 [details]
Improved gps control script.

This is an improved version of the control script to add/remove devices used by
gpsd. It is a used version of the hotplug script, but uses the gps-ctrl program
insteadof the python commands.
Comment 18 Mikkel L. Ellertson 2007-04-04 16:59:18 EDT
Thinking about this, should we be running gpsd as a service, instead of starting
it from hotplug? We could then create a /etc/sysconfig/gpsd config file with the
socket listed there, and source the file when we want to talk to gpsd. You could
also use the standard service functions to determin in gpsd is running. Maybe
run "service gpsd start" from a udev script if gpsd is not running?

If you start gpsd using the control socket option, you are not limited to
adding/removing USB devices. You can add/remove/copntrol serial and PCMCIA GPS
devices as well. One disadvantage would be that any program that checks to see
if gpsd is running would find it running even if there are no GPS devices
currently attached. On my system, xgps will also exit if you remove the last
active GPS device.
Comment 19 David Monniaux 2007-07-16 22:00:05 EDT
ACTION=="add", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
ACTION=="remove", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"

worked for me.
Comment 20 Mikkel L. Ellertson 2007-07-28 20:28:13 EDT
(In reply to comment #19)
> ACTION=="add", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
> SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
> ACTION=="remove", KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20",
> SYSFS{idProduct}=="0406", RUN+="/etc/hotplug.d/usb/gpsd.hotplug add $devpath"
> 
> worked for me.

Are you sure the remove rule gets run? When I was researching this, I found that
there was no idVendor ID to match on when doing a remove. Also, your remove rule
is trying to add the device again, instead of remove it. In any case, udev is
susposed to be able to launch the hotplug script directly - I believe that is
what  51-hotplug.rules is for.
Comment 21 Mikkel L. Ellertson 2007-09-11 21:10:42 EDT
If it would help, I have created an RPM with the udev rules, the udev script,
and the program to talk to the control socket, as well as the man page for it.
The .spec file could be cleaned up, but before I spend the time, I want to see
if it is wanted.
Comment 22 Matthew Truch 2007-09-14 14:26:58 EDT
(In reply to comment #21)
> If it would help, I have created an RPM with the udev rules, the udev script,
> and the program to talk to the control socket, as well as the man page for it.
> The .spec file could be cleaned up, but before I spend the time, I want to see
> if it is wanted.
> 

Yes, it is wanted (as long as it, obviously, doesn't interfere with plain old
gpsd operation).  Unfortunately, I can't test much (if any) of this, I only have
an old-school serial line gps.  

On a slightly unrelated note, Mikkel, are you a Fedora contributor?  Since I
really can't debug much about this package anymore I've been considering
orphaning it and letting someone else (who can use it) take it over.  
Comment 23 Mikkel L. Ellertson 2007-09-19 14:44:12 EDT
Created attachment 199961 [details]
An add-on package for gpsd.

A tempary fix for hotpluging UPS attached GPS devices.
Comment 24 Mikkel L. Ellertson 2007-09-19 14:45:18 EDT
Sorry for the delay. Here is the source RPM. I do not see how it could interfere
with the normal operation, but I could be wrong. It will start gpsd if it is not
running, the same as the hotplug script would. It looks like the next release of
gpsd will have udev rules, so this will no longer be needed.

On your other note, no I am not a Fedora contributor. I probably should become
one. I started using Fedora with FC5, and I have not moved to F7, except for a
test machine. (On the other hand, I was using RedHat before there was a
Fedora...) I will have to think about taking on the responsibility of taking
care of this package.
Comment 25 Bug Zapper 2008-04-04 01:15:23 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 26 Mikkel L. Ellertson 2008-04-04 19:21:59 EDT
I worked with the upstream provider, so the next release should take care of the
problem.
Comment 27 Bug Zapper 2008-05-13 22:30:09 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 John Poelstra 2008-06-27 19:58:25 EDT
Please close this bug when it is addressed in Fedora.  We do not use the
RELEASE_PENDING state.  changing to ASSIGNED
Comment 29 Douglas E. Warner 2008-11-06 10:08:11 EST
I believe we've had a gpsd release since this was last discussed; can anyone confirm whether this is still an issue?
Comment 30 Jérôme Audu 2008-11-27 17:04:50 EST
(In reply to comment #29)
> I believe we've had a gpsd release since this was last discussed; can anyone
> confirm whether this is still an issue?

I'm using a fresh install of Fedora 10 with gpsd-2.37-2.fc9.i386
My GPS is a Keymaze 300

Here output of lsusb
Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

The hotplug script /etc/hotplug.d/usb/gpsd.usermap
include (by default) an entry for my GPS

# The Prolific Technology 2303 (commonly in tandem with SiRF chips)
gpsd.hotplug 0x0003 0x067b 0x2303 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000

But, still no GPSD daemon when GPS is plugged.
(started by hand fix the problem)
Comment 31 Nick Lamb 2008-12-21 05:40:44 EST
Maintainer: To try to fix a problem in a package you maintain, take suggested patches from the other contributors to the Bugzilla comments and apply them to the source package, then build it and upload the resulting packages to testing. Users can then test the fixed packages and let you know if they work.

Although it would be lovely if just waiting a few months and posting "Can anyone confirm whether this is still an issue?" fixed bugs, unfortunately it doesn't. In fact it's worse than useless since it just fills the bug report with noise. If you haven't heard otherwise the bug still exists. Make sure that each "can anyone...?" message offer users something new to try out which might fix their problem, otherwise they have no incentive to do anything.
Comment 32 Mikkel L. Ellertson 2008-12-25 17:46:56 EST
There is a better fix in the SVN tree, and should be included in the next release of GPSD. It works with Udev to create a /dev/gps? symlink for the USB device, and then runs the hotplug wrapper that sends the correct connect/disconnect information to the hotplug script. The hard part on the disconnect is that udev does not have the USB information to test on the disconnect, but you can still test the symlink when a USB device is disconnected.

This is a much better fix then my patches here. The could be deleted, as the information in the SVN tree makes them obsolete.
Comment 33 Douglas E. Warner 2009-03-25 17:01:46 EDT
gpsd 2.39 should have improved udev/hotplug support; I'm not sure if it works in all situations yet, so let me know how things are.
Comment 34 Jérôme Audu 2009-04-08 16:05:14 EDT
An update for my #30 comments as I've just tried gpsd-2.39-3.fc10.i386 package:

Now, "gpsd" start when my "Keymaze 300" is plugged.

but, It does not exit when I unplug my GPS...
here msg from dmesg and some output of my console.

dmesg
----8<--------8<--------8<--------8<--
pl2303 2-1:1.0: device disconnected
----8<--------8<--------8<--------8<--

----8<--------8<--------8<--------8<--
[root ~]# /etc/init.d/gpsd status
gpsd (pid 8155) is running...

[root@bebe ~]# /etc/init.d/gpsd stop
Stopping gpsd:                                             [  OK  ]
----8<--------8<--------8<--------8<--

How to check / trace is there something wrong in a script ?

Another thing, my "Keymaze 300" is know as a broken device
so I need to start gpds with "-b" option. 
I've updated to the /etc/sysconfig/gpsd file for that.
OPTIONS="-b -n"

Maybe it's a good idea to warn the user (maybe at install time)
that some GPS can be broken using default option (=> link to the man page 
of gpsd, or just a tips like use "-b" for safe session...
Comment 35 Nick Lamb 2009-04-09 21:08:10 EDT
There is no gpsd 2.39 in the signed updates, so I looked on koji, is that what you intended Douglas ?

The package from koji, gpsd-2.39-3.fc9.i386 is broken. The gpsd binary is installed as /usr/sbin/gpsd, but the init.d script looks for it in /usr/bin/gpsd and of course this can't work.

I don't know if other problems are fixed, the lack of working init script seems like a showstopper.
Comment 36 Douglas E. Warner 2009-04-09 21:24:59 EDT
(In reply to comment #35)
> There is no gpsd 2.39 in the signed updates, so I looked on koji, is that what
> you intended Douglas ?
> 
> The package from koji, gpsd-2.39-3.fc9.i386 is broken. The gpsd binary is
> installed as /usr/sbin/gpsd, but the init.d script looks for it in
> /usr/bin/gpsd and of course this can't work.
> 
> I don't know if other problems are fixed, the lack of working init script seems
> like a showstopper.  

gpsd 2.39 will most likely not make it into F9 or F10 as it has a soname bump which breaks compatibility with other apps.

I'll have to take a look at the packaged location of gpsd; sbin doesn't seem like the proper place if it's able to be run out of udev now.
Comment 37 Douglas E. Warner 2009-04-09 21:35:02 EDT
(In reply to comment #34)
> How to check / trace is there something wrong in a script ?

I'm not sure; you'd have to ask gpsd-dev.
 
> Another thing, my "Keymaze 300" is know as a broken device
> so I need to start gpds with "-b" option. 
> I've updated to the /etc/sysconfig/gpsd file for that.
> OPTIONS="-b -n"
> 
> Maybe it's a good idea to warn the user (maybe at install time)
> that some GPS can be broken using default option (=> link to the man page 
> of gpsd, or just a tips like use "-b" for safe session...  

/etc/sysconfig is a common place on Red Hat/Fedora systems to configure daemons;  if your Keymaze 3000 has a unique usb id (ie, isn't detected through a serial converter) then we can probably add something to make the '-b' automatic.  Otherwise there will always be configuration required.
Comment 38 Jérôme Audu 2009-04-10 03:38:32 EDT
(In reply to comment #37)
> > Another thing, my "Keymaze 300" is know as a broken device
> > so I need to start gpds with "-b" option. 
> > I've updated to the /etc/sysconfig/gpsd file for that.
> > OPTIONS="-b -n"
> > 
> > Maybe it's a good idea to warn the user (maybe at install time)
> > that some GPS can be broken using default option (=> link to the man page 
> > of gpsd, or just a tips like use "-b" for safe session...  
> 
> /etc/sysconfig is a common place on Red Hat/Fedora systems to configure
> daemons;  if your Keymaze 3000 has a unique usb id (ie, isn't detected through
> a serial converter) then we can probably add something to make the '-b'
> automatic.  Otherwise there will always be configuration required.  

My first msg was not enought clear... If you plug a KeyMaze 300 without "-b" for GPSD, then, the keymaze 300 become useless! So, it would be nice 
to warn the user before... Currently , there is no way to precisely identify 
the keymaze 300 (unique USB id...)

I let you read this email about that.
http://www.nabble.com/Decathlon-Geonaute-Keymaze-300-td16187800.html
Comment 39 Bug Zapper 2009-06-09 18:22:37 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 40 Bug Zapper 2009-07-15 04:27:34 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.