From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Description of problem: I have a Palm m130 that was synching fine (using Evolution or pilot-link tools) on a Fedora Core 4 32-bit system. My system is now upgraded to Fedora 8 on a 64-bit system. Instead of using visor, I'm trying to connect using libusb (i.e. the new correct way). The problem is that the system doesn't see the device. Tried running: sudo pilot-xfer -p usb: -l Running pilot-xfer as root to avoid any additional permission problems. All pilot-xfer does is display it's 'Listening for incoming connection on usb:...' message and sit there. This is clearly a communication problem given what I tried and what I know works (see Additional info). Version-Release number of selected component (if applicable): pilot-link-0.12.3 How reproducible: Always Steps to Reproduce: 1. Put Palm m130 into cradle 2. Run 'sudo pilot-xfer -p usb: -l' 3. Press cradle hotsync button 4. Become frustrated as pilot-xfer never connects Switching steps 2 and 3 (press hotsync FIRST, then run command) produces the same results. Actual Results: pilot-xfer prints it's listening message and just sits there. Eventually, the Palm m130 hotsync times out. Expected Results: Given the 'pilot-xfer -p usb: -l' command, I expected to see a list of database files on the Palm m130. Additional info: Always run pilot-xfer as root to avoid permission problems. I've followed all the directions I could find (doc/README.libusb and various mailing lists posts). Visor is blacklisted, running lsusb shows the Palm device, entries are being made in /dev/bus/usb. Verified that the pilot rules (doc/60-libpisock.rules) are being used after copying it to /etc/udev/rules.d, changing the GROUP from 'dialout' to 'uucp', and reloading the rules (udevcontrol --reload_rules). No errors from udev about reading the rules file. I've tried compiling pilot-link myself when the yum installed version didn't work (verifying that libusb was enabled). Tried the version in CVS (as of June 2, 2008). Tried the Koji version (http://koji.fedoraproject.org/koji/taskinfo?taskID=632388). Tried the patch for z22 (http://mail.gnome.org/archives/gnome-pilot-list/2007-October/msg00011.html). Tried the other patch for z22 (http://lists.pilot-link.org/pipermail/pilot-link-general/2007-November/003271.html) except that I tried the flag for the m130 entry. Tried the USB_INIT_NONE flag. My initial post on the pilot-link mailing list can be found at http://lists.pilot-link.org/pipermail/pilot-link-general/2008-May/003351.html and the discussion continues in June at http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html.
Created attachment 308354 [details] Debug information from pilot-xfer This debug log was created using the following settings: setenv PILOT_DEBUG "DEV SLP CMP NET SOCK USER" setenv PILOT_DEBUG_LEVEL "DEBUG" setenv PILOT_LOGFILE "pilot-link-debug.log" setenv PILOT_LOG 1
Just to note that I've tried to step through this issue with Adam on the pilot-link-general mailing list (see the links he provides), and as far as I can tell this is NOT a problem with permissions - he's tried testing as root, and using the F8 test RPM for PolicyKit from bug #280251. Instead, it would appear to be a genuine incompatibility problem between the pilot-link libusb code and m130 handhelds. The upstream developer hopes to buy some m130 hardware to work on this issue.
Because of the previous comment I think the current upstream cvs version is not fixed, but could you please test that version - I did not found any notice about the result of this test on http://lists.pilot-link.org discussions. Thanks.
I believe we are waiting for a pilot-link developer to buy, or be donated, M130 hardware to test with. It's not for sale in retail any more, so this could take a while. Discussion on the pilot-link list stalled at that point. This incompatibility keeps cropping up in forums, so I think this bug should be left open, although the solution is likely to come from upstream.
I think it would be nice if the bug reporter try to test the cvs version - there is no notice about any test and there is a chance the upstream cvs fix it. But if there is no change then I agree with you, the best solution is to wait.
Ivana: the thread continues in the June archive of the mailing list; the reporter has tested the CVS version: http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html Adam: and you had no luck with the F9 liveCD either? (Just to confirm the bug is common to F8 and F9)
Ops. I don't understand this comment properly - when I read it, you are right, thanks.
As stated, I did try the CVS version (as of June 2) with no luck. I never bothered with the Fedora 9 liveCD since I think Kevin mentioned that it probably wouldn't work. On a side note, I did get syncing working with the old Visor module for the time being. I'm in the middle of recovering from a hard disk failure (found out the day before the drive crashed that my system wasn't being backed up anymore because of an IP # change -- fine time to tell me!) If people think that I should try the Fedora 9 liveCD, I can. It might take a while as I try to get back to where I was and catch up on all my missed work :-{(
I haven't tried the live CD, but I am running a regular F9 installation and libusb does not work with my m130 - behaviour is the same as the original bug report.
Adam, Brian thanks a lot for your help - in fc there is no patch which could fix it. I agree with Kevin - the best solution for now it to wait for upstream.
On a fully-patched FC8, I symlinked /etc/udev/rules.d/60-libpisock.rules and 60-pilot.rules to the respective .rules.fedora files in /usr/share/pilot-link/udev/. /dev/ttyUSB? and /dev/pilot files were created (/dev/pilot as a symlink to /dev/ttyUSB1), but pilot-link couldn't connect to /dev/pilot and my M130 eventually timed out. However, if I told pilot-link to connect to /dev/ttyUSB0, i.e. pilot-xfer -p /dev/ttyUSB0 -l then all was well. I propose therefore, that 60-pilot.rules ought to link to contain: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*",KERNEL=="ttyUSB[02468]", SYMLINK="pilot", GROUP="uucp", MODE="0660" pilot-link is 0.12.2-21.fc8, kernel is 2.6.25.11-60.fc8, udev is 118-1.fc8, hal is 0.5.10-3.fc8
Alex: libusb - which doesn't require use of the udev rules - is now the default for pilot-link in Fedora, but as this bug shows there are still a few devices not yet compatible with the libusb implementation. Until these handhelds work with libusb users will need to configure udev. We recently tried to tidy up the instructions for using the fall-back udev configuration, and this is documented in README.fedora - suggestions for improving README.fedora are welcome. Until recently Fedora also carried a customised variant of 60-libpisock.rules, which was both broken for some devices and caused confusion when users went to the pilot-link mailing lists for help. A key issue is that it's impossible to write a udev rule symlinking /dev/pilot that works for *all* handhelds on *all* machines (see bug #281641). What works for you will definitely fail for someone, somewhere. As you've discovered, some Palm handhelds use ttyUSB(x), while others use ttyUSB(x+1)... and this is further confused if you have another USB serial device which might create a ttyUSB device (making your odd port even, and so on). So we now ship the unmodified upstream version of 60-libpisock.rules with instructions on how to modify it for your setup in README.fedora. (In reply to comment #11) > On a fully-patched FC8, I symlinked /etc/udev/rules.d/60-libpisock.rules and > 60-pilot.rules to the respective .rules.fedora files in > /usr/share/pilot-link/udev/. /dev/ttyUSB? and /dev/pilot files were created Hmmm, was this the 60-libpisock.rules provided in the current F8 RPM? It shouldn't create a /dev/pilot symlink unless you modified it by hand. I've just checked a fresh copy of pilot-link-0.12.2-21.fc8 - are you sure you don't have an .rpmnew around? > BUS=="usb", SYSFS{product}=="Palm > Handheld*|Handspring*",KERNEL=="ttyUSB[02468]", SYMLINK="pilot", GROUP="uucp", > MODE="0660" The SYSFS matching also causes a load of hassles because it relies on a non-guaranteed string from the hwdata package (in turn from another upstream). This string changed at least once over the life of F8 - it's not a robust mechanism for matching. Sorry to sound so negative, but the impossibility of fixing the udev rules was one of the motivations for using libusb. If you follow the links in earlier comments you'll see the upstream pilot-link developer was trying to get m130s working with libusb, but was struggling to get hold of any hardware.
Hello, for now I think there is no solution how fix this problem for fc8 - but this is fixed in fc9 - so I'm closing this bug as nextrelease.
Ivana: which patch fixed it for F9? As far as I'm aware there hasn't been a fix applied upstream. We haven't done anything at the Fedora end to fix it, have we? - it's a compatibility problem specifically with the m130, not just the PolicyKit/hal/libusb stuff. Brian/Adam: could you confirm this is fixed in F9, please? Re-open this bug if not and reset version to F9. If there has been a Fedora patch to fix this it should certainly be pushed back upstream.
(Ivana: comment #11 is a bit of a red herring. If it were a valid bug - which it's not - it should be filed separately to this one. I suspect this bug is a USB "timing" bug similar to the recent Clie ones; unfortunately applying the Clie timings is reported not to work)
Kevin, No, not fixed in F9. I'm still using pilot-link to sync my m130.
Ivana / Adam: please re-open and set version to F9.
Hello, sorry for closing this (thanks Kevin for reopening it ).
Still not working in F10.
Works almost out of the box with F10+all updates for me. Cradle configured as USB, timeout=2, device=/dev/ttyUSB0, Speed=57600. The only tweak I needed to do was 'modprobe visor' in /etc/rc.d/rc.local
Alex, This bug is about libusb. Your use of 'modprobe visor' and device=/dev/ttyUSB0 indicate you are using the visor module, which means that you are not using libusb.
(In reply to comment #19) > Still not working in F10. Updated version accordingly. Sorry I can't help with direct debugging, not having that Palm model myself.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.
This is still a problem with F11. I haven't tested it yet with F12 as I'm not yet running F12.
I'm now running F12. This is still does not work with F12. Can someone reopen this bug? I don't have permission to change the status.
Since I was the original creator, I guess I can reopen it as long as somebody tells me exactly what I need to do. For status, my only two choices are CLOSED or ASSIGNED. If I set it to ASSIGNED, what should I set the other field to (currently set to WONTFIX)? Never reopened a bug before, so I want to make sure I do it the proper way.
(In reply to comment #27) > Since I was the original creator, I guess I can reopen it as long as somebody > tells me exactly what I need to do. For status, my only two choices are CLOSED > or ASSIGNED. If I set it to ASSIGNED, what should I set the other field to > (currently set to WONTFIX)? ASSIGNED will fix it, but the other field will disappear (only set when CLOSED). > Never reopened a bug before, so I want to make sure I do it the proper way. You can reopen but since pilot-link is more or less dead upstream: http://www.pilot-link.org/pilot-link-0-12-4-pew-and-pas-release this is unlikely to ever be fixed. (But patches welcome).
Changed version to 12 since Brian Mury states it still doesn't work. Maybe somebody will submit a patch someday even if pilot-link is done. Especially since this is a bug with libusb, not necessary with pilot-link itself.
Thanks, fixed in pilot-link-0.12.5-4.fc15.
Ehm, sorry it was typo(wrong bug number).
Hello, please can you reproduce this bug with the latest versions of packages on rawhide?
Ivana, I sent you an email but I haven't receive a reply, so I'll state my message here: I see that you would like me to test with rawhide. I'm currently running Fedora 13. Is that good enough for testing or is rawhide radically different? If I need to use rawhide, how do I go about getting packages and will they work on Fedora 13? Also, which packages should I be updating? I'm afraid I'll need more precise instructions as to what you would like me to do to upgrade the packages.
(In reply to comment #33) > Ivana, I sent you an email but I haven't receive a reply, so I'll state my > message here: > > I see that you would like me to test with rawhide. I'm currently > running Fedora 13. Is that good enough for testing or is rawhide > radically different? If I need to use rawhide, how do I go about > getting packages and will they work on Fedora 13? > > Also, which packages should I be updating? > > I'm afraid I'll need more precise instructions as to what you would like > me to do to upgrade the packages. I think she probably was wondering if you could rebuild the rawhide package locally on your Fedora 13 machine and then install them. In any case, I went ahead and did some scratch builds for you, you can download the packages from koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2748486 click on the architecture you have and the rpms should be at the bottom of the list.
Here's what I've done so far in trying to get the pilot-link to work (which hasn't). Maybe one of the problems I'm having is preventing it from working: 1) Installed new version of pilot-link sudo rpm -U pilot-link-0.12.5-1.fc13.x86_64.rpm Previously, I had pilot-link-0.12.4-7.fc13.x86_64. Since I only had the pilot-link package installed, that's the only one I updated. 2) Tried to remove visor (didn't know if it needed to be removed). Could not remove the visor module from the kernel. Ran: sudo modprobe -r visor No errors, but 'modprobe -l' still listed it. Added: blacklist visor to '/etc/modprobe.d/blacklist.conf' and rebooted. 'modprobe -l' still listed visor. 3) Removed udev rules I put into place. I had the following rules to create '/dev/pilot': BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *", KERNEL=="ttyUSB[02468]", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="uucp", MODE="0666" I commented that rule out and changed the original Pilot rule in '/usr/share/pilot-link/udev/60-libpisock.rules' so that the group is uucp: ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0050", GROUP="uucp", MODE="0664" lsusb still shows the Pilot when I hit the hot sync button (so I know it's ID vendor 0830 and product 50). After changing the rules, I ran '/etc/init.d/udev-post reload'. This results in the message: Retrigger failed udev events [ OK ] So I assume things loaded ok. Running 'pilot-xfer -p usb: -l' resulted in the same problem as before, no connection. I ran as myself and as root. I can post another pilot-link debug like I did originally, but I thought I would run this by people first to make sure I did everything I was suppose to do or if there was some obvious error (like visor needs to be removed for USB to work).
This may just be broken upstream (i.e. in pilot-link itself), and since upstream is more or less dormant and no new PalmOS 5.x devices are in production any longer, I suspect that this bug may never be fixed, except by somebody willing to debug it right down to the device level. (which is well beyond me as packager).
As long as visor continues to work, I can use that. This is not critical.
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
Not working in F15.
(In reply to comment #39) > Not working in F15. Bumping to F15. However, I suspect that this bug may never be fixed, just to reiterate my comment #36. Of course, any patches would be welcome.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Hi guys, what's the current status of this bug now? As Alex said, I am afraid this never be fixed. So, without any new progress, I would close this bug as CANTFIX if you agree. peter
Yes, I would say close as CANTFIX is there never will be one. No point leaving it open. If you can leave a reason for CANTFIX, make sure it's added so that anybody else seeing this issue will understand why it's not being fixed.
Thanks Adam. I am closing this issue as CANTFIX, as we were unable the determine the root of this problem, upstream is gone and this kind of HW is getting old.. peter