Bug 600137

Summary: Cannot Configure Bluetooth DUN For Droid Eris
Product: [Fedora] Fedora Reporter: wdc
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: anton, aron, dcbw, dougsland, gansalmon, huffman, itamar, jonathan, jyundt, kernel-maint, mackendw, madhu.chinakonda, oded, sseago, warlord
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 17:29:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
.xssession-errors file containing bluetooth status
none
Output after trying the 0616 source snapshot from gnome.org none

Description wdc 2010-06-04 02:05:49 UTC
Description of problem:

  "Error: timed out detecting phone details"

comes from the Bluetooth New Device Setup window when I try and enable
"Access the Internet using your mobile phone (DUN)."

Version-Release number of selected component (if applicable):

Kernel:  2.6.33.5-112.fc13.i686
NetworkManager-0.8.1-0.1.git20100510.fc13.i686
ModemManager-0.3-12.git20100504.fc13.i686

Fedora Hardware: Lenovo T60P laptop.

Phone: Droid Eris connecting to PdaNet v 2.42
Droid firmware v 2.1, Baseband version 2.42.00.04.12, 
Kernel 2.6.29-8a03cb9a htc-kernel@and18-2#1, Build Number 2.36.605.1 CL1645907

How reproducible:

Always

Steps to Reproduce:
1. Select "Access the Internet using your mobile phone (DUN)." from the New Device Setup window from the Gnome Bluetooth Applet.

Actual results:

Timeout with error message, "Error: timed out detecting phone details"

Expected results:

Working Bluetooth DUN Setup.


Additional info:

I've reviewed the dialog in bugzilla 595902, and am using that as a template to try and be maximally helpful here.

I am also being affected by bugzilla 566332. I have installed the SELinux policy that appears in that bug report as a temporary work-around, but that is insufficient.

Here is relevant output from running modem-manager --debug:

** (modem-manager:3753): DEBUG: (tty/rfcomm0): could not get port's parent device
** Message: (rfcomm0) opening serial device...
** (modem-manager:3753): DEBUG: <1275611951.213323> (rfcomm0) device open count is 1 (open)
** (modem-manager:3753): DEBUG: (rfcomm0): probe requested by plugin 'Generic'
** (modem-manager:3753): DEBUG: <1275611951.312658> (rfcomm0): --> 'AT+GCAP<CR>'
** (modem-manager:3753): DEBUG: <1275611953.84867> (rfcomm0) device open count is 0 (close)
** Message: (rfcomm0) closing serial device...

