Description of problem: Hotsync of Palm PDAs used to work reliably for me up to and including FC5, but did not in default FC6 installations and now not in default F7 installations either. The normal means of syncing Palm devices is to use either a serial or USB connection symlinked to /dev/pilot, in the case of USB-capable Palms the target of this symlink is usually /dev/ttyUSB0 or /dev/ttyUSB1 and the symlink should be created by udev. Currently this cannot happen for at least two reasons, 60-libpisock.rules in the pilot-link rpm is placed in /usr/share/pilot-link/udev whereas it needs to be in /etc/udev/rules.d for udev to find it. There also needs to be a pilot.rules file in the same place with the following string on a single line: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666" This information came direct from the pilot-link developer. However, one problem with these rules is that for 60-libpisock.rules the udev group entry for the Palm and Handspring PDAs is shown as "dialout", and in the pilot.rules string above it is "usb", neither of these groups exist in a default install in /etc/group which appears to prevent the creation of /dev/pilot even if /dev/ttyUSB* exist. I have also needed to add a new file containing: <ttyUSB>=/dev/ttyUSB* <console> 0660 <ttyUSB> 0660 root.uucp into /etc/security/console.perms.d because without the default rules give /dev/ttyUSB* ownership root:disk and hese cannot be used by a normal user, adding an entry for these nodes to console.perms then makes /dev/ttyUSB* appear to have ownership <current user>:disk with 660 permissions allowing access to them. At least with a Palm TX these changes are needed, otherwise it simply won't work out of the box and the new complexity of hal, udevd, dbus etc to convey signals back and forth means it has taken a long time to work out what is broken and how to fix it. Note that my changes may be slightly incorrect, but seem to work for me. Version-Release number of selected component (if applicable): pilot-link-0.12.2-4.fc7.x86_64 pilot-link-0.12.2-4.fc7.i386 pilot-link-devel-0.12.2-4.fc7.x86_64 pam-0.99.7.1-5.1.fc7.x86_64 pam-0.99.7.1-5.1.fc7.i386 How reproducible: Appears to be completely reproducible (i.e. can never sync a modern USB Palm) without re-configuration Steps to Reproduce: 1. Connect Palm (cradle optional) to USB port 2. Press sync button 3. Start sync in JPilot Actual results: Watch eveything sit there until the connection times out Expected results: Palm syncs (although the timing for the hotsync button press and JPilot button click is still difficult to get right every time). Additional info:
Further problems appeared relating to the pilot.rules file I added to /etc/udev/rules.d which were solved by removing NAME="ttyUSB%n", from the rule entry. Without this omission the rule fails and no /dev/pilot symlink is ever created. I have also replaced GROUP="usb" with GROUP="uucp" since the uucp group exists in /etc/group whereas usb does not.
*** This bug has been marked as a duplicate of 158809 ***
This is _NOT_ a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=158809. cf. https://bugzilla.redhat.com/show_bug.cgi?id=158809#c52
(In reply to comment #3) > This is _NOT_ a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=158809. > cf. https://bugzilla.redhat.com/show_bug.cgi?id=158809#c52 Yes, I agree, they are related but not the same. This bug is about the configuration that is needed even if udev is fast enough. Although I'm not the pilot-link maintainer. If the currrent maintainer doesn't re-open it, or otherwise say why it should be marked as a dupe, I'll re-open it in a few days.
Thanks for your comments, perhaps I will look to this bug more closer - asap, for now I will reopen it.
Status update?
This bug is still present in Fedora 8 (could owner or reporter change the tag, please). Alex: I note that in a post to gnome-pilot-list you say that the Fedora pilot-link package "does currently install [the rules], but puts them in the wrong place". I moved 60-libpisock.rules to /etc/udev/rules.d/, but the "usb" group doesn't exist. Should I change this to "uucp" as suggested above? Is there anything else you'd expect me to need to do to get a Treo 680 working with Fedora 8? Do I need the .perms file too as suggested above? I don't have a working setup at the moment, but any search reveals so many potential issues it's difficult to know where to start.
(In reply to comment #7) > This bug is still present in Fedora 8 (could owner or reporter change the tag, > please). > Alex: I note that in a post to gnome-pilot-list you say that the Fedora > pilot-link package "does currently install [the rules], but puts them in the > wrong place". There appear to be two different kind of rules you need. The one currently in /usr/share/pilot-link/udev/ are, I think, are related to libusb synching. > I moved 60-libpisock.rules to /etc/udev/rules.d/, but the "usb" group doesn't > exist. Should I change this to "uucp" as suggested above? > Is there anything else you'd expect me to need to do to get a Treo 680 working > with Fedora 8? Do I need the .perms file too as suggested above? I still use the visor method of synching (and the pilot-link package is currently setup to default to the visor module) and to get this working necessitates having a file as described in comment #0 which currently doesn't exist at all. > I don't have a working setup at the moment, but any search reveals so many > potential issues it's difficult to know where to start. My file looks like this: BUS=="usb", SYSFS{product}=="Palm Handheld*", KERNEL=="ttyUSB*",NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666" and I put it in: /etc/udev/rules.d/03-local.rules and I have another file with ttyUSB1:$local:uucp:0660 in /etc/udev/permissions.d/10-visor.permissions This is enough for basic sync to work for me. I plan to update the package soon after the current holiday break (in the US), so these rules get installed by default, but I need to do some more research (and consult with upstream) to ensure that I know what each of these files does and exactly what to set as the permissions groups etc.. Otherwise I could risk making a bad situation worse.
Most of this is described in: http://www.pilot-link.org/README.usb particularly point 2) under "Configuring udev to create inodes dynamically for you"
Background: I had Palm sync working (with the visor module) on a desktop running FC5. When I rebuilt this machine with F7 I didn't manage to get a working sync config. I now have a laptop with a fresh F8 install I'm trying to configure correctly. > There appear to be two different kind of rules you need. The one currently in > /usr/share/pilot-link/udev/ are, I think, are related to libusb synching. Yes, that's correct. Given the comments from the udev maintainer (bug #281641, comment #18) regarding the udev rules for visor, I thought I'd try libusb. > My file looks like this: > BUS=="usb", SYSFS{product}=="Palm Handheld*", KERNEL=="ttyUSB*",NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666" > and I put it in: /etc/udev/rules.d/03-local.rules This matches what's recommended upstream - however note that the "usb" group doesn't exist on Fedora. If you set: udevcontrol log_priority=debug then reload the rules with: udevcontrol reload_rules you'll see that the GROUP="usb" failes. > and I have another file with > ttyUSB1:$local:uucp:0660 > > in /etc/udev/permissions.d/10-visor.permissions F8 doesn't have a /etc/udev/permissions.d/ - is this method deprecated? Is /etc/security/console.perms.d/ the right place to do it now? (comment #0) > ensure that I know what each of these files does and exactly what to set as the > permissions groups etc.. Otherwise I could risk making a bad situation worse. Well, yes, exactly - I have a cleanly installed machine and I'm very aware that tinkering with configuration files here and there could break fixed Fedora packages should they ever be released (though let's face it, this has been broken for years now). There are so many bug entries and mailing list threads each with slightly different advice. It has to be said, after a reboot - and I've no idea why this was needed, I'd reloaded udev rules - I'm having a _little_ more success with the visor module. With the above udev rule /dev/pilot is created - but pilot-xfer just sits there waiting (also tested as root to sidestep perm issues).
Ok after some more searching and testing, here is my current understanding; I don't think there's anything that's not been said here or in other bugs, but I've tried to pull it all together. VISOR MODULE The visor module presents a serial interface to the older utilities that expect one (e.g. older versions of pilot-link). To make this work on a Fedora 8 machine you must create a file such as /etc/udev/rules.d/60-pilot.rules containing: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="uucp", MODE="0666" This is as recommended by upstream, save a change of GROUP from "usb" to "uucp". According to comment #0, you also need a file in /etc/security/console.perms.d/ to set permissions on /dev/ttyUSB? allowing access to the console user. Neither of these files are included in the Fedora pilot-link package. My experience: although visor loads and /dev/pilot is create, this doesn't work with pilot-xfer for me on a fresh F8 box (see comment #10). I suspect it may be the timing voodoo required - finding the right amount of time to pause between pressing the hotsync button and running pilot-xfer (!). I fear this sort of problem is inherent in using a solution like the visor module. So, on to... LIBUSB libusb provides an alternative interface for pilot-link to access your handheld. If you are using libusb you don't need to configure as for visor, above. First, create a file called /etc/modprobe.d/blacklist-visor containing: blacklist visor Then move the 60-libpisock.rules file provided in the Fedora pilot-link package from /usr/share/pilot-link/udev/ to /etc/udev/rules.d/ and amend the "dialout" group entries to "uucp". Ignoring permission issues, this is now working for me. I don't know whether a reboot or two helped, or it may be that you seem to need to execute pilot-link before pressing the hotsync button - i.e. the opposite behaviour to using the visor module. There is discussion in bug #158809 about what the right way to set permissions for console users on the subset of /dev/bus/usb devices pilot-link uses, but this is also languishing unresolved. Overall a pretty diabolical out of box experience for Palm users with Fedora - especially since, many moons ago, this used to work.
Kevin: thanks for the exhaustive analysis! Yeoman's work to be sure! And very helpful, on the basis of this, I have reworked the spec file in F-8 to add the relevant udev configuration files, so that (at least) the visor module should work out of the box. That way, we at least get back to where we were around FC-6 or so. I have a koji build for F-8, that you can download and test at: http://koji.fedoraproject.org/koji/taskinfo?taskID=260910 The config files look like this: /etc/udev/rules.d/60-pilot.rules: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*", KERNEL=="ttyUSB*",NAME ="ttyUSB%n", SYMLINK="pilot", GROUP="uucp", MODE="0666" /etc/security/console.perms.d/60-pilot.perms: <ttyUSB>=/dev/ttyUSB* <console> 0660 <ttyUSB> 0660 root.uucp I have tested this on my clean F-8 box which previously had no legacy pilot-link configs and this seems to work: # pilot-xfer -l -p /dev/pilot modulo the timing issues you mention (which I also have). What I do is press the hotsync button on the Palm (a Treo 680 in this case) and have a tail -f /var/log/messages and about 1/2-1 second (will probably vary depending on the speed of the machine, udev etc.) after I see the "usb 1-2: Handspring Visor / Palm OS converter now attached to ttyUSB0" message, I start the above command, and I get a list of files. I realise that this doesn't address the timing issue, but it is at least usable and gets us back to having usable configs for the visor synching method. Once we have this working, we can revisit enabling libusb support and/or dropping visor maybe for the F-9 release. I'll check with Ivana on this. Also note there is a 0.12.3 version of pilot-link which is in the pipe for F-9, but I haven't ported these changes there yet. In any case, please test and let me know if there are any show stoppers and if not, I can check it in and push out a new package to updates-testing for F-7 and F-8.
Thanks for your great work Kevin and Alex, now I have enough time to look to pilot-link package so I will try to put pilot-link to more usable state. Alex I will look to your build.
(In reply to comment #13) > Thanks for your great work Kevin and Alex, now I have enough time to look to > pilot-link package so I will try to put pilot-link to more usable state. > Alex I will look to your build. Ivana: I have diffs against the current F-8 CVS branch of pilot-link ready to check in, so let me know if it works and I can check them in and then we can work from there. Also I am currently on #fedora-devel right now so we could talk about it if you are online.
The koji build works for me - many thanks! I'll try to dig out and test with a Tungsten T later in the week too, since I think it uses the "other" ttyUSB (which takes us back to the udev/pilot-link problems in bug #158809, which doesn't seem to be resolvable without moving to libusb). As I mentioned in bug #158809, comment #61, if you want libusb testing - and I'd suggest you do, since it's clearly the long-term solution to fixing these issues - I think you need to ship a correct and working configuration for libusb, not enabled by default, but in /usr/share/pilot-link with a README. The proposed patches in bug #158809 seem sensible to me... Are we confident the console.perms.d mechanism is the Right Way? Ivana, would it be possible to get a udev maintainer to check over these configs and the ones for libusb in bug #158809? Will console perms change with the introduction of PolicyKit? (I have no idea, but I would hate to see this working only for the ground to change under our feet again).
(In reply to comment #15) > As I mentioned in bug #158809, comment #61, if you want libusb testing - and I'd > suggest you do, since it's clearly the long-term solution to fixing these issues > - I think you need to ship a correct and working configuration for libusb, not > enabled by default, but in /usr/share/pilot-link with a README. The proposed > patches in bug #158809 seem sensible to me... Probably a good idea. Something like http://www.pilot-link.org/README.libusb but removing all but the Fedora-specific information and adding anything else necessary in README.fedora. We could certainly enable libusb by default for pilot-link in rawhide because breakage there isn't such a big deal, although we need to encourage people to actually test it before the release of F-9, which is tricky because there may not be that many Palm users who also use rawhide (I don't ;-)) > Are we confident the console.perms.d mechanism is the Right Way? Ivana, would it > be possible to get a udev maintainer to check over these configs and the ones > for libusb in bug #158809? Will console perms change with the introduction of > PolicyKit? (I have no idea, but I would hate to see this working only for the > ground to change under our feet again). We talked on IRC, and I believe Ivana is currently consulting with the udev maintainers, once we get an answer, we'll probably commit and issue an update to updates-testing for wider testing.
Here is a solution for Fedora 8 http://www.harald-hoyer.de/linux/console_acls_for_palm
Test version of pilot-link package - pilot-link-0.12.2-9.fc8 which contains Harald Hoyer solution (thanks for your great help) is build now.
pilot-link-0.12.2-9.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pilot-link'
Can we get a test version for F7? Thanks...
(In reply to comment #20) > Can we get a test version for F7? Thanks... Unfortunately the F-8 pilot-link package relies on the PolicyKit package, which doesn't exist in F-7, so this particular solution won't work on F-7. My suggestion for a fallback is to use my (admittedly hacky) udev solution. It works for the moment, and we won't have to maintain it after F-7 goes EOL. With respect to the F-8 solution, I'm proposing also installing scriptlets that run the commands in %post /sbin/service haldaemon condrestart /sbin/rmmod visor I'll attach a patch to the F-8 spec file shortly.
The package in updates-testing works for me - thanks! I tried the %post scriplet commands from comment #21 - these also worked and are required to avoid a reboot - it seems sensible to add these before pushing beyond the testing repo. Enabling libusb goes against the upstream maintainers advice - and while I think it's the right way to go because the visor alternative is horrible, it won't be a complete surprise if some handhelds fail (and of course it's better than the default F7/F8 install where nothing would work!). So it would seem sensible to include a README.Fedora and the alternative visor configs in /usr/share/pilot-link. Given this is a major change, is there any reason not to rebase to pilot-link 0.12.3 at the same time? Has anyone contacted the packagers of e.g. gnome-pilot to warn of the jump to libusb?
Tested in a limited way using: pilot-xfer -p usb: -l and confirmed working with a Treo 680, Treo 650, and Tungsten T. Unfortunately, it breaks my soundcard (bug #411321).
(In reply to comment #23) > Tested in a limited way using: pilot-xfer -p usb: -l > and confirmed working with a Treo 680, Treo 650, and Tungsten T. It works for me fine too on Treo 680. Good to know it also works for the 650 and Tungsten T. > Unfortunately, it breaks my soundcard (bug #411321). I was wondering what happened to my soundcard! I started thinking that something was odd with pulseaudio, now I know that the pilot-link update was the culprit... Looks like the updates-testing has been obsoleted: https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4050 so at least it won't affect users en-masse yet. Hopefully the fix is an easy one (probably needs to fix some HAL perms) and we can re-push this.
(In reply to comment #22) > The package in updates-testing works for me - thanks! > I tried the %post scriplet commands from comment #21 - these also worked and are > required to avoid a reboot - it seems sensible to add these before pushing > beyond the testing repo. Exactly, I will look into doing that. And then once the HAL bug is resolved and we can push back to updates-testing again. > Enabling libusb goes against the upstream maintainers advice - and while I think > it's the right way to go because the visor alternative is horrible, it won't be > a complete surprise if some handhelds fail (and of course it's better than the > default F7/F8 install where nothing would work!). So it would seem sensible to > include a README.Fedora and the alternative visor configs in /usr/share/pilot-link. Actually I talked to David Desrosiers on #pilot-link about this and he seemed to think that it was OK to start to test libusb in distributions. (I'll try to dig up the log of the conversation to see exactly what his advice was). More posts from people's success or otherwise on a wider range of devices will help to decide if visor support can be dropped without major repercussions But, yes, there should be clear instructions for how to drop back to visor, if the device support isn't there using libusb. Ideally there would be some way to restore using a script. Kevin: if you want to start drafting some text for README.fedora, describing how to enable/disable visor support, I can also work on it and add it to the spec file. > Given this is a major change, is there any reason not to rebase to pilot-link > 0.12.3 at the same time? The major reason is that involves an soname bump for libpisock, and hence a recompile for all other dependent apps (gnome-pilot, jpilot etc.) > Has anyone contacted the packagers of e.g. gnome-pilot to warn of the jump to > libusb? That should be done, although, in theory it shouldn't matter to them, other than users of those apps might need to start the hotsync in the app first, rather than on the Palm (which is a reverse to the way the visor module method works). Let me look into it.
(In reply to comment #24) > (In reply to comment #23) > > Unfortunately, it breaks my soundcard (bug #411321). > > I was wondering what happened to my soundcard! I started thinking that > something was odd with pulseaudio, now I know that the pilot-link update was the > culprit... Looks like the updates-testing has been obsoleted: A workaround that works for me to get sound back, was simply to restart the HAL daemon, this got back pulseaudio for me: sudo /etc/init.d/haldaemon restart this needs to be done on each reboot, and perhaps when logging in and out of a session (or switching users).
(In reply to comment #25) > That should be done, although, in theory it shouldn't matter to them, other than > users of those apps might need to start the hotsync in the app first, rather > than on the Palm (which is a reverse to the way the visor module method works). With the new permission config I find this no longer matters - hotsync can be pressed before or after pilot-xfer is executed (because, I guess, previously the permissions weren't set until hotsync was pressed, whereas now they're assigned as soon as the usb device is created). I'll draft a README.fedora in the next few days.
Fixed in pilot-link-0.12.2-10.
pilot-link-0.12.2-10.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pilot-link'
Created attachment 284421 [details] README.Fedora for pilot-link package I think the file /usr/share/pilot-link/udev/60-libpisock.rules is deprecated by the PolicyKit solution and should be removed. For README.Fedora to make sense, Alex's 60-pilot.rules and 60-pilot.perms need to be included in /usr/share/pilot-link/udev/ If it's more appropriate for them to be in /usr/share/doc/pilot-link-X.XX/ then the README.Fedora needs amending.
F7 and F8 still aren't working. Has anything been checked into the regular update repositories?
(In reply to comment #31) > F7 and F8 still aren't working. Has anything been checked into the regular > update repositories? (please read earlier comments in this bug) F8: No, the package is only in updates-testing - please test if you can (instructions in comment #29). The updates-testing package "only" adds a better configuration for detecting and initialising the USB connection - pilot-link itself hasn't changed. F7: No, and because PolicyKit doesn't exist in F7 the automatic solution described here (comment #17) will not be packaged for F7 (see comment #21). However, the earlier udev configuration will work as well as it ever has (see README.Fedora in comment #30 and comment #12 for the config files) - hopefully this README.Fedora and fallback configs will make it into future packages. You can try following the README.Fedora and adding the configurations by hand - please report success/failure and if you have any improvements here.
(In reply to comment #30) > Created an attachment (id=284421) [edit] > README.Fedora for pilot-link package Thanks for that, looks great. I'm wondering now whether we could ship a libusb enabled package for F-7 but use /etc/security/console.perms.d/60-pilot.perms rather than PolicyKit for the permissions stuff, but use HAL for rest, would that work?
(In reply to comment #33) > I'm wondering now whether we could ship a libusb > enabled package for F-7 but use /etc/security/console.perms.d/60-pilot.perms > rather than PolicyKit for the permissions stuff, but use HAL for rest, would > that work? I'm not sure how you'd get 60-pilot.perms to differentiate between the USB devices libusb uses (/dev/usbdev*, presumably). The /dev/ttyUSBn devices are created by the visor module (libusb doesn't use them), so without them you'd have to give permissions on _all_ USB devices, which seems, uh, bad (obviously 60-pilot.perms does this to a much more limited degree if you have other non-Palm /dev/ttyUSBn. Which is bad too, but at least constrained). Given that the F8/PolicyKit solution is so nice and clean, I see little justification for developing what will inevitably be complex udev permissions rules for F7. Any change of getting the fallback configs and README.Fedora in the F8 package before it leaves updates-testing?
(In reply to comment #34) > Any change of getting the fallback configs and README.Fedora in the F8 package > before it leaves updates-testing? Build with configs and README.fedora are in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=30029 there is an additional build underway that additionally incorporates haldaemon restart and removing the visor module at: http://koji.fedoraproject.org/koji/buildinfo?buildID=30034 Please test the first build and then the second build, then I can hopefully prepare an update for updates-testing that will supercede the current package in updates-testing.
Alex, README.fedora references files in /usr/share/doc/pilot-link/ - these need to be changed to /usr/share/pilot-link/ (no doc/). Is there any reason why KERNEL=="ttyUSB*",NAME="ttyUSB%n" as tested in comments from this bug has been changed to KERNEL=="ttyUSB[13579]" in /usr/share/pilot-link/udev/60-pilot.rules ? I believe this will break compatibility with the few devices that use an even-numbered ttyUSB port. Other than this, the two builds seem fine. Also tested after reverting to the current Fedora updates version of pilot-link.
(In reply to comment #36) > README.fedora references files in /usr/share/doc/pilot-link/ - these need to be > changed to /usr/share/pilot-link/ (no doc/). Hmm, I think what happened I was going to put them in /usr/share/doc/pilot-link-*/ and updated README.fedora then I changed my mind, but missed changing some back. I'll fix that. > Is there any reason why KERNEL=="ttyUSB*",NAME="ttyUSB%n" as tested in comments > from this bug has been changed to KERNEL=="ttyUSB[13579]" in > /usr/share/pilot-link/udev/60-pilot.rules ? > I believe this will break compatibility with the few devices that use an > even-numbered ttyUSB port. I think I changed that at Ivana's recommendation, based on feedback from Harald Hoyer, but since those configs aren't installed by default, they could be changed back. > Other than this, the two builds seem fine. Also tested after reverting to the > current Fedora updates version of pilot-link. Good. Could you please test installing an upgrade of the original visor-enabled package, then install from a fresh install? I want testing of the "/sbin/service haldaemon condrestart" which should only run in the case of an update.
Build in progress here: http://koji.fedoraproject.org/koji/buildinfo?buildID=30382 RPMs should be downloadable from there soon. Please test, if all is well (and you can test both fresh installs as well as upgrades), I'll push to updates-testing and ask Ivana to obsolete the currently pending pilot-link in updates-testing.
(In reply to comment #37) > Good. Could you please test installing an upgrade of the original > visor-enabled package, then install from a fresh install? I want testing of the > "/sbin/service haldaemon condrestart" which should only run in the case of an > update. Judging from chatter in /var/log/messages, the haldaemon restart occurs when I update from pilot-link-0.12.2-7.fc8 to pilot-link-0.12.2-14.fc8. It doesn't happen if I force a complete removal of the pilot-link package, then install pilot-link-0.12.2-14.fc8 anew.
(In reply to comment #39) > Judging from chatter in /var/log/messages, the haldaemon restart occurs when I > update from pilot-link-0.12.2-7.fc8 to pilot-link-0.12.2-14.fc8. It doesn't > happen if I force a complete removal of the pilot-link package, then install > pilot-link-0.12.2-14.fc8 anew. Right, that sounds correct. I'm also curious to know whether it works when you (say) actively have the visor module loaded using the old version, then update to the new package, that you can use the new libusb version "out of the box", without having to manually unload the visor module or restart hal.
I --oldpacakge'd back to 0.12.2-7.fc8 and modprobe'd visor in. If I then update to 0.12.2-15.fc8 hal is restarted, and lsmod shows that visor is no longer loaded. So looks like it's working. Great!
> /sbin/service haldaemon condrestart No, no, no. You shall not under any cimcumstances restart the hal daemon.
(In reply to comment #42) > No, no, no. You shall not under any cimcumstances restart the hal daemon. What's the correct mechanism? udevcontrol reload_rules ? (I remember searching several months ago for the Right Way to reload udev rules once they'd been changed, but didn't find a definitive answer)
(In reply to comment #43) > (In reply to comment #42) > > No, no, no. You shall not under any cimcumstances restart the hal daemon. > > What's the correct mechanism? udevcontrol reload_rules ? > > (I remember searching several months ago for the Right Way to reload udev rules > once they'd been changed, but didn't find a definitive answer) There's no correct way, presently, to do this with either hal or udev. In the future there might be a command to poke one or more devices. Until then the best advise is to replug the device.
(In reply to comment #44) > There's no correct way, presently, to do this with either hal or udev. In the > future there might be a command to poke one or more devices. Until then the best > advise is to replug the device. Why is that bad? What do you mean by "replugging" the device? Unplugging and replugging in? I don't think that works. Anyway, all I am doing is automating in a scriptlet what Harald Hoyer (who crafted the libusb solution in the first place) says: "# service haldaemon restart # rmmod visor" from http://www.harald-hoyer.de/linux/console_acls_for_palm
(In reply to comment #45) > Why is that bad? Because it interrupts the use of other clients and daemons relying of services from HAL. By what you are doing, you may very well be crashing other software running on the system. It's the same reason the hal package itself doesn't restart the service. By the same token you don't see the X server restarting itself when being updated. Similar, you don't see the kernel kexec'ing itself on upgrade. > What do you mean by "replugging" the device? Unplugging and > replugging in? I don't think that works. Works fine; the user just unplugs the device and plugs it in again. > Anyway, all I am doing is automating > in a scriptlet what Harald Hoyer (who crafted the libusb solution in the first > place) says: > > "# service haldaemon restart > # rmmod visor" > > from http://www.harald-hoyer.de/linux/console_acls_for_palm That's wrong. Harald is not the upstream nor the package maintainer in Fedora for hal. I am.
(In reply to comment #46) > It's the same reason the hal package itself doesn't restart the service. By the > same token you don't see the X server restarting itself when being updated. > Similar, you don't see the kernel kexec'ing itself on upgrade. OK, I will remove it, but it isn't unreasonable assumption that it *could* be restarted since several most services in /etc/init.d/ work OK with a restart. > > What do you mean by "replugging" the device? Unplugging and > > replugging in? I don't think that works. > > Works fine; the user just unplugs the device and plugs it in again. I haven't tested replugging per se, but I know I needed to do something before the HAL/libusb solution took effect. So does the HAL daemon notice the new rules and apply them upon the "replugging"? > > "# service haldaemon restart > > # rmmod visor" > > > > from http://www.harald-hoyer.de/linux/console_acls_for_palm > That's wrong. Harald is not the upstream nor the package maintainer in Fedora > for hal. I am. Fair enough, so we can remove the condrestart and add a note for the user in README.fedora as well as in the text for the bodhi update that the user needs to unplug the device is it is currently plugged in for it to work. If the Palm isn't plugged in at the time of upgrade, does the user need to plugin it in, unplug and replugin it in, or can the user just plug it in and have it work "out of the box"?
(In reply to comment #47) > OK, I will remove it, but it isn't unreasonable assumption that it *could* be > restarted since several most services in /etc/init.d/ work OK with a restart. Thanks. I should probably remove condrestart but upstream plans also include abandoning an init script all together (uses activation instead). > Fair enough, so we can remove the condrestart and add a note for the user in > README.fedora as well as in the text for the bodhi update that the user needs to > unplug the device is it is currently plugged in for it to work. > > If the Palm isn't plugged in at the time of upgrade, does the user need to > plugin it in, unplug and replugin it in, or can the user just plug it in and > have it work "out of the box"? Yes, new rules and update to rules are automatically recognized. We just can't apply them if the device is already plugged in... e.g. if you do the upgrade, and *then* plug in the Palm everything is good. Similar if you do the upgrade and replug your Palm it's also good. (It might be possible in the future to apply new/changed rules to devices.. but at least one way of thinking about it the problem wouldn't allow it. It's something I'd like to be possible but it's a hard problem.)
OK new F-8 build available in koji, please test: http://koji.fedoraproject.org/koji/buildinfo?buildID=30545 with the following changes: * Mon Jan 7 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 2:0.12.2-16 - Don't restart haldaemon - Update README.fedora to mention replugging to enable new HAL - Don't tag HAL/PolicyKit files as %config (#427840) New text added to README.fedora: "IMPORTANT: If your Palm device is plugged in at the time of the upgrade (or you are experiencing difficuly with having the Palm device recognized) you should probably unplug and replugin in your device after the upgrade for the new HAL configuration to take effect." (also synchronised rawhide/devel branch with all the recent F-8 changes)
Ping? Any feedback on the new build? I'd like to push to updates-testing and obsolete the current version in updates-testing: https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4431
Hello, thanks for your comments, after a discussion with Alex (thanks), I have built a new version (pilot-link-0.12.2-17.fc8) which is in test branch now - if there is be no major problem then it will go to stable branch in a week. It will be great if anybody can test it. The changes are: * remove the visor removal from %prep section - it is unacceptable to have a command which affect runtime tasks, packages should be buildable as non-root - instead of this there is a note in README.fedora * add KERNEL=="ttyUSB[13579]" instead of KERNEL=="ttyUSB*",NAME="ttyUSB%n" - NAME="ttyUSB%n" - is useless - KERNEL=="ttyUSB*" - with this rule udev can choose arbitrary ttyUSB* "file" so it could be bogus for many pdas * change README.fedora
Update is here (which includes link to koji build you can download before it goes to update testing): https://admin.fedoraproject.org/updates/F8/pending/pilot-link-0.12.2-17.fc8
There are a number of Palm devices that use even numbered /dev/ttyUSBn ports, please look at http://www.pilot-link.org/node/111 for more information on this. The change to the KERNEL=="ttyUSB[<ports>]" string will affect a number of devices.
(In reply to comment #53) > There are a number of Palm devices that use even numbered /dev/ttyUSBn ports, > please look at http://www.pilot-link.org/node/111 for more information on this. > The change to the KERNEL=="ttyUSB[<ports>]" string will affect a number of devices. Remember that the update now uses libusb so these visor/udev method is now obsolete with this update, so this change only affects people who want to go back the previous method. The README.fedora does mention alternative modifications to make these devices work, see: http://cvs.fedoraproject.org/viewcvs/rpms/pilot-link/F-8/README.fedora?rev=1.5&view=auto
Also, the current version of pilot-link didn't carry any udev configurations in any case, so strictly speaking this doesn't change the existing behaviour. The udev configurations are provided as documentation so that the user can drop back to using the visor method if needed.
OK, I see that this is in theory going to work better than the visor module, but I'm nervous because of the practical impossibility of making it work since FC5 for me. I withdraw my objection in view of the additional information given, but please keep this under review in case it turns out to be problematic. I can't test it myself yet as I have not migrated from F7 to F8 so far.
Thanks Brian for your comment. I agree with Alex I hope the hal version will be ok for the majority of users and udev solution is for now "only" a part of documentation.
This update isn't working for me. Actually, pilot-link works perfectly with usblib enabled and I can sync my Palm TX, but only for root. Unfortunately, the whole HAL/PolicyKit/ACL setup isn't working and I can't sync with a normal user. First, a lateral issue that may or may not be related. After installing the package for the first time, if HAL daemon is running, it crashes the first time I plug the palm. I tested it manually; if HAL is running with no 19-pam-acl-management.fdi file (but with all the other configurations) and I add this file, it crashes when I plug the palm. If I restart HAL, everything is fine. Then, when I plug the palm, everything seems to work. The palm is recognized and an ACL is created: [root@host ~]# ll /dev/bus/usb/002/ total 0 crw-r--r-- 1 root root 189, 128 2008-01-10 22:24 001 crw-r--r--+ 1 root root 189, 186 2008-01-10 23:09 059 [root@host ~]# getfacl /dev/bus/usb/002/059 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/002/059 # owner: root # group: root user::rw- user:myuser:rw- #effective:r-- group::r-- mask::r-- other::r-- I don't know much about ACLs, but the mask seems to be undoing all work done by PolicyKit (or whatever), as the mask effectively gives my user the same permissions it already had.
Hello, thanks for your comment - there are two problems 1/ After the update to pilot-link-0.12.2-17.fc8 when you plug the palm HAL daemon crashes. Please could you attach here the log which is displayed? 2/ Pilot-link does not sync with your palm - getfacl output seems to be good. Do you have visor module activated? And which version of kernel do you use? Could you attach here the output of pilot-link command which does not work for you? Thanks.
David, could you please look at #58 (the second paragraph), where could be the problem? Thanks. Ivana
(In reply to comment #58) > This update isn't working for me. Actually, pilot-link works perfectly with > usblib enabled and I can sync my Palm TX, but only for root. Unfortunately, the > whole HAL/PolicyKit/ACL setup isn't working and I can't sync with a normal user. Did you happen to update from the previous version of the package that was in updates-testing? It's possible that the new HAL file isn't taking effect because the old one was marked %config(noreplace). This has been fixed in the new version. You might want to remove all pilot-link related packages and files and start fresh and see if you can still duplicate the error.
Yep, something is up here too - yesterday I did a big yum update which may, or may not, have changed something I guess. I'm now on kernel-2.6.23.9-85.fc8. I don't see any evidence of the hal crash mentioned in comment #58. However, running as a normal user, pilot-xfer just sits there waiting (works as root). This is consistent with previous problems where the user doesn't have permissions. How does pilot-link detect additions/changes on the USB bus? As in comment #58, getfacl (I presume this is the right command to use?) shows: # file: dev/bus/usb/004/008 # owner: root # group: root user::rw- user:krp:rw- #effective:r-- group::r-- mask::r-- other::r-- (I'm surprised to see you say that pilot-xfer doesn't need rw access, but if you say so...) hal-device has a new Palm Handheld device after every press of the hotsync button - i.e. the devices created on hotsync aren't removed from hal-device. I haven't found anything that summarises how all this is _meant_ to fit together, so this could be working as designed, but I thought I'd mention it.
Ok, I just installed F8 clean from DVD on an old PC, and _without_ running yum update just installed the -17 koji build of pilot-link. Firstly, I see the haldaemon crash as described in comment #58 when I plug the Treo in: Jan 11 21:04:20 localhost kernel: usb 1-2: new full speed USB device using uhci_hcd and address 2 Jan 11 21:04:20 localhost kernel: usb 1-2: configuration #1 chosen from 1 choice Jan 11 21:04:24 localhost kernel: hald[2034]: segfault at b7e02000 eip 080571b6 esp bfc3c010 error 4 Restarting the haldaemon fixes this, but something is clearly wrong somewhere. Secondly, I _can_ use pilot-xfer as a non-root user without any problems. getfacl for the device nodes in question shows: # file: dev/bus/usb/001/004 # owner: root # group: root user::rw- user:testuser:rw- group::r-- mask::rw- other::r-- Note that there _isn't_ a mask, and testuser has rw permissions - unlike comments #58 and #62. N.B. This is a different machine to that I've been using in all my other comments. This is all running on the console - it's a bit too painful to use a modern X11/Gnome desktop on this PC - but that shouldn't make a difference, should it?
pilot-link-0.12.2-17.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pilot-link'
(in comment #63 obviously I meant there "isn't a read-only mask") I've just tested on yet another old PC: this one is a clean F8 install which _has_ been updated to the current packages in the updates repository and then pilot-link-0.12.2-17.fc8 - but nothing else has been fiddled with or configured. Again using console not X... pilot-xfer doesn't work non-root. getfacl: # file: dev/bus/usb/002/004 # owner: root # group: root user::rw- user:testuser:rw- #effective:r-- group::r-- mask::r-- other::r-- There's that pesky read-only mask again. Where is this set? Is it the: <merge key="access_control.file" type="copy_property">linux.device_file</merge> in 20-pda-acl-management.fdi, and if so, would linux.device_file have changed over F8 updates? I also see the hald crash again: Jan 11 21:52:46 localhost kernel: usb 2-2: new full speed USB device using o hci_hcd and address 2 Jan 11 21:52:47 localhost kernel: usb 2-2: configuration #1 chosen from 1 ch oice Jan 11 21:52:47 localhost kernel: hald[2165]: segfault at b7ded000 eip 08057 1b6 esp bf8e6b10 error 4 grepping /var/log/messages on my usual machine (as used except for the last two comments) I don't see this segfault on the last update to 0.12.2-17.fc8, but I do find lots of them from some time ago. Judging from the log date I suspect I would've been testing 0.12.2-10. I guess that's why I concluded haldaemon needed restarting to get anything to work!
(In reply to comment #59) > 1/ After the update to pilot-link-0.12.2-17.fc8 when you plug the palm HAL > daemon crashes. Please could you attach here the log which is displayed? I removed all pilot-link packages and files, reinstalled pilot-link-0.12.2-17.fc8 and the HAL did not crash. However, I can reproduce it with these steps (with pilot-link installed): # mv /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi . # /etc/init.d/haldaemon restart # I know, this is wrong, but it is necessary to reproduce the bug Plug the palm Unplug the palm # mv 19-pam-acl-management.fdi /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi Plug the palm Segfault It haven't had the patience of trying this, but it seems to me that if HAL is running, but with no policy installed (and no visor module), if you plug and unplug the palm and then install pilot-link, it will crash. Here is the log: Jan 11 22:30:19 hamlet kernel: hald[32139]: segfault at 00002aaaaad94000 rip 0000000000410270 rsp 00007fff78937ff0 error 4 > 2/ Pilot-link does not sync with your palm - getfacl output seems to be good. Sorry, it doesn't. If it were ok, the "other::r--" permission would be enough and we would not be messing with HAL/PolicyKit. > Do you have visor module activated? No. Or else it would not work as root. > And which version of kernel do you use? 2.6.23.9-85.fc8 x86_64 > Could > you attach here the output of pilot-link command which does not work for you? Sorry, it just locks. No errors. BTW, I guess Kevin has managed to reproduce the ACL bug (and the non-bug :)). It clearly does not affect all systems. So, if you need more data about mine, just ask. One more thing, sometimes the first time I plug the palm, the ACLs are right. But it doesn't help me, because when I press the hotsync button, another device is created with the wrong ACL. > Thanks. Thank you very much for paying attention to this bug!
The package doesn't currently work and clearly shouldn't get beyond updates-testing. My tests above strongly suggest that there was a change in HAL/PolicyKit which means the Palm configuration worked with earlier versions, but now doesn't. That's not to say there isn't an incorrect assumption in the Palm config exposed by a legitimate change in HAL. linux.device_file (comment #65) is a false lead, I now understand that this is just passing the actual device node where the Palm is discovered to HAL. I can see that the config sets access_control.type to pda, and that the policyconfig should allow_active access - I'm unclear as to which part of HAL/PolicyKit then applies this ACL - i.e. where the ro, rather than rw, mask is being introduced.
I pulled down a bunch of updates tonight, including udev-118-1.fc8 pilot-xfer now works as the active user, and the ACLs are set correctly: # file: dev/bus/usb/004/007 # owner: root # group: root user::rw- user:krp:rw- group::r-- mask::rw- other::r-- I strongly suspect the resolved bug #424331 was culprit.
It started working for me. I can't say exactly when, but I also have udev-118-1.fc8 installed. The segfault bug in hal still persists (see comment #66), but I guess this should be another bug.
If the pilot-link currently in updates-testing works for you (or does not work), consider adding a note and/or a "works for me" (or "doesn't work" as appropriate) on: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-0453 Please only leave short notes, detailed bug reports should go here.
(In reply to comment #69) > It started working for me. I can't say exactly when, but I also have > udev-118-1.fc8 installed. Please consider adding a "works for me" as detailed in comment #70 above. > The segfault bug in hal still persists (see comment #66), but I guess this > should be another bug. Yes, probably should be filed separately, but leave a link to the new bug here).
Hmm, finally got around to testing the new version still in updates-testing using libusb method, but unfortunately something changed, such that my Treo 680 will only sync as root. I manually restarted hal, and actually even tried a complete clean reboot and there is no visor module loaded. Then I try (as a normal user): $ pilot-xfer -p usb: -l Listening for incoming connection on usb:... Now I press hotsync on the device, but nothing happens. Here's what I see in the syslog at the time of the press: Jan 30 04:26:30 binoche kernel: usb 1-2: USB disconnect, address 5 Jan 30 04:26:31 binoche kernel: usb 1-2: new full speed USB device using uhci_hcd and address 6 Jan 30 04:26:31 binoche kernel: usb 1-2: configuration #1 chosen from 1 choice Something about the change in policykit or hal rules cause the device to only be recognised as root. Here is the getfacl output: $ getfacl /dev/bus/usb/001/00* getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/001/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: dev/bus/usb/001/002 # owner: root # group: root user::rw- group::r-- other::r-- # file: dev/bus/usb/001/009 # owner: root # group: root user::rw- group::r-- other::r--
I do have udev-118-1.fc8 from bug #424331, so that doesn't seem to be the problem.
Gosh, how frustrating. Something has changed here too, and I'm experiencing the same problem as Alex (comment #72). It was working back for me back in comment #68. Doing an lsusb I noticed: Bus 004 Device 004: ID 0830:0061 Palm, Inc. Palm Zire 31 Which is wrong, because it's a Treo 680, not a Zire 31. hal-device shows: info.product = 'Palm Zire 31' (string) so the udev/PolicyKit rules are no longer matching - they need "Palm Handheld". strace of lsusb incriminates the file /usr/share/hwdata/usb.ids, which is part of package hwdata - and sure enough this was updated on Jan 25. Reverting to hwdata-0.207-2.fc8.noarch.rpm fixes the problem for me. So is: 1) The new version of hwdata "more correct" and the pilot-link PolKit scripts need to be more complicated to match all the different Palm handhelds? Though it's obviously not completely correct as it's mis-identified my Treo as a Zire 31. 2) The newer hwdata is wrong and needs reverting? Either way it strikes me that hwdata has enormous power to break scripts related to udev/Polkit etc. - or is this an isolated incident? Perhaps there needs to be an clear policy to make sure new scripts are using the hwdata correctly (1); or a sanity check to see potential effects of hwdata changes before they're released (2) (e.g. if a string is removed/amended from hwdata find do a find over relevant scripts to check if it's in use) (karsten cc'd for hwdata)
Looks like upstream for the usb.ids erronously used the USB id 0830:0061 for Palm Zire 31, please add a comment p.e. to http://www.qbik.ch/usb/devices/showdev.php?id=3930
I don't think so; http://www.pilot-link.org/node/111 clearly shows that the USB id 0830:0061 is for the Zire 31, it's also for the Tungsten T5, the Treo 650, the Zire 21 and the Zire 72. You can't use the USB id to definitively identify Palm devices in this manner.
pilot-link-0.12.2-17.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
much better with pilot-link-0.12.2-17.fc8 but not yet perfect; I had to - cp /usr/share/pilot-link/udev/60-libpisock.rules /etc/udev/rules.d/ - change every instance of "dialout" to "uucp" in 60-libpisock.rules - usermod -a -G uucp me # (where 'me' is my username) - obviously log out and back in so that the group change takes note: - as there still is a slight delay getween pressing the sync button and the device being there, it would be nice if we gave some feedback (visual or audio) once the device is available. Not sure how to achieve this, my first thought was to add , PROGRAM=="/usr/bin/aplay /home/pcfe/Documents/LCARSsounds/comp/206.wav" to the udev rules but pulseaudio will not let udev access the sound device (quite rightly so), so this needs another solution - I have no group dialup, not sure if this is my setup (then no need to worry) or if F8 in general does not have that group (then the example file needs adjusting to uucp - the README.fedora should have a note of all the above
Well, pilot-link-0.12.2-17.fc8 definitely doesn't work out of the box for me. I have a Zire 22, have selinux disabled, and run kde, if those could make any difference. When I try the vanilla config, here's what I see: first, plug in palm and lsusb and hal-device agree that it is /dev/bus/usb/003/NNN, but pequod(~) ls -l /dev/bus/usb/003/NNN crw-r--r-- 1 root root 189, 266 2008-02-03 12:21 /dev/bus/usb/003/NNN pequod(~) getfacl /dev/bus/usb/003/NNN getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/NNN # owner: root # group: root user::rw- group::r-- other::r-- then after I start "pilot-xfer -p usb: -l", then hit HotSync on the palm, the palm moves to /dev/bus/usb/003/NNN+1 and I see the same permissions. Looking at the comments from those lucky enough to have this work, I suspect that I should be seeing an additional line in getfacl output like "user:joe:rw-" In other words, I see the same failure as in comment #72. This happens both on my laptop, where I have been using pilot-link successfully with the visor module and udev kludge, and on my desktop, where, until today, I had never used pilot-link. Both are fully updated F8 machines. FWIW the libpisock udev kludge has never worked for me. Sigh.
(In reply to comment #71) > Yes, probably should be filed separately, but leave a link to the new bug here). > Filled under bug #431377.
As reported above, this package stopped working for me also. My Palm T|X is now considered a Zire 31 and I can only sync as root. I'm seeing the same behavior of comment #72 and comment #79.
A shame, given comment #72 and comment #74, that this went to stable. Guess I (we) should have given more "does not work" on koji? From comment #76, we can say that either: a) there's a bug in the latest release of hwdata b) there's a bug in the latest release of hwdata and the pilot-link polkit rules make incorrect assumptions about info.product Karsten: Has the upstream db changed since you last linked to it? It looks ok to me - although if it's just been changed to Treo680 that will presumably break things for any other devices that Palm uses the same product ID for. What, in this situation, should pilot-link expect to find as the product string? Do I need to file a bug against hwdata, or are you tracking the problem here? Patrick: could you try the newer libusb method instead, please? - it obsoletes the problems you list (and it's _impossible_ to get the libpisock.rules method to ship in a working state for _all_ devices). You'll need to revert hwdata with the updates currently in stable... Joe, Gustavo: if you revert to hwdata-0.207-2.fc8.noarch.rpm it should work. See comment #74.
Alas, reverting to hwdata-0.207-2.fc8.noarch.rpm does make my device permissions more inline with those in comment #62: [root@pequod ~]# ls -l /dev/bus/usb/003/ total 0 crw-r--r-- 1 root root 189, 256 2008-02-04 14:59 001 crw-rw-r--+ 1 root root 189, 264 2008-02-04 15:09 009 [root@pequod ~]# getfacl /dev/bus/usb/003/* getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: dev/bus/usb/003/009 # owner: root # group: root user::rw- user:joe:rw- group::r-- mask::rw- other::r-- and hal-device shows: usb_device.product = 'Palm Handheld' (string) instead of 'Zire 31 ' _BUT_ pilot-xfer hangs: pequod(~) pilot-xfer -p usb: -l Listening for incoming connection on usb:... [ad infinitum] It doesn't matter whether I plug a/o hotsync before/after I launch pilot-xfer. Sigh.
(In reply to comment #83) > # file: dev/bus/usb/003/009 > # owner: root > # group: root > user::rw- > user:joe:rw- ... > _BUT_ pilot-xfer hangs: > pequod(~) pilot-xfer -p usb: -l Joe: the permissions look fine now. I see from comment #79 that you're using a Zire 22? Unfortunately the Zire 22 doesn't work with pilot-link/libusb, though patches are available. I've filed this, and cc'd you, in bug #431498. (In the meantime, you might like to see if the instructions in README.Fedora get you anywhere with the older visor module method - but libusb is the preferred solution heading forward)
in response to comment #82: if you meant that I need hwdata-0.215-1.fc8 , then it does not work. My Tungsten T5 gets identified as 'Palm Zire 31' and the perms seem wrong # file: dev/bus/usb/003/062 # owner: root # group: root user::rw- group::r-- other::r-- Can you please tell me if I used the right hwdata, in that case I will open a separate bug. Or if I used the wrong one, in that case can you tell wheich exact version I should use in testing.
(In reply to comment #85) > if you meant that I need hwdata-0.215-1.fc8 , then it does not work. > > Can you please tell me if I used the right hwdata, in that case I will open a > separate bug. Or if I used the wrong one, in that case can you tell wheich exact > version I should use in testing. As I've already said in comment #74 and comment #82: Reverting to hwdata-0.207-2.fc8.noarch.rpm fixes the problem for me. This was the version used in F8 until the update in late January. You'll probably need to restart haldaemon or reboot.
All of the most recent Palm devices appear to use the same USB ID, so it seems to me that taking the correct action based on the device ID is unlikely to be possible, there must be a further process of identifying the actual device. That's a different problem from the permissions issue, but maybe they are related due to taking the wrong action based on misidentifying the device. This whole hal/udev/ConsoleKit/PolicyKit thing has become so complex that I no longer understand exactly how it works, adding the libusb/visor issues in pilot-link into the whole situation just makes it worse. I suspect that much of the problem is due to not treating these packages as an interrelated whole, but I don't know how to get that to happen. Comments?
Bravo comment #87! It seems to me that question is: does pilot-link need to behave differently with distinct devices that Palm has chosen to give the same USB vendor:product pair? The answer is probably to ask that upstream pilot-link and upstream hwdata harmonize their handling of this Palm-created mess.
(In reply to comment #87) > All of the most recent Palm devices appear to use the same USB ID, so it seems > to me that taking the correct action based on the device ID is unlikely to be > possible, there must be a further process of identifying the actual device. The udev/polkit config in the Fedora pilot-link package: - needs to identify _all_ USB devices that use pilot-link so it can set permissions for the current console user to access those handhelds. I'm confident this can be done, but would like confirmation of what string we should expect to receive from hwdata [1] - is distribution specific as other distributions don't use PolicyKit yet. - uses the hwdata package to map product IDs to product description strings and hal/udev to propagate this information. pilot-link (upstream): - needs to identify _different_ USB devices and act accordingly; during the hotsync connection process different devices have different timing tolerances (this was the problem with your Zire 22). - has a relatively small lookup table as it only cares about PalmOS handhelds. - is unlikely to introduce a dependency on hwdata for ID mappings. (In reply to comment #88) > It seems to me that question is: does pilot-link need to behave differently with > distinct devices that Palm has chosen to give the same USB vendor:product pair? Yes. The PolicyKit rule doesn't. [1] It may be that the polkit rule needs a lookup table of all valid product IDs, rather than matching on a string. Does the current rule match e.g. Sony PalmOS handhelds? I suspect not.
in response to comment #86 # rpm -Uhv --oldpackage hwdata-0.207-2.fc8.noarch.rpm # /etc/init.d/haldaemon restart # getfacl /dev/bus/usb/003/090 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/090 # owner: root # group: root user::rw- group::r-- other::r--
Karsten what would be better way to identify palm devices (the original idea of using the USB id 0830:0061 was from hal-info file 10freedesktop/10-usb-pda.fdi)?
Created attachment 294103 [details] Fixed .fdi file Ok, I found the problem and have a solution, but it may not be the best solution going forward. The problem isn't exactly with hwdata, but with the pilot-link .fdi file. I may be wrong, but it is not necessary to rely on hwdata provided strings to match a device. This can be done using the USB ids directly and was partially done in the .fdi file, with the string used only as a fallback. The problem is it was done wrong: the match was being made on the keys "usb.vendor_id" and "usb.product_id", but it should be made on the keys "usb_device.vendor_id" and "usb_device.product_id". The fallback was actually catching all cases. I fixed the 19-pam-acl-management.fdi file to match the correct keys and it worked for me. I went a bit further and added all PalmOS ids I could find in the 60-libpisock.rules. I also removed the label based fall back as I can't see how it could be made to work reliably. I'm attaching the corrected file. The reason why this may not be the best solution is that we will have to keep the list of USB ids synchronized with what pilot-link supports. However, the USB ids supported by pilot-link are a property of the software and maybe this (the whole HAL/PolicyKit conf) should be propagated upstream. Regardless of the future proof solution, the patch I made works now and hopefully fixes the package for most of the users.
(In reply to comment #90) > # rpm -Uhv --oldpackage hwdata-0.207-2.fc8.noarch.rpm > # /etc/init.d/haldaemon restart > # getfacl /dev/bus/usb/003/090 Patrick: what does lsusb show for your Palm? (If it's not "Palm Handheld" then, no, I'm afraid it won't work yet).
(In reply to comment #92) > The problem isn't exactly with hwdata, but with the pilot-link .fdi file. Gustavo - great, thanks! I was coming to the same conclusion; Ivana mentioning 10freedesktop/10-usb-pda.fdi was the final piece of the puzzle (are the PalmOS entries in this obsolete now?) I wonder whether the vid/pid matching should go in 10freedesktop/10-usb-pda.fdi (upstream then to the hal-info package) rather than in pilot-link, marking "pda.platform" as "palm" and perhaps "pda.palm.hotsync_interface" as "usb" (if this is a valid value). The "access_control" capabilities could then be set by matching on "pda.platform" == "palm" (and perhaps "usb"). Or if we wanted to have console rw on all PDAs (including non-Palm) just match on "info.capatilities" == "pda". In summary: we should use the vid/pid to set a generic "pda" capability first, then match on this capability to set the access_control properties (rather than the vid/pid directly). Thoughts? As for vid/pid that pilot-link will recognise with USB, look at known_devices[] in usb.c from the pilot-link source: http://cvs.pilot-link.org/libpisock/usb.c?view=log P.S. hwdata is still incorrect ;)
I submitted a patch for usb.ids to the maintainer a few days ago, if this is accepted (and I don't see why it wouldn't) this will eventually make it into hwdata. However, I note that the link in comment #94 about pilot-link's usb.c device definitions shows that there are still missing Palm devices, but I don't know how much this matters. I will see if I can get David D to comment on it on the pilot-link mailing list.
WRT comment #89 >> It seems to me that question is: does pilot-link need to behave differently with >> distinct devices that Palm has chosen to give the same USB vendor:product pair? >Yes. The PolicyKit rule doesn't. I don't see how pilot-link does this then since the fix in bug #431498 simply adds some derived information to the data structures it maintains based on the vendor:product pair that it reads from the Palm, and acts according to the derived information. cf. comment #8 in bug #431498.
To the (minimal) extent that I can understand /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi, the stanza: <!-- Known Palm PDAs from Palm, Inc. --> <match key="usb.vendor_id" int="0x0830"> <!-- Palm m130 --> <match key="usb.product_id" int="0x0050"> <append key="info.capabilities" type="strlist">access_control</append> <merge key="access_control.type" type="string">pda</merge> <merge key="access_control.file" type="copy_property">linux.device_file</merge> </match> <!-- Tungsten T5 --> <match key="usb.product_id" int="0x0061"> <append key="info.capabilities" type="strlist">access_control</append> <merge key="access_control.type" type="string">pda</merge> <merge key="access_control.file" type="copy_property">linux.device_file</merge> </match> </match> looks like it should (which it obviously doesn't) set the permissions properly when I plug in my Z22 (which does match usb.vendor_id=0x0830 and usb.product_id=0x0061), independent of hwdata/PolicyKit. FWIW, wrt comment #93, with hwdata-0.207, lsusb report my Z2 as: Bus 003 Device 010: ID 0830:0061 Palm, Inc. while with hwdata-0.215, lsusb reports it (on a different box) as: Bus 005 Device 002: ID 0830:0061 Palm, Inc. Palm Zire 31 I'm just trying to glean enough information so that I can get sync working the next time pilot-link, or hwdata, or PolicyKit change and topple the house of cards, without resorting to the deprecated visor kernel module.
(In reply to comment #97) > looks like it should (which it obviously doesn't) set the permissions properly > when I plug in my Z22 (which does match usb.vendor_id=0x0830 and > usb.product_id=0x0061), independent of hwdata/PolicyKit. Joe, take a look at comment #92 to see why the current configuration doesn't work.
(In reply to comment #96) > I don't see how pilot-link does this then since the fix in bug #431498 simply > adds some derived information to the data structures it maintains based on the > vendor:product pair that it reads from the Palm Sorry, yes, you're right. When skim-reading the pilot-link lists for Z22 compatibility I mistakenly came to the conclusion that different devices with the same pid had different timing quirks (so let's hope Palm haven't actually inflicted this upon us!). As per Gustavo's patch (comment #92), the hal/polkit should be disentangled from the hwdata provided strings (those these should still be fixed; Brian has already sent a patch upstream - comment #95).
Created attachment 294520 [details] .fdi file containing information about PalmOS handhelds DavidZ: could you check this over, please? (Bug owner: could you mark this as NEEDINFO for David. Thanks.) Ok, encouraged by the HAL Specification, I've split out Information and Policy regarding PalmOS handhelds as I was mulling in comment #94. This first attachment matches on USB VID/PID (based on Gustavo's patch) for PalmOS PDAs and sets: a "pda" capability; the pda platform as "palm"; and the correct value for the hotsync port. It is a new, additional, .fdi file, and should currently be placed in /usr/share/hal/fdi/information/20thirdparty/ but should probably, long term, be merged into hal-info via upstream - see (1), below. In a moment I will attach the second file, which replaces the existing /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi currently shipped in the pilot-link package. This sets the same access_control policy as the current version, but matches on the "pda" capability and "palm" platform - not directly on USB ID. i.e. I've separated out identifying a Palm PDA, and setting access_control capabilities for such Palm PDAs. Questions: 1) This attachment should probably be merged into the existing /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi, via freedesktop, shouldn't it? 2) I copied the use of the pda capability, pda.platform and pda.palm.hotsync_interface from /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi - but these namespaces aren't defined in the HAL spec. Ok? 3) This currently sets access_control policy only for "pda"s with the "palm" "pda.platform"; good policy at the current time, or better to grant access for all PDAs? 4) Is this using HAL as designed? Is it good policy to set access control by capability rather than for specific devices (duplicating vid/pid matching)? I have also synchronised the USB VID/PID matching in this .fdi file with: http://cvs.pilot-link.org/libpisock/usb.c?view=log i.e. it matches only those devices the pilot-link USB code recognises (no point matching anything else, pilot-link/libusb won't work with them!) This has added a number of devices, and removed: 0x04e8:0x6601 (a Samsung)
Created attachment 294521 [details] Replacement /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi When used in conjunction with attachment #294520 [details] this attachment should replace the existing /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi shipped with pilot-link. See comment #100. Out of curiosity, why is the file called "pam-acl-management" - what's with the "pam" bit?
Thanks to all for your work - I'm just trying to find the bast version of fdi rules - I need to discuss this with the hal maintainer a bit but I hope an testing package will be released soon (thanks Gustavo and Kevin for your suggestions).
I've solicited advice from the hal mailing list: http://lists.freedesktop.org/archives/hal/2008-February/010772.html If nothing else, the VID/PIDs should probably be pushed upstream, and the HAL list seemed like the appropriate place for discussion. I'll report back if there are any conclusions.
Kevin - Do you believe that one needs _both_ attachment #294520 [details] and attachment #294521 [details]? If so, it would be desirable to give them different names, or do you mean that a merged file combining the two should replace /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi? I don't seem to need attachment #294521 [details].
Joe: attachment #294521 [details] *requires* attachment #294520 [details] to work as designed; but installing attachment #294520 [details] *without* attachment #294521 [details] will just fall back to the behaviour of the existing 19-pam-acl-management.fdi (i.e. the capabilities added by attachment #294520 [details] won't be used to any effect) In other words: yes, both patches are intended to be used together. To restate what I said in comment #100: - attachment #294521 [details] replaces the existing /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi - attachment #294520 [details] should currently be installed as e.g. /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi, but may eventually be better merged into /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi These patches, and the alternative attachment #294103 [details], are slightly different configurations to achieve the same result. I believe my patches provide a cleaner separation between identifying Palm devices and then granting access controls to this class of devices.
Thanks Kevin for your great work - for now I'm still waiting to bug 431377 which should be fixed first. Without the fix for this bug it would be impossible to release any new version.
(In reply to comment #105) I just want to say great work guys. I have been trying for the past two months to get my Palm Tungsten T5 to work again in FC8. I had been using the klunky udev rules up until the upgrade changed ttyUSB to usbdev. I found this mailing list a few days ago and tried several times to make sense of it. I even tried downgrading hwdata, pilot-link, etc. but I kept running into errors and conflicts. I finally restored everything to its 'latest' stable release and implemented the two patches in comment #105. I had to make sure that I un-implemented a couple of the earlier patches. Finally Success!! Again, great work guys!
Fedora 8: Fix not working for me. I created and installed files in the locations as mentioned above post 105. /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi visor is blacklisted. Also created /usr/share/PolicyKit/policy/pilot-device-file.policy as per Hearld Hoyer web site Results: pilot-xfer -p usb: -l Listening for incoming connection on usb:... Just sits there and does nothing waiting for a response. /sbin/lsusb returns this when the palm is set to sync. Bus 001 Device 008: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71 So far no luck,
(In reply to comment #108) > Fedora 8: Fix not working for me. > I created and installed files in the locations as mentioned above post 105. > /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi That's correct. > /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi Also correct. The rest of the configuration should already be in place from the current F8 updates pilot-link package (0.12.2-17.fc8)... > visor is blacklisted. This should be done by the rpm provided /etc/modprobe.d/blacklist-visor > Also created /usr/share/PolicyKit/policy/pilot-device-file.policy > as per Hearld Hoyer web site Did you create this manually? Don't - you'll have overwritten the rpm provided version of this file - which is the one you need. The original version on Harald Hoyer's site is incorrect, although it formed the basis for what we have here. > pilot-xfer -p usb: -l > Just sits there and does nothing waiting for a response. > /sbin/lsusb returns this when the palm is set to sync. > Bus 001 Device 008: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71 If you've reverted the policy file to the one provided by the rpm does this still happen? Does it work as root? (The symptoms above match those from insufficient permissions on the USB device file) If it's still not working, what does: # getfacl /dev/bus/usb/001/* return? (You'll have to change the device path accordingly if you use a different USB port)
I guess comment #105 wasn't quite clear enough without a bit more context, so... SUMMARY OF WHAT TO DO for those wanting to try out libusb and PolicyKit ===================== Make sure you have the latest pilot-link-0.12.2-17.fc8 Check that you haven't manually changed any of the configuration provided by this package (try "rpm --verify pilot-link" for a start) Make the following manual changes: 1) install attachment #294521 [details] as /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi 2) install attachment #294520 [details] as /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi You shouldn't need any other changes - be they from this bug, Harald Hoyer's site, or anywhere else (though there's a known problem with Zire 22 - see bug #431498). Be aware that this solution - or a similar one - will eventually be included in the pilot-link rpm, and the manual changes made here may break that package when it's released!
Also to note that I've submitted the contents of attachment #294520 [details] (with a few VID/PID corrections) merged with the existing 10freedesktop/10-usb-pda.fdi to the HAL mailing list for inclusion upstream and thereby into hal-info. There's not been any response as yet: http://lists.freedesktop.org/archives/hal/2008-February/010836.html If it isn't accepted there I'll post a corrected version of attachment #294520 [details] here (but there are only a couple of VID/PID corrections).
(In reply to comment #109) > (In reply to comment #108) > > Fedora 8: Fix not working for me. > > I created and installed files in the locations as mentioned above post 105. > > /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi > > That's correct. > > > /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi > > Also correct. > > The rest of the configuration should already be in place from the current F8 > updates pilot-link package (0.12.2-17.fc8)... > > > visor is blacklisted. > > This should be done by the rpm provided /etc/modprobe.d/blacklist-visor > > > Also created /usr/share/PolicyKit/policy/pilot-device-file.policy > > as per Hearld Hoyer web site > > Did you create this manually? Don't - you'll have overwritten the rpm provided > version of this file - which is the one you need. > > The original version on Harald Hoyer's site is incorrect, although it formed the > basis for what we have here. > > > pilot-xfer -p usb: -l > > Just sits there and does nothing waiting for a response. > > /sbin/lsusb returns this when the palm is set to sync. > > Bus 001 Device 008: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71 > > If you've reverted the policy file to the one provided by the rpm does this > still happen? Does it work as root? (The symptoms above match those from > insufficient permissions on the USB device file) > > If it's still not working, what does: > # getfacl /dev/bus/usb/001/* > return? (You'll have to change the device path accordingly if you use a > different USB port) > /usr/share/PolicyKit/policy/pilot-device-file.policy > Did you create this manually? Don't - you'll have overwritten the rpm provided > version of this file - which is the one you need. Reverted back to the original file. /usr/share/PolicyKit/policy/pilot-device-file.policy The connection was made successfully as root. Connection was unsuccessful as user. Shouldn't this work as users as well? Thanks!
(In reply to comment #112) > The connection was made successfully as root. > Connection was unsuccessful as user. > Shouldn't this work as users as well? Yes. Please double check you don't have any old manual configuration, perhaps from previous experimenting, and that you definitely have the right files (comment #110). As I already asked at the end of comment #109, please could you check getfacl output; more generally: WHAT TO DO IF IT DOESN'T WORK ============================= If you've followed the setup instructions in comment #110 and "pilot-xfer -p usb: -l" doesn't work... First, try either rebooting your machine or restarting haldaemon (bug #431377 can crash PolicyKit when rules are changed). If it still doesn't work: does "pilot-xfer -p usb: -l" work as root? If NO: then there's likely to be a problem with pilot-link recognising your handheld. There's a known problem with Zire 22s for example (see bug #431498). These problems should be reported in separate bugs, but leave a reference to the new bug here. If YES: it's probably a permissions problem, i.e. a problem with the new PolicyKit rules, that's stopping non-root users accessing the USB device file for the handheld. Please check the following and report your findings in this bug: - find out which USB bus your handheld is attached to using lsusb - use getfacl to check the ACL of the handheld device nodes. e.g. if lsusb shows the Palm on USB bus 003, report the results of: # getfacl /dev/bus/usb/003/* When reporting back to this bug, please be sure to include: the PalmOS handheld you're using; the relevant part of the output from lsusb; the output from getfacl. This bug is already rather long, unwieldy, and confusing; thorough and concise comments are greatly appreciated ;) Hopefully this comment, along with comment #110, will help new testers report problems effectively. Thanks!
(In reply to comment #101) > Out of curiosity, why is the file called "pam-acl-management" - what's with the > "pam" bit? Uh, ok, it's just occurred to me this might be a typo - was it intended to be "palm-acl-management"?
> Yes. Please double check you don't have any old manual configuration, perhaps > from previous experimenting, and that you definitely have the right files > (comment #110). As I already asked at the end of comment #109, I don't recall doing anything more than replacing the files as listed and the policy file from the other site which I restored to the original.(I kept the original copy and renamed it.) For good measure, just in case I was brain dead at the time I reinstalled pilot-link. I then had to replace the file 19-pam-acl-management.fdi to get back to where I was before (connecting as root.) Still no connection as user. >please could you check getfacl output; more generally: lspci= Bus 001 Device 010: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71 getfacl output= # file: dev/bus/usb/001/010 # owner: root # group: root user::rw- group::r-- other::r-- >please be sure to include: the PalmOS handheld you're using; Palm OS v5.2.1
(In reply to comment #115) > For good measure, just in case I was brain dead at the time I reinstalled > pilot-link. I then had to replace the file 19-pam-acl-management.fdi to get back > to where I was before (connecting as root.) Steve, Replacing 19-pam-acl-management.fdi shouldn't make any difference as to whether it works as root - it only affects permissions for user, not the behavior of pilot-link itself. Are you sure it didn't work as root before this? Please confirm you've followed ALL the steps in comment #110 and comment #113 - sorry to go on, but I need to know you've carefully followed all the steps, in order. You only mention that you've followed half of them. Please confirm your pilot-link version, and the *model* of your PalmOS handheld (not the OS version). Double check that the contents of the appropriate files match the contents of the two attachments in comment #110.
Created attachment 295803 [details] Original Fedora8 policy file currently installed.
Comment 115: I have followed the steps in comment 110 verified that the file contents, locations and names are correct. Kevin as you stated, changing file 19-pam-acl-management.fdi is not the cause for it not working as root. Apparently the USB connection didn't reset for some reason. It was a coincidence that I changed the file and rebooted to find it working again as root. I verified this, the behavior occurred with both files The device is Palm Tungsten E Comments 113: The file attached is the original file installed on the machine which I reverted back to based on your instructions. lspci= Bus 001 Device 010: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71 getfacl output= # file: dev/bus/usb/001/010 # owner: root # group: root user::rw- group::r-- other::r-- Condition: pilot-xfer -p usb: -l Connects as root but not as user
CURRENT TESTERS: a new version, pilot-link-0.12.2-18.fc8, has been pushed to updates. This does *not* fix the problems detailed in the bug, but it does still ship with an earlier broken version of the HAL/PolicyKit configuration files. If you install this update please check you still have the manual changes detailed in comment #110 in place. Meanwhile, I've been working through Steve Baker's problem with him directly by email (comment #118 etc.). I'm pretty confident his issue is caused by having the wrong configuration files, not a problem with the supplied configuration itself. We'll report back here if there's a genuine problem with the configuration. NEW TESTERS: Please follow the instructions in comment #110. If you have problems, step through the instructions in comment #113. Thanks! HAL/POLICYKIT REVIEW: Probably best to start with comment #111, comment #100, comment #114, and comment #94.
(This is for future releases of the package; testers should stick with the above instructions for the moment) My patch to upstream hal-info has been accepted; I've created bug #434960 to request a new Fedora hal-info package and marked it as a dependency for this bug. Once hal-info is rebuilt, attachment #294520 [details] becomes obsolete. Only attachment #294521 [details] will be required to fix the pilot-link configuration, which should replace the current 19-pam-acl-management.fdi. I'd suggest that, at the same time, we correct its filename from: /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi to: /usr/share/hal/fdi/policy/10osvendor/19-palm-acl-management.fdi (/usr/share/PolicyKit/policy/pilot-device-file.policy should remains as-is)
As a new tester led here from Harald's page (thanks for the comment Kevin!) I can report success with a fully updated F8 system (no updates-testing) and the procedure in comment #110. Too bad you can't make particular comments "sticky" to the top or bottom of the comment list to more easily help new arrivals. PDA is a Treo 700p.
I have a palm TX. I have fc8 x86_64, all up to date as of 2008-02-28. I have pilot-link 0.12.2-18.fc8. With no modifications, I can access my TX as root, as in pilot-xfer -p usb: -l but not as a regular user. I followed comment #110, put in those files, rebooted, and even tried manually restarting hald. (service haldaemon restart). It still doesn't work as a regular user. lsusb says: Bus 005 Device 005: ID 0830:0061 Palm, Inc. Palm Zire 31 (Yes, it's mis-recognized as a Palm Zire 31, *shrug*) getfacl /proc/bus/usb/005/* says: getfacl: Removing leading '/' from absolute path names # file: proc/bus/usb/005/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: proc/bus/usb/005/005 # owner: root # group: root user::rw- group::r-- other::r--
Garrett, The exact location of the files is very important, and the file names and paths are confusingly similar. The only previous user who has had problems had saved the files in the wrong directories, so please check this very carefully. If it still fails to work, please make a bziped tarball of /usr/share/hal and email it to me directly. When pilot-xfer is trying to connect, could you also run: lshal > lshal_output.txt (or similar) and send that to me as well. Finally, could you let me know what versions of pilot-link, hal, and hal-info you have installed. As before, we'll report back here should it be more than an installation problem.
(In reply to comment #123) > The exact location of the files is very important, and the file names and paths > are confusingly similar. The only previous user who has had problems had saved > the files in the wrong directories, so please check this very carefully. You're right, sure enough I put one of them in the wrong place. Sorry about that. So I fixed that and rebooted, and now I can use pilot-xfer as a regular user and it seems to be working fine. I'm really confused: the acl on those /proc/bus/usb items is the same as it was before, so I don't understand why it's working: getfacl /proc/bus/usb/005/00* says: getfacl: Removing leading '/' from absolute path names # file: proc/bus/usb/005/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: proc/bus/usb/005/006 # owner: root # group: root user::rw- group::r-- other::r-- FYI: Every time I use pilot-xfer, the item number goes up. So one time it's /proc/bus/usb/005/006, then the next time it's /proc/bus/usb/005/008, etc. It seems harmless, but it strikes me as odd.
(In reply to comment #124) > You're right, sure enough I put one of them in the wrong place. Sorry about that. And in a similar vein... > I'm really confused: the acl on those /proc/bus/usb items is the same as it was > before, so I don't understand why it's working: > getfacl /proc/bus/usb/005/00* says: Try, as comment #113 says: # getfacl /dev/bus/usb/005/* N.B. /dev/bus/usb, not /proc/bus/usb
Yep, you're right: getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/005/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: dev/bus/usb/005/009 # owner: root # group: root user::rw- user:garrett:rw- group::r-- mask::rw- other::r-- It's been one of those days...
I noticed that most of the policy in /usr/share/hal/fdi/policy/10osvendor/ and /usr/share/PolicyKit/policy/ belonged to the hal package, especially that relating to device file access. So I've submitted a patch upstream to include PDA access policy: http://lists.freedesktop.org/archives/hal/2008-March/010979.html We'll see how it goes!
Hi Kevin, Thanks for all of your work on this! I finally upgraded to F-8 on mylaptop, so I now have a chance to test your fixes. As per comment #113, I can successfully connect as root, but not as a regular user. Details are for a Palm Treo 680: lsusb output (don't know why it says "Palm Zire 31" when it's really a Treo, but anyhow): Bus 003 Device 024: ID 0830:0061 Palm, Inc. Palm Zire 31 # getfacl /dev/bus/usb/003/* getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/003/001 # owner: root # group: root user::rw- group::r-- other::r-- # file: dev/bus/usb/003/024 # owner: root # group: root user::rw- group::r-- other::r-- Is there a way to force policykit/hal to allow access to the device as a user in the absence of a global fix? If you get a chance it would be great if you could create a patch against the CVS for the spec files and ancillary files, that we could directly apply: http://cvs.fedoraproject.org/viewcvs/rpms/pilot-link/F-8/ Instructions for anonymous checkout of CVS are here: https://fedoraproject.org/wiki/UsingCvs You'd just make your changes and then run: cvs diff -u > krp.patch and post the patch as an attachment here. (Since you have a fairly detailed understanding of the pilot-link internals, iff you were interested in becoming a Fedora contributor, you could also sign up as a package co-maintainer!) My understanding of the situation at the moment is that once the HAL changes to now on bug #434960 are applied, then the only change required to the current 0.12.2-18 version of the package is the fix to the 19-pam-acl-management.fdi file? While we await the HAL update (since it's been waiting for about 2 weeks with not much response from the HAL maintainer) might it be useful to push a version of pilot-link that contains the extra file, and the remove just as the new HAL gets pushed? That way things would start working out of the box (at least as root) for most users.
(In reply to comment #128) > Hi Kevin, > > Thanks for all of your work on this! I finally upgraded to F-8 on mylaptop, so > I now have a chance to test your fixes. > > As per comment #113, I can successfully connect as root, but not as a regular > user. Details are for a Palm Treo 680: > > lsusb output (don't know why it says "Palm Zire 31" when it's really a Treo, but > anyhow): Gah! Quick update: I had originally copied the 10-usb-pda-palm.fdi file into /usr/share/hal/fdi/policy/20thirdparty rather than /usr/share/hal/fdi/information/20thirdparty ! Now that I fixed it and it *works* as a regular user! Now I'd really like to get this package updated! Ivana: what's left to do in terms of pushing Kevin's updates? I saw that you mention that you didn't want to push an update until bug #431377 was fixed. But that was over 3 weeks ago, do you know what the status of that is currently? Is it still a problem? Kevin: I can create a scratch koji build that others can test in the meantime if Ivana decides we aren't quite ready for a new package in updates-testing. Thanks all.
Alex: I've pushed all the changes upstream; there's currently a release candidate of hal 0.5.11 which has the patches included. When this, and the corresponding hal-info, are released (probably within the next week), pilot-link won't need to ship any additional files (i.e. 19-pam-acl-management.fdi and can be dropped from pilot-link), and the other hal bugs this is dependent on will have been fixed. I've created bug #437310 track this for F9. I don't know whether hal-0.5.11 will be shipped for F8, and whether it's worth waiting for (or including the comment #110 patches in the meanwhile). I'll probably be off-net for the rest of the week, unfortunately.
Fedora 9 will work: I ran the F9 beta, updated hal and hal-info from rawhide and grabbed pilot-link-0.12.3-13.fc9 from koji - it all works fine. Job done. The path forward for Fedora 8 all depends upon whether hal-0.5.11 and an accompanying hal-info release will be packaged for F8. If they are, we can drop the hal configs from pilot-link (as has been done for F9), dependency bug #435093 will be cleared and, afaict from the beta, so will bug #431377. If there's not going to be a hal update for F8, then we'll have to craft some config for pilot-link that whichever hal/hal-info version is in current F8. Perhaps if not hal, at least a hal-info update could be pushed? (I notice that one was created to aid some recent F8 NetworkManager changes). Bug #435093 can be worked around (at bit ugly, but...), though I don't see what we can do to avoid bug #431377. hal-0.5.11 is still a release candidate, so a new package may drop out once it's released. Or perhaps Fedora policy will be to stay with 0.5.10 for F8? If anyone's in direct communication with the hal maintainers, it'd be good to know either way! Once we know what'll be going down with hal I'll gladly re-jig any config files that may be needed for the pilot-link package.
(In reply to comment #131) > The path forward for Fedora 8 all depends upon whether hal-0.5.11 and an > accompanying hal-info release will be packaged for F8. There is a hal-info in updates-testing, not sure if it fixes the issues here though: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2352 > If they are, we can drop the hal configs from pilot-link (as has been done for F9), dependency > bug #435093 will be cleared and, afaict from the beta, so will bug #431377. Perhaps you could open up a hal bug requesting an update to 0.5.11 (or at least backporting the relevant changes to 0.5.10) and make this bug depend on that bug. I'll happily chime in and second such an update. pilot-link really needs to be fixed on F-8 as it does turn users off Fedora, see for example a recent post on: http://www.redhat.com/archives/fedora-devel-list/2008-March/msg01932.html (which although not very specific about the exact problem does mention Palm synchronization) > If there's not going to be a hal update for F8, then we'll have to craft some > config for pilot-link that whichever hal/hal-info version is in current F8. > Perhaps if not hal, at least a hal-info update could be pushed? (I notice that > one was created to aid some recent F8 NetworkManager changes). Bug #435093 can > be worked around (at bit ugly, but...), though I don't see what we can do to > avoid bug #431377. > > hal-0.5.11 is still a release candidate, so a new package may drop out once it's > released. Or perhaps Fedora policy will be to stay with 0.5.10 for F8? If > anyone's in direct communication with the hal maintainers, it'd be good to know either way! HAL updates have been pushed during a release cycle before to fix bugs such as these, so I see no reason that this would be any different.
(In reply to comment #132) > There is a hal-info in updates-testing, not sure if it fixes the issues here Unfortunately not; it's just a fix for an earlier pull of upstream. We could really do with a fresh release of hal, too. > Perhaps you could open up a hal bug requesting an update to 0.5.11 I've updated bug #434960 (and bugs #435093 #431377) - though these have all been without reply for a month or more. I wondered if there was any other Fedora mechanism we might get a status update on hal through - I asked for advice about this bug on fedora-devel a month ago, but didn't get any help on the hal side of things. There may be good reasons a hal/hal-info update won't be pushed for F8; it's the not knowing that's the issue...
*** Bug 435266 has been marked as a duplicate of this bug. ***
Given that everything should be working using libusb in Fedora 9, and having just seen the tale of a confused user in bug #435266, perhaps we should defend against the inevitable upset blacklisting visor by default could cause. i.e. we should get something in the Fedora 9 Release Notes documenting the change (to using "-p usb:" from the old /dev/pilot / /dev/ttyUSBx) and referencing README.Fedora for any problems. Considering the F9 release schedule, I guess this needs to happen very very soon. How do we go about this? Alex? Ivana?
Good idea - I'm discussing it with release notes team.
(In reply to comment #135) > Given that everything should be working using libusb in Fedora 9, and having > just seen the tale of a confused user in bug #435266, perhaps we should defend > against the inevitable upset blacklisting visor by default could cause. > > i.e. we should get something in the Fedora 9 Release Notes documenting the > change (to using "-p usb:" from the old /dev/pilot / /dev/ttyUSBx) and > referencing README.Fedora for any problems. Looks like you can contribute here: http://fedoraproject.org/wiki/Docs/Beats/HowTo although I've never done so. > Considering the F9 release schedule, I guess this needs to happen very very > soon. How do we go about this? Alex? Ivana? I've Cc'ed the release notes team: relnotes on this bug and marked the fedora_requires_release_note flag as per instructions above. If you could e-mail them directly about the issues as per that Howto that would also be great.
Also, we should really push the hal maintainer to push out a new hal for so we can finally fix this bug in F-8 too. Ivana: could you possibly bug the hal maintainer again? He hasn't been very responsive recntly regarding Kevin's exhaustive bug reports.
visor was already blacklisted in Fedora 8. Not that I'm necessarily against documenting it in the Fedora 9 release notes, since apparently it slipped by last time, but it's not actually a Fedora 9 change.
And if he remains unresponsive and/or doesn't want to push an F-8 update of hal to 0.5.11, we should go with plan B: putting the changes into the pilot-link directly as per comment #133. This bug now has 139 comments, now that we know exactly what the problem is and how to fix it (hopefully!) we need to close this bug.
(In reply to comment #139) > visor was already blacklisted in Fedora 8. Not that I'm necessarily against > documenting it in the Fedora 9 release notes, since apparently it slipped by > last time, but it's not actually a Fedora 9 change. But the pilot-link package never really worked properly out of the box in F-8 (hence this bug) and it was never mentioned in F-8 release notes. Also many people went back to using the visor module method pending the various hal issues described here, so I think it would be worth mentioning now that we seem to have ironed out the issue once and for all.
I have to agree, this has caused, and continues to cause, untold grief for Palm/Sony/Handspring/etc. device users and has been broken in one way or another since the introduction of dynamic device nodes, hal et al. It's long past time that there was something solid and explanatory there to tell them how to get it to work without all that trouble and effort.
(In reply to comment #139) > visor was already blacklisted in Fedora 8. It was blacklisted in a Fedora 8 _update_, as far as I recall. visor via udev never worked out of the box for F8; it was hoped those configuring by hand could deal with the blacklisting. As Alex says, a release note opens a nice fresh page in the book, so to speak, and lets people know we've finally got it sorted. Ivana: if something needs writing up and mailing to releng@, let me know - though it shouldn't need more than a quick paragraph.
Alex - regarding the comment #138 I'm trying to get some attention of davidz to this issue - I try to contact him again at the end of previous week so I hope I will be more successful this time. Kevin - regarding #143 - for now I'm still trying to contact release notes team - but unsuccessfully - I hope will discuss this issue with them today.
(In reply to comment #144) > Alex - regarding the comment #138 I'm trying to get some attention of davidz to > this issue - I try to contact him again at the end of previous week so I hope I > will be more successful this time. Great thanks! > Kevin - regarding #143 - for now I'm still trying to contact release notes team > - but unsuccessfully - I hope will discuss this issue with them today. Why not just edit the Beats directly on the wiki rather than waiting to discuss them? It says on http://fedoraproject.org/wiki/Docs/Beats/HowTo that the number one best way to contribute is to edit directly: "Edit the content directly within the appropriate beat at Docs/Beats, using the same directions." Furthermore as far as editing goes, it also says: "Don't worry. Competent writers and editors are watching your contributions. We'll follow up with your contribution directly in the Wiki, cleaning, simplifying, formatting, and so forth. " if somebody can post some suggested text here, I'll happily contribute them (and take the grief etc. for it).
In reply to comment #145 -- yes, editing directly works great. Docs/Beats/Desktop seems like the best fit, yes? FYI, we do a web update of the release notes to coincide with the release, and that update page is linked from the top of all the release notes pages to make it abundantly clear the web-based notes are always the latest. When you've written the content to the wiki, go ahead and remove the fedora_requires_release_note flag, thanks.
I just edit release notes text: http://fedoraproject.org/wiki/Docs/Beats/PackageNotes If there is any problem please write a comment. Thanks.
Thanks Ivana; sorry I've only just caught up with this. I suggest we explicitly mention using usb:... How about: " The pilot-link package now blacklists the visor module by default. Users are encouraged to try the libusb functionality included in recent versions of pilot-link. This is enabled by passing the "--port usb:" option instead of the serial devices used in the past (typically /dev/pilot or /dev/ttyUSB0). For example: pilot-xfer --port usb: --list HAL and PolicyKit have been updated to correctly set permissions for the necessary USB devices. If you have any existing manual configuration please ensure it is reverted to avoid possible conflicts. For further information see README.fedora, included in the pilot-link package. " README.fedora includes a reference to this bug, which I think is sufficient. Alex: I think I've jumped through the necessary hoops; I'm mailing you a request to be added to the wiki EditGroup.
Hello Kevin, thanks :). My opinion is: libusb support is in pilot link since FC7 so I don't know whether it is relevant to write it to release notes now it could be mentioned there but I prefer to have it at the end. The reason why I 'd like to do a note to release notes is that the visor module is blacklisted and the configuration uses hal/policy kit now. So I suggest to remove libusb part or put it at the end of text.
Ivana: I agree that from a user perspective the main change they're likely to encounter (perhaps unknowingly) is the blacklisting, so it's important to mention it first. However, after the initial "what's changed?" question, the next thing a user thinks is "and what should I do about it?". This second answer is to use the libusb port options - and given that we're also trying to alert users who may have given up with pilot-link on Fedora, it's important we tell them what they should do differently (if they do what they used to - using /dev/pilot - it still won't work). I realise libusb has been built in since F7 (that's why I say "recent verions"), but there was no previous *need* to use it whereas now there is - this very bug started from using the old visor method on F7! We switched to using libusb to work *around* these problems. The HAL/PolicyKit configuration is secondary and "under the hood"; while it's essential to enable smooth use of pilot-link/libusb, a user doesn't need to know the full details *unless* they've previously manually changed the configuration in a way that might clash (perhaps while working around the broken config in previous releases). I think it's important to come at the release notes from a user perspective (mention -p usb: ), and to cover the most common problem we've encountered with the new setup in this bug (mis-configuration). I also suspect these will be the most likely source of new bugs (see bug #435266 which prompted the Release Note discussion), so best to head them off at the pass ;) In summary, I've structured my suggested release note as: 1) what's changed 2) what to do about it 3) what might go wrong and where to get help Putting the libusb bit at the end would swap the order to 1,3,2 - which I don't think reads as clearly. I agree libusb is too opaque a term - I've changed it below to "direct USB access". If someone in the wiki EditGroup could add me (krp/KevinPage), that would be useful - thanks! " The pilot-link package now blacklists the visor module by default. Users are encouraged to try the direct USB access present in recent versions of pilot-link. This is enabled by passing the "--port usb:" option instead of the serial devices used in the past (typically /dev/pilot or /dev/ttyUSB0). For example: pilot-xfer --port usb: --list HAL and PolicyKit have been updated to correctly set permissions for the necessary USB devices. If you have any existing manual configuration please ensure it is reverted to avoid possible conflicts. For further information see README.fedora included in the pilot-link package. "
Oh, and remember the HAL/PolicyKit configuration changes aren't part of the pilot-link package at all for F9. They come from hal and hal-info via the changes I pushed upstream. So the HAL/PolicyKit bit technically isn't a change in the pilot-link package!
OK - you are right this version could be more useful for palm users then the first one - thanks for your help.
Pleased to confirm that everything is working as it should in the F9 Preview Release.
*** Bug 443189 has been marked as a duplicate of this bug. ***
OK, it looks like we're unlikely to get an update of hal to 0.5.11, and since we've had zero response from David Zeuthen on this matter, I suggest we update the package to workaround the missing hal files and put them in pilot-link as Kevin suggested in comment #131 and close this bug!! We can deal with removing them from pilot-link if at some point hal on F-8 is update, but that seems very unlikely at this stage, especially as focus shifts to F-9 and the new rawhide/F-10 very soon. So let's just fix this for F-8 and move on.
Can I please have a status update for Fedora 8. I'm up to date with hal-0.5.10-1.fc8.2 pilot-link-0.12.2-18.fc8 That pilot-link supplies this: /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi which does not match the one proposed in message #110 of this thread, and there is no corresponding package in the RPM to match the proposed file: /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi Should I install/replace those files with the fdi files attached in this thread? I'm trying to help my friend, who is a new convert to Linux, use his Palm LifeDrive. I don't have a Palm device, so I have no experience, and this problem/thread is not helping me figure which end is up. Thanks in advance, pj
(In reply to comment #156) > Can I please have a status update for Fedora 8. I'm up to date with > hal-0.5.10-1.fc8.2 > pilot-link-0.12.2-18.fc8 Hey Paul, Unfortunately this would just work out of the box if hal was updated to 0.5.11 on F-8, but no word from the hal maintainer that he's going to do that. So currently hal doesn't contain the right fixes, so they have to be either carried in the pilot-link package (which isn't done as yet because we were hoping for a new hal), or added manually which is what comment #110 and comment #113 were about. > That pilot-link supplies this: > > /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi > > which does not match the one proposed in message #110 of this thread, and there > is no corresponding package in the RPM to match the proposed file: > > /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi > > Should I install/replace those files with the fdi files attached in this thread? Yes, you need to replace those files with the ones attached here. I also had to modify: /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi > I'm trying to help my friend, who is a new convert to Linux, use his Palm > LifeDrive. I don't have a Palm device, so I have no experience, and this > problem/thread is not helping me figure which end is up. Hopefully Kevin Page can correct me if I'm wrong, but I did manage to get things to work once I followed those comments to the letter. I think we just need to assume that hal won't be updated on F-8 and put the right fixes in pilot-link directly.
(In reply to comment #157) > Hopefully Kevin Page can correct me if I'm wrong, but I did manage to get things > to work once I followed those comments to the letter. Yes, as Alex says, users wishing to workaround current HAL/PolicyKit problems should still follow comment #119 (and thereby comment #110, and if necessary comment #113). Bear in mind that you may need to undo these manual changes when a fix is supplied within the pilot-link package (or hal/hal-info). N.B. Make sure you put the replacement configs in *exactly* the right places. > I think we just need to assume that hal won't be updated on F-8 and put the > right fixes in pilot-link directly. I'll refactor the upstream patches to workaround bug #435093. Hopefully in the next day or so.
Created attachment 306554 [details] patch updating hal config to match upstream hal Alex: try this - sorry for the delay. Patched against a CVS checkout of the pilot-link package. It works for me (after a reboot/haldaemon restart) but I've only tested it a couple of times(!). I'm offline until Tuesday, so I'll look at any problems then.
(In reply to comment #159) > Created an attachment (id=306554) [edit] > patch updating hal config to match upstream hal > > Alex: try this - sorry for the delay. Patched against a CVS checkout of the > pilot-link package. > > It works for me (after a reboot/haldaemon restart) but I've only tested it a > couple of times(!). I'm offline until Tuesday, so I'll look at any problems > then. Hey Kevin, Do you happen to know if the hal-info-20080215-2.fc8 currently in updates-testing: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2352 includes the fix to the FDI files that you included in this patch? If so, we could karma up the update and get it pushed to stable and avoid having to patch pilot-link.
No, not based on build date and version name - and I'm pretty certain that's the same update I checked out in comment #133 queued up since then. We'd need a hal-info from at least 20080226, and even with that we'd need to ship some config in pilot-link unless we get an update of the main hal package to 0.5.11.
(In reply to comment #161) > No, not based on build date and version name - and I'm pretty certain that's the > same update I checked out in comment #133 queued up since then. We'd need a > hal-info from at least 20080226, and even with that we'd need to ship some > config in pilot-link unless we get an update of the main hal package to 0.5.11. OK, I'm going to commit this now as this bug has been open far too long and it looks unlikely that we'll get the hal update any time soon. I'll first do a scratch build and post the URL to the scratch build here for Kevin (and others) to test. If that all works out, I'll submit an official build for updates-testing.
By the way, the .spec file changes looked fine to me. RPMs can be accessed from the koji scratch build here (click on the Descendent Task for your particular arch) to access the actual RPM: http://koji.fedoraproject.org/koji/taskinfo?taskID=632388 Kevin: can you test them? (I'll also check on my F-8 laptop when I get home).
(In reply to comment #163) > Kevin: can you test them? The i386 build works for me.
Created attachment 308517 [details] Fix visor module fallback config and documentation re: working libusb/PolicyKit config, we're playing the waiting game again - it looks like we *might* get an errata release of hal/hal-info via bug #435093. Alex, Ivana, how long do you want to wait this time? I linked to patched on Monday. (Perhaps you could contact Richard directly to find out his plans?) Meanwhile the earlier change in usb.ids broke our fallback config for using the visor module. Attached is a patch to correct this (by removing 60-pilot.rules in favour of the upstream config with instructions to modify for Fedora). I don't know whether this warrants a release, but several users have been confused by this since the release of F9: https://www.redhat.com/archives/fedora-list/2008-May/msg01990.html https://www.redhat.com/archives/fedora-list/2008-June/msg00456.html http://lists.pilot-link.org/pipermail/pilot-link-general/2008-May/003351.html http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html
By the way, did the koji scratch build work for others?
(In reply to comment #165) > Created an attachment (id=308517) [edit] > Fix visor module fallback config and documentation > > re: working libusb/PolicyKit config, we're playing the waiting game again - it > looks like we *might* get an errata release of hal/hal-info via bug #435093. > Alex, Ivana, how long do you want to wait this time? I linked to patched on > Monday. (Perhaps you could contact Richard directly to find out his plans?) I think we've waited far too long already. I say unless the new version of hal-info-20080607-1.fc8 that appears to be in updates-testing now: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-5137 fixes the above problems, we should push this ASAP (after fixing the fallback configs). Otherwise we may be waiting forever. Why the hal maintainer didn't include the pilot-link fix which has been an issue for several months now at the same time is beyond me. They appear to not be very interested in pilot-link issues despite Kevin's copious work on this.
(In reply to comment #165) > Created an attachment (id=308517) [edit] > Fix visor module fallback config and documentation > Meanwhile the earlier change in usb.ids broke our fallback config for using the > visor module. Attached is a patch to correct this (by removing 60-pilot.rules > in favour of the upstream config with instructions to modify for Fedora). > > I don't know whether this warrants a release, but several users have been > confused by this since the release of F9: > https://www.redhat.com/archives/fedora-list/2008-May/msg01990.html > https://www.redhat.com/archives/fedora-list/2008-June/msg00456.html > http://lists.pilot-link.org/pipermail/pilot-link-general/2008-May/003351.html > http://lists.pilot-link.org/pipermail/pilot-link-general/2008-June/003374.html Is this patch against the current F-8 or F-9 branch of pilot-link? Also, does it need to be applied to all branches (i.e. including rawhide/devel)?
(In reply to comment #167) > I think we've waited far too long already. I say unless the new version of > hal-info-20080607-1.fc8 that appears to be in updates-testing now Ah, I hadn't seen that. The hal-info update pulls from git, so obsoletes the scratch build of pilot-link with my patch (or at least part of it). You should revert that patch. There's also a patch to fix the int_outof bug in hal, though no updated policy files (as hal didn't get bumped to the newer version, it's just an errata patch). So, if there aren't any more hal/hal-info updates, we'd need to carry the policy in pilot-link, i.e. option 2) in bug #435093 comment #4. I can cook up a new patch for pilot-link to do this, but if anyone has more effective communication with the hal packagers than bz (I'm not on IRC) it'd be nice to know they aren't going to carry the policy patches there before I waste any time on a patch. (In reply to comment #168) > Is this patch against the current F-8 or F-9 branch of pilot-link? Both. It should have applied against the CVS checkout to both F-8 and F-9. Do you prefer this kind of duplication, or a single patch to apply twice? Obviously if I make a patch for policy files I'll roll this in too. > Also, does it need to be applied to all branches (i.e. including > rawhide/devel)? Ooops, yeah, should've included rawhide.
Created attachment 309418 [details] Patch to fix config and docs in pilot-link I've heard nothing from the hal packagers in the last week (has anyone else?) so I presume we won't be seeing anything beyond the hal-info-20080607-1.fc8 and hal-0.5.10-2.fc8 in F8 updates-testing. I think we should, therefore, try to get a pilot-link into updates-testing that will work in conjunction with these pending hal/hal-info updates. This patch does so; it should apply against the current (20080615) Fedora CVS checkout of pilot-link and: - removes config duplicated in hal-info-20080607-1.fc8 - fixes documentation for visor fallback in F-8, F-9, and devel Alex: this supersedes my last (visor doc) patch, but builds upon the one you applied (i.e. don't revert that one ;) ) On a practical note I've now upgraded my main laptop to F9, so it'll more of a pain to test patches for F8. I have, however, tested this one! Obviously you need the hal and hal-info from F8 updates-testing for it to work.
(*sigh*) More lack of maintainer communication: Richard Hughes obsoleted the existing updates-testing update https://admin.fedoraproject.org/updates/F8/FEDORA-2008-5137 by pushing a new update for hal: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-5380 but crucially, didn't also append the hal-info build, effectively obsoleting the hal-info update at the same time. I'll note this on bug #244995 (which was the whole reason for updating hal again).
Ok, so Richard confirms in bug #244995 that we'll get a rebuild of hal-info. Can we have a scratch build ready to push to updates-testing when that happens? (people can still get the obsoleted hal-info to test with from koji if they like) hal-info has a date derived version. Could/should a Requires: hal-info >= 20080227 be added to the F-8 pilot-link spec file?
I'm leaving for a conference tomorrow but I'll have sporadic Internet access for about a week. If the hal-info build gets pushed soon, I'll apply the latest patch and do at least a scratch build. As for the Requires, that probably isn't necessary since it is (or should be) a transient issue and it shouldn't be necessary to maintain that in the .spec file for very long.
(In reply to comment #173) > I'll have sporadic Internet access for > about a week. If the hal-info build gets pushed soon, I'll apply the latest > patch and do at least a scratch build. Alex, appreciate you may be offline - so don't know if you saw that the requisite hal and hal-info builds went into updates-testing on Friday. So we're good to get a patched pilot-link in there too...?
Could my last patch be applied? Please? ;) For F8, at least people could test in conjunction with the hal and hal-info in updates-testing. I don't expect there to be any problems. I don't think we need to wait for anything else from hal/hal-info. Also a reminder that it fixes documentation for both F8 and F9 which is actively causing confusion for users and pilot-link maintainers (see the links in comment #165 ...and another thread has just sprung up on pilot-link-general). Fedora enabling libusb by default has foisted this code upon a much larger user base (for the better, IMHO); this has, as one might expect, exposed some compatibility regressions. Getting to the root of these problems would be much easier if we put our packages in order, because at the moment the first suspicion is - not without basis - broken Fedora config/docs/packaging.
(In reply to comment #175) > Could my last patch be applied? Please? ;) I'm back now. Looking at patch. The devel branch removed the 60-pilot.rules file, was this intended? > For F8, at least people could test in conjunction with the hal and hal-info in > updates-testing. I don't expect there to be any problems. I don't think we need > to wait for anything else from hal/hal-info. > Also a reminder that it fixes documentation for both F8 and F9 which is actively > causing confusion for users and pilot-link maintainers (see the links in comment > #165 ...and another thread has just sprung up on pilot-link-general). > > Fedora enabling libusb by default has foisted this code upon a much larger user > base (for the better, IMHO); this has, as one might expect, exposed some > compatibility regressions. Getting to the root of these problems would be much > easier if we put our packages in order, because at the moment the first > suspicion is - not without basis - broken Fedora config/docs/packaging. Agreed.
(In reply to comment #176) > I'm back now. Looking at patch. The devel branch removed the 60-pilot.rules > file, was this intended? Yes, the patch should remove it from all branches (see comment #165). I guess it was put there to do a better job than the 60-libpisock.rules from upstream, but following recent changes it actually does a worse job (and if you follow the instructions in the current release RPM and use it as provided, will fail to work. Nice.). Instead, the patch updates the README.Fedora with instructions on how to modify the upstream provided 60-libpisock.rules - which is shipped in the RPM - to make it work with Fedora. This also means that should users need to report problems upstream they're more familiar with what they've done, which is closer to what upstream expect, and less likely to confound upstream with different-for-no-reason Fedora configs.
OK, I checked the patch and it looks OK and applied to all branches. The rawhide and F-9 builds simply changed the README.fedora and removed 60-pilot.rules in preference to upstream's 60-libpisock.rules which you would only need if you wanted to drop back to visor module. rawhide build: http://koji.fedoraproject.org/koji/buildinfo?buildID=54924 F-9 build: http://koji.fedoraproject.org/koji/buildinfo?buildID=54925 (I'll push the F-9 build to updates-testing after Kevin tests it locally) F-8 (scratch build for the moment): http://koji.fedoraproject.org/koji/taskinfo?taskID=698672 (Kevin please test again and I'll try to test as well, then I'll push to updates-testing. I assume this won't be able to pushed to stable until the hal-info in updates-testing is also pushed?)
(In reply to comment #178) > Kevin please test again and I'll try to test as well, then I'll push to > updates-testing. I've tested both the F9 update and the F8 scratch build - both are fine. You might also want to take a look at the patch in bug #454178, depending on whether you think it best to push less updates, or less changes at once. > I assume this won't be able to pushed to stable until the > hal-info in updates-testing is also pushed? That's certainly desirable, though pushing the updated pilot-link without hal/hal-info won't do any harm, it just won't work until they land (the net result being no different to the current update, which also doesn't work). Is there a way to declare this dependency in koji? Otherwise, would I be right in thinking that as soon as a package gets the requisite karma in updates-testing it'll be pushed to stable? The hal and hal-info should get there first as they're starting with more karma. Once pushed to updates-testing I'd hope the F8 users on this bug could test hal+hal-info+pilot-link and give the appropriate karma. Bug #452701 concerns me. Will the negative karma block the hal-info push? I can't reproduce the crash - it seems hardware specific - and the reporter hasn't responded. Experience tells me that waiting on hal bugfixes is a bad place to be. I suppose more widespread testing will help pin it down.
(In reply to comment #179) > I've tested both the F9 update and the F8 scratch build - both are fine. > > You might also want to take a look at the patch in bug #454178, depending on > whether you think it best to push less updates, or less changes at once. Maybe make that a second update. > > > I assume this won't be able to pushed to stable until the > > hal-info in updates-testing is also pushed? > > That's certainly desirable, though pushing the updated pilot-link without > hal/hal-info won't do any harm, it just won't work until they land (the net > result being no different to the current update, which also doesn't work). > > Is there a way to declare this dependency in koji? Not really, I'll probably just make sure that the appropriate hal-info is already pushed before pushing pilot-link to stable, or manually withdraw it if appropriate hal-info won't be pushed simultaneously. > Otherwise, would I be right in thinking that as soon as a package gets the > requisite karma in updates-testing it'll be pushed to stable? The hal and > hal-info should get there first as they're starting with more karma. Right. > Once pushed to updates-testing I'd hope the F8 users on this bug could test > hal+hal-info+pilot-link and give the appropriate karma. That would be the plan, yes. > Bug #452701 concerns me. Will the negative karma block the hal-info push? I > can't reproduce the crash - it seems hardware specific - and the reporter hasn't > responded. Experience tells me that waiting on hal bugfixes is a bad place to > be. I suppose more widespread testing will help pin it down. Yep, it concerns me, I can definitely reproduce the hal crash, so I had to -1 karma points, also as I point out on bug #452701 comment #5 hal-info-20080607-2.fc8 doesn't appear to contain the 10-usb-pda-palm.fdi file in any case, which was the whole point of the update (at least from the point of view of pilot-link users). Perhaps we should think about reintroducing it back into the pilot-link package if the hal problems persist so we can at least get this out.
OK, I made a mistake, I hadn't also updated hal and the old contents of 10-usb-pda-palm.fdi appear to have been merged into: /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi is that correct Kevin? I'll switch my karma to +1
(In reply to comment #181) > the old contents of 10-usb-pda-palm.fdi appear to have been merged into: > /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi > is that correct Kevin? Yes, that was where I merged the contents upstream (comment #111 ;) )
Now tested the scratch build along with new hal/hal-info and appears to work for me too. Preparing a real update to "updates-testing" now. Since we have no reponse from David Zeuthen, returning bug to ASSIGNED.
pilot-link-0.12.2-21.fc8 has been submitted as an update for Fedora 8
pilot-link-0.12.2-21.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pilot-link'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-6277
For those still running F8, please could you test the pilot-link package in updates-testing and leave feedback (see comment #185) - we believe the package should close this bug. I've removed the dependencies I added on bug #431377 and bug #452701 - hal/hal-info updates have been released despite these.
For those of us with a working Fedora 8 system from comment #110, what do we need to do to test the new pilot-link package in updates-testing? I've done a full system update, then installed the new pilot-link package and it works, but it did before. :) Thanks for the hard work.
(In reply to comment #187) > For those of us with a working Fedora 8 system from comment #110, what do we > need to do to test the new pilot-link package in updates-testing? Before updating pilot-link from updates testing, remove any manual changes. e.g. if you'd followed comment #110, remove: /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi /usr/share/hal/fdi/information/20thirdparty/10-usb-pda-palm.fdi It *should* also be safe to remove those files after installing the updated pilot-link (but definitely safest to do beforehand) - but only because of a typo (19-pam-acl... is superseded by 19-palm-acl...). Double-check the above files aren't owned by a package before you delete them with: rpm -qf <filename> If not owned by a package it's a reasonable assumption they were handmade changes.
(In reply to comment #186) > For those still running F8, please could you test the pilot-link package in > updates-testing and leave feedback (see comment #185) - we believe the package > should close this bug. Kevin, I'm not on the pilot-link list, but if you are, could you request that any Fedora users there test the F-8 package provide feedback via bodhi? That way we can good feedback which wll hopefully progress us towards stable. If we don't hear any negative feedback in the next week or so, I may just push it to stable manually. (In reply to comment #187) > For those of us with a working Fedora 8 system from comment #110, what do we > need to do to test the new pilot-link package in updates-testing? > > I've done a full system update, then installed the new pilot-link package and it > works, but it did before. :) Andrew if it works for you, please give the package a +1 karma via bohdi: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-6277 That goes for anybody else on this bug who is still running F-8 and pilot-link... ;)
pilot-link-0.12.2-21.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Finally closing this bug. Hooray! Please open up a new bug if you have a problem with this update as this bug has 191 comments already and many are unrelated issues.