** (modem-manager:3753): CRITICAL **: mm_serial_port_close: assertion `priv->open_count > 0' failed

I can't tell from this output if the phone closed the connection or what.

From /var/log messages:

Jun  3 20:36:17 wdc-laptop ntpd[1513]: Listen normally on 10 wlan0 fe80::219:d2ff:fe28:5052 UDP 123
Jun  3 20:36:18 wdc-laptop ntpd[1513]: 0.0.0.0 0628 08 no_sys_peer
Jun  3 20:37:26 wdc-laptop NetworkManager[3765]: <info> BT device 00:24:BA:E5:DF:2B removed
Jun  3 20:37:29 wdc-laptop kernel: btusb_intr_complete: hci0 urb f31a7300 failed to resubmit (1)
Jun  3 20:37:29 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f31a7e00 failed to resubmit (1)
Jun  3 20:37:29 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f31a7b80 failed to resubmit (1)
Jun  3 20:38:39 wdc-laptop bluetoothd[2661]: Discovery session 0x2b550b8 with :1.161 activated
Jun  3 20:38:43 wdc-laptop bluetoothd[2661]: Stopping discovery
Jun  3 20:38:45 wdc-laptop bluetoothd[2661]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Jun  3 20:38:45 wdc-laptop bluetoothd[2661]: pin_code_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Jun  3 20:38:47 wdc-laptop kernel: btusb_intr_complete: hci0 urb e49b3180 failed to resubmit (1)
Jun  3 20:38:47 wdc-laptop kernel: btusb_bulk_complete: hci0 urb e49b3280 failed to resubmit (1)
Jun  3 20:38:47 wdc-laptop kernel: btusb_bulk_complete: hci0 urb e49b3d00 failed to resubmit (1)
Jun  3 20:39:01 wdc-laptop bluetoothd[2661]: link_key_notify (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B, type=0)
Jun  3 20:39:01 wdc-laptop bluetoothd[2661]: probe failed with driver input-headset for device /org/bluez/2659/hci0/dev_00_24_BA_E5_DF_2B
Jun  3 20:39:03 wdc-laptop kernel: btusb_intr_complete: hci0 urb e5f03e80 failed to resubmit (1)
Jun  3 20:39:03 wdc-laptop kernel: btusb_bulk_complete: hci0 urb e5f03800 failed to resubmit (1)
Jun  3 20:39:03 wdc-laptop kernel: btusb_bulk_complete: hci0 urb e5f03080 failed to resubmit (1)
Jun  3 20:39:08 wdc-laptop kernel: btusb_intr_complete: hci0 urb f67af780 failed to resubmit (1)
Jun  3 20:39:08 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f67af600 failed to resubmit (1)
Jun  3 20:39:08 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f67af180 failed to resubmit (1)
Jun  3 20:39:11 wdc-laptop bluetoothd[2661]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Jun  3 20:39:15 wdc-laptop kernel: btusb_intr_complete: hci0 urb f5e7df80 failed to resubmit (1)
Jun  3 20:39:15 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f5e7de80 failed to resubmit (1)
Jun  3 20:39:15 wdc-laptop kernel: btusb_bulk_complete: hci0 urb f5e7d300 failed to resubmit (1)
Jun  3 20:39:55 wdc-laptop dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.90" (uid=0 pid=2659 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.161" (uid=500 pid=3854 comm="bluetooth-wizard))

The first line shows that indeed we have restarted Network Manager after having started modem-manager in debug mode.

I'd be grateful for any thoughts on what is happening and how I could help further isolate the fault.

-Bill

Comment 1 Dan Williams 2010-06-05 04:00:01 UTC
Can you try this again, reproduce the problem, and include ~/.xsession-errors too?  That's where the bluetooth plugin dumps its output, and that's what would get most of the interesting log output.  At this stage, NM isn't really involved at all.

Comment 2 wdc 2010-06-05 12:45:08 UTC
Created attachment 421423 [details]
.xssession-errors file containing bluetooth status

It turns out that the .xsession-errors file currently active has the bluetooth status from my previous attempts.

Is this sufficient, or would you like me to run another, clean test?

Comment 3 Aron Griffis 2010-06-05 16:12:59 UTC
I have the same exact problem, trying to use PdaNet on Droid Incredible with HP Compaq 6510b.

Comment 4 JYundt 2010-06-05 23:01:45 UTC
Same problem here with a Motorola Droid + ASUS 1005HA running Feodra 13.

Comment 5 Brian C. Huffman 2010-06-08 00:00:55 UTC
Same problem with PdaNet on Droid with Dell Latitude D630.  I have verified that I *can* send files to the device via bluetooth.

Comment 6 Jesse Keating 2010-06-14 17:24:56 UTC
I'm seeing this too on F13 with a Nexus 1 and pdanet.  Here is the relevant part of .xsession-errors:

** Message: dun_start: starting DUN device discovery...
** Message: dun_start: calling Connect...

** (bluetooth-wizard:21483): CRITICAL **: dbus_g_proxy_add_signal: assertion `g_datalist_id_get_data (&priv->signal_signatures, q) == NULL' failed
** Message: dun_start: finished
** Message: dun_connect_cb: processing Connect reply
** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0'
** Message: dun_connect_cb: finished

** (bluetooth-wizard:21483): WARNING **: dun_timeout_cb: Error: timed out detecting phone details.

Comment 7 Jesse Keating 2010-06-14 17:26:19 UTC
Adding myself to cc.

Comment 8 Dan Williams 2010-06-15 16:56:20 UTC
If you see bulk & interrupt URB submission errors in 'dmesg' when doing anything with BT, that indicates kernel problems.  I've personally experienced regressions from F11/F12 BT support to a few devices, so I'm not at all confident that things are working well on the kernel side.

For now, moving this to the kernel to figure out why the BT/USB issues are happening.

I've just now verified that a BT adapter and phone combination that works on F11 no longer works on F13 (Kensington Bluetooth USB Adapter + LG Rumor) with the same symptoms we've seen above with failed URB resubmissions.  That points directly to a kernel regression in bluetooth support.

Comment 9 Derek Atkins 2010-06-23 02:34:00 UTC
FWIW, I'm seeing this with my HTC Evo using PDAnet.

From dmesg:

btusb_bulk_complete: hci0 urb ffff8801997a8f00 failed to resubmit (1)
btusb_intr_complete: hci0 urb ffff8801abe6f540 failed to resubmit (1)
btusb_bulk_complete: hci0 urb ffff8801abe6fa80 failed to resubmit (1)
btusb_bulk_complete: hci0 urb ffff8801abe6f6c0 failed to resubmit (1)
type=1400 audit(1277259763.448:13868): avc:  denied  { read } for  pid=27912 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=173628001 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

Running 2.6.32.12-114.fc12.x86_64

Comment 10 Derek Atkins 2010-06-23 02:37:50 UTC
FWIW, here's my output from .xsession-errors:

(bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed

(bluetooth-applet:19766): GLib-GObject-WARNING **: invalid cast from `GtkActionGroup' to `GtkAction'

(bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed
** Message: has_config_widget 38:E7:D8:47:10:0D DialupNetworking
** Message: has_config_widget 38:E7:D8:47:10:0D OBEXObjectPush
** Message: has_config_widget 38:E7:D8:47:10:0D AudioSource
** Message: has_config_widget 38:E7:D8:47:10:0D A/V_RemoteControlTarget
** Message: has_config_widget 38:E7:D8:47:10:0D Headset_-_AG
** Message: has_config_widget 38:E7:D8:47:10:0D HandsfreeAudioGateway
** Message: has_config_widget 38:E7:D8:47:10:0D Phonebook_Access_-_PSE
** Message: has_config_widget 38:E7:D8:47:10:0D DialupNetworking
** Message: has_config_widget 38:E7:D8:47:10:0D OBEXObjectPush
** Message: has_config_widget 38:E7:D8:47:10:0D AudioSource
** Message: has_config_widget 38:E7:D8:47:10:0D A/V_RemoteControlTarget
** Message: has_config_widget 38:E7:D8:47:10:0D Headset_-_AG
** Message: has_config_widget 38:E7:D8:47:10:0D HandsfreeAudioGateway
** Message: has_config_widget 38:E7:D8:47:10:0D Phonebook_Access_-_PSE
** Message: Default Bluetooth adapter is powered
** Message: dun_start: starting DUN device discovery...
** Message: dun_start: calling Connect...
** Message: dun_start: finished
** Message: dun_connect_cb: processing Connect reply
** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0'
** Message: dun_connect_cb: finished

** (bluetooth-wizard:1973): WARNING **: dun_timeout_cb: Error: timed out detecting phone details.

(bluetooth-applet:19766): GLib-GObject-WARNING **: invalid cast from `GtkActionGroup' to `GtkAction'

(bluetooth-applet:19766): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion `GTK_IS_ACTION (action)' failed

Comment 11 Oded Arbel 2010-06-27 10:15:16 UTC
I also have the same issue with a Motorola Milestone with Android 2.1 and PDANet 2.42. My outputs for all the above are identical except various memory locations and mac addresses.

I've opened a GNOME bug 622545 about it ( https://bugzilla.gnome.org/show_bug.cgi?id=622545 ) as it looked like a GNOME Bluetooth issue from my side.

Comment 12 Derek Atkins 2010-06-29 16:39:04 UTC
FWIW, I think this might be a PDAnet issue..  I couldn't use DUN against a Mac, either.  So it might not necessarily be a Linux problem per se.

Comment 13 JYundt 2010-06-29 16:48:44 UTC
I disagree with the issue being related to PDAnet.  I've had my phone (Verizon Motorola Droid 2.1) running with PDAnet on Windows 7 and OSX (Snow Leopard) without any issues.  DUN only seems to fail on Fedora 13.

Comment 14 Derek Atkins 2010-06-29 19:21:11 UTC
Hmm.. The Mac I tried was running 10.5, not 10.6.  But I didn't see any DUN advertisements either way.

Comment 15 Wendell MacKenzie 2010-07-30 00:14:04 UTC
FWIW, I had the same issue on OpenSuse 11.3 with my treo 700p using DUN.  I was getting the DUN timeout during obtaining of the phone details as well.

I downgraded the ModemManager version to 0.4-1.0 and it now works.  Here is the debug output if that helps:

** (modem-manager:20077): DEBUG: <1280448219.105071> (rfcomm0) device open count is 1 (open)
** (modem-manager:20077): DEBUG: (rfcomm0): probe requested by plugin 'Generic'
** (modem-manager:20077): DEBUG: <1280448219.204411> (rfcomm0): --> 'AT+GCAP<CR>'
** (modem-manager:20077): DEBUG: <1280448220.400251> (rfcomm0): <-- 'A'
** (modem-manager:20077): DEBUG: <1280448220.402205> (rfcomm0): <-- 'T+GCAP<CR>'
** (modem-manager:20077): DEBUG: <1280448220.405209> (rfcomm0): <-- '<CR><LF>+GCAP: +CIS707-A, CIS-856, +MS, +ES, +DS, +FCLASS<CR><LF><CR><LF>OK<CR><LF>'
** (modem-manager:20077): DEBUG: <1280448220.405310> (rfcomm0) device open count is 0 (close)
** Message: (rfcomm0) closing serial device...
** Message: (rfcomm0) type primary claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2
** Message: (Generic): CDMA modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 claimed port rfcomm0
** (modem-manager:20077): DEBUG: Added modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2
** (modem-manager:20077): DEBUG: (tty/rfcomm0): outstanding support task prevents export of /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2
** (modem-manager:20077): DEBUG: Exported modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2 as /org/freedesktop/ModemManager/Modems/0
** (modem-manager:20077): DEBUG: (/org/freedesktop/ModemManager/Modems/0): data port is rfcomm0
** (modem-manager:20077): DEBUG: Removed modem /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2

Comment 16 wdc 2010-08-08 15:21:53 UTC
Wendell:

I was just on the Fedora 13 and SuSE Package sites, and could find no ModemManager 0.4-1.0

Where exactly did you find it?

Comment 17 Aron Griffis 2010-08-08 18:31:09 UTC
wdc, I don't know about OpenSUSE but you can find Fedora builds here:

http://koji.fedoraproject.org/koji/packageinfo?packageID=8770

I haven't tried an older build yet to see if it would fix the problem for me.

Comment 18 wdc 2010-08-08 18:39:46 UTC
Yes, koji is where I looked for an 0.4-1.0.  There isn't one there.
There is 0.3-13 and then 0.4-2.

All the Fedora builds are using interim git checkins rather than a particular stable upstream source.

When we know where Wendell got what is working, we can associate that with a particular upstream source and patch set.

Comment 19 Wendell MacKenzie 2010-08-08 22:18:23 UTC
Hi:

I grabbed the latest ModemManager source tar ball from gnome.org and using 
the specfile from the latest factory src rpm @ opensuse "massaged" it as a 4-1.0 release inside.

I followed the below procedure:

- downoaded ModemManager-4.0.tar.bz2 from gnome.org/pub/sources and 
  dropped it into:

  /usr/src/packages/SOURCES

- installed the latest source RPM I could find in the OpenSUSE factory to 
  get the relevant bits needed to build the package RPM

- edited the SPECfile pointing it to the 4.0 tar ball and manually set the
  release ident portion to 1.0.

- then compiled the rpm pkg:

# cd /usr/src/packages/SPECS
# rpmbuild -ba ModemManager.spec

hths,
Wendell

Comment 20 wdc 2010-08-09 02:25:17 UTC
Created attachment 437508 [details]
Output after trying the 0616 source snapshot from gnome.org

I tried to reproduce Wendell's setup.

I fetched the latest Fedora ModemManager source:
ModemManager-0_4-4_git20100720_fc13 

And the ModemManager upstream source from:
ftp://ftp.acc.umu.se/pub/GNOME/sources/ModemManager/0.4/ModemManager-0.4.tar.bz2  

I renamed the downloaded upstream source ModemManager-0.4.dl.tar.bz2  
As Wendell did, I modified the spec file, built, installed and restarted ModemManager.

I still get the same errors, as shown by the attached file containing output from .xsession-errors and /var/log/messages.

Can someone interpret the errors and suggest what might be going on?

Comment 21 wdc 2010-08-09 02:26:56 UTC
I will note in passing that I also tested on a similar laptop that is in Fedora testers.  It was running the 2.6.34 kernel and ModemManager-0_4-4_git20100720.

It failed in the same way.

Comment 22 wdc 2010-09-04 01:07:08 UTC
Actually, I think the Kernel problem is now fixed.
I just took the 2.6.34.6-47 kernel update and now the resubmission failure error messages no longer happen.

Sadly, the DUN STILL does not configure.

Here is the new output from /var/log/messages (with one line of extra output before and after the bluetooth stuff.):

Sep  3 16:53:04 wdc-laptop ntpd_intres[1477]: DNS 2.fedora.pool.ntp.org -> 169.229.70.183
Sep  3 16:53:35 wdc-laptop bluetoothd[1447]: Discovery session 0xb77cfd10 with :1.69 activated
Sep  3 16:53:43 wdc-laptop bluetoothd[1447]: Stopping discovery
Sep  3 16:53:45 wdc-laptop bluetoothd[1447]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Sep  3 16:53:45 wdc-laptop bluetoothd[1447]: pin_code_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Sep  3 16:54:03 wdc-laptop bluetoothd[1447]: link_key_notify (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B, type=0)
Sep  3 16:54:03 wdc-laptop bluetoothd[1447]: probe failed with driver input-headset for device /org/bluez/1443/hci0/dev_00_24_BA_E5_DF_2B
Sep  3 16:54:11 wdc-laptop bluetoothd[1447]: link_key_request (sba=00:16:CF:F0:AC:3A, dba=00:24:BA:E5:DF:2B)
Sep  3 16:54:12 wdc-laptop modem-manager: (rfcomm0) opening serial device...
Sep  3 16:54:23 wdc-laptop modem-manager: (rfcomm0) closing serial device...
Sep  3 16:54:23 wdc-laptop modem-manager: (rfcomm0) opening serial device...
Sep  3 16:54:30 wdc-laptop modem-manager: (rfcomm0) closing serial device...
Sep  3 16:54:54 wdc-laptop dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.11" (uid=0 pid=1443 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.69" (uid=500 pid=2255 comm="bluetooth-wizard))
Sep  3 16:56:22 wdc-laptop ntpd[1454]: 0.0.0.0 c615 05 clock_sync

Here is the relevant content from .xsession_errors:

** Message: has_config_widget 00:24:BA:E5:DF:2B DialupNetworking
** Message: has_config_widget 00:24:BA:E5:DF:2B OBEXObjectPush
** Message: has_config_widget 00:24:BA:E5:DF:2B AudioSource
** Message: has_config_widget 00:24:BA:E5:DF:2B A/V_RemoteControlTarget
** Message: has_config_widget 00:24:BA:E5:DF:2B Headset_-_AG
** Message: has_config_widget 00:24:BA:E5:DF:2B HandsfreeAudioGateway
** Message: has_config_widget 00:24:BA:E5:DF:2B Phonebook_Access_-_PSE
** Message: has_config_widget 00:24:BA:E5:DF:2B DialupNetworking
** Message: has_config_widget 00:24:BA:E5:DF:2B OBEXObjectPush
** Message: has_config_widget 00:24:BA:E5:DF:2B AudioSource
** Message: has_config_widget 00:24:BA:E5:DF:2B A/V_RemoteControlTarget
** Message: has_config_widget 00:24:BA:E5:DF:2B Headset_-_AG
** Message: has_config_widget 00:24:BA:E5:DF:2B HandsfreeAudioGateway
** Message: has_config_widget 00:24:BA:E5:DF:2B Phonebook_Access_-_PSE
** Message: Default Bluetooth adapter is powered
** Message: dun_start: starting DUN device discovery...
** Message: dun_start: calling Connect...
** Message: dun_start: finished
** Message: dun_connect_cb: processing Connect reply
** Message: dun_connect_cb: new rfcomm interface '/dev/rfcomm0'
** Message: dun_connect_cb: finished
** (deja-dup-monitor:1919): DEBUG: monitor.vala:263: Invalid next run date.  Not scheduling a backup.

** (bluetooth-wizard:2255): WARNING **: dun_timeout_cb: Error: timed out detecting phone details.

----

I think the key to forward progress is in the log message:

Sep  3 16:54:54 wdc-laptop dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.11" (uid=0 pid=1443 comm="/usr/sbin/bluetoothd) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.69" (uid=500 pid=2255 comm="bluetooth-wizard))
Sep  3 16:56:22 wdc-laptop ntpd[1454]: 0.0.0.0 c615 05 clock_sync

My phone said:
  PdaNet is Connected!
  Bytes: 0/0 
  Activities: 0/0
  Battery: 85%

Just like always.
I presume a successful DUN negotiation would involve more than 0 bytes and 0 activities.

Comment 23 Bug Zapper 2011-06-02 12:07:36 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 24 Bug Zapper 2011-06-27 17:29:01 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.