Bug 280251 - pilot-link configuration is incomplete
Summary: pilot-link configuration is incomplete
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: pilot-link
Version: 8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 435266 443189 (view as bug list)
Depends On: 411321 431377 432644 434960
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-06 10:31 UTC by Brian Morrison
Modified: 2013-03-06 03:54 UTC (History)
21 users (show)

Fixed In Version: 0.12.2-21.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-18 08:48:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
README.Fedora for pilot-link package (1.74 KB, text/plain)
2007-12-11 18:14 UTC, Kevin R. Page
no flags Details
Fixed .fdi file (9.52 KB, text/xml)
2008-02-06 13:45 UTC, Gustavo Maciel Dias Vieira
no flags Details
.fdi file containing information about PalmOS handhelds (12.64 KB, text/plain)
2008-02-10 22:51 UTC, Kevin R. Page
no flags Details
Replacement /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi (476 bytes, text/plain)
2008-02-10 22:55 UTC, Kevin R. Page
no flags Details
Original Fedora8 policy file currently installed. (546 bytes, text/plain)
2008-02-25 15:20 UTC, Steve Baker
no flags Details
patch updating hal config to match upstream hal (30.77 KB, patch)
2008-05-23 23:22 UTC, Kevin R. Page
no flags Details | Diff
Fix visor module fallback config and documentation (6.83 KB, patch)
2008-06-06 08:21 UTC, Kevin R. Page
no flags Details | Diff
Patch to fix config and docs in pilot-link (27.11 KB, patch)
2008-06-15 21:51 UTC, Kevin R. Page
no flags Details | Diff

Description Brian Morrison 2007-09-06 10:31:27 UTC
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:

Comment 1 Brian Morrison 2007-09-19 09:52:56 UTC
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.




Comment 2 Ivana Varekova 2007-09-24 13:29:23 UTC

*** This bug has been marked as a duplicate of 158809 ***

Comment 4 Alex Lancaster 2007-09-24 14:48:35 UTC
(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.

Comment 5 Ivana Varekova 2007-09-24 14:58:12 UTC
Thanks for your comments, perhaps I will look to this bug more closer - asap,
for now I will reopen it.

Comment 6 Orion Poplawski 2007-10-08 22:56:19 UTC
Status update?

Comment 7 Kevin R. Page 2007-11-22 22:45:59 UTC
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.

Comment 8 Alex Lancaster 2007-11-23 09:40:11 UTC
(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.

Comment 9 Alex Lancaster 2007-11-23 09:43:31 UTC
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"

Comment 10 Kevin R. Page 2007-11-23 13:18:05 UTC
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).


Comment 11 Kevin R. Page 2007-11-23 16:55:54 UTC
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.

Comment 12 Alex Lancaster 2007-11-27 09:37:33 UTC
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.

Comment 13 Ivana Varekova 2007-11-27 09:51:26 UTC
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.


Comment 14 Alex Lancaster 2007-11-27 10:01:39 UTC
(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.



Comment 15 Kevin R. Page 2007-11-27 13:05:58 UTC
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).

Comment 16 Alex Lancaster 2007-11-27 13:28:43 UTC
(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.

Comment 17 Harald Hoyer 2007-11-29 12:40:54 UTC
Here is a solution for Fedora 8

http://www.harald-hoyer.de/linux/console_acls_for_palm

Comment 18 Ivana Varekova 2007-11-30 08:46:29 UTC
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.

Comment 19 Fedora Update System 2007-12-03 11:46:08 UTC
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'

Comment 20 Orion Poplawski 2007-12-03 17:13:27 UTC
Can we get a test version for F7?  Thanks...


Comment 21 Alex Lancaster 2007-12-04 02:49:44 UTC
(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.




Comment 22 Kevin R. Page 2007-12-04 17:45:19 UTC
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?

Comment 23 Kevin R. Page 2007-12-05 23:26:59 UTC
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).

Comment 24 Alex Lancaster 2007-12-06 04:51:30 UTC
(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.


Comment 25 Alex Lancaster 2007-12-06 05:04:03 UTC
(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.

Comment 26 Alex Lancaster 2007-12-06 05:08:01 UTC
(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).

Comment 27 Kevin R. Page 2007-12-06 09:18:05 UTC
(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.

Comment 28 Ivana Varekova 2007-12-06 11:15:01 UTC
Fixed in pilot-link-0.12.2-10.

Comment 29 Fedora Update System 2007-12-06 22:52:45 UTC
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'

Comment 30 Kevin R. Page 2007-12-11 18:14:10 UTC
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.

Comment 31 Joshua Rosen 2007-12-11 22:53:23 UTC
F7 and F8 still aren't working. Has anything been checked into the regular
update repositories?

Comment 32 Kevin R. Page 2007-12-12 09:05:50 UTC
(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.

Comment 33 Alex Lancaster 2007-12-12 15:23:47 UTC
(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?

Comment 34 Kevin R. Page 2007-12-12 17:12:06 UTC
(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?

Comment 35 Alex Lancaster 2008-01-04 10:34:35 UTC
(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.

Comment 36 Kevin R. Page 2008-01-07 09:46:49 UTC
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.

Comment 37 Alex Lancaster 2008-01-07 10:02:57 UTC
(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.

Comment 38 Alex Lancaster 2008-01-07 10:15:48 UTC
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.

Comment 39 Kevin R. Page 2008-01-07 10:19:35 UTC
(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.

Comment 40 Alex Lancaster 2008-01-07 10:44:29 UTC
(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.


Comment 41 Kevin R. Page 2008-01-07 18:03:35 UTC
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!

Comment 42 David Zeuthen 2008-01-07 19:22:37 UTC
> /sbin/service haldaemon condrestart

No, no, no. You shall not under any cimcumstances restart the hal daemon.


Comment 43 Kevin R. Page 2008-01-07 19:50:31 UTC
(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)


Comment 44 David Zeuthen 2008-01-07 20:08:06 UTC
(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.




Comment 45 Alex Lancaster 2008-01-07 23:00:05 UTC
(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



Comment 46 David Zeuthen 2008-01-07 23:08:28 UTC
(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.


Comment 47 Alex Lancaster 2008-01-07 23:38:23 UTC
(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"?


Comment 48 David Zeuthen 2008-01-07 23:51:26 UTC
(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.)


Comment 49 Alex Lancaster 2008-01-08 00:04:05 UTC
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)

Comment 50 Alex Lancaster 2008-01-09 09:14:40 UTC
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


Comment 51 Ivana Varekova 2008-01-10 15:00:17 UTC
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 

Comment 52 Alex Lancaster 2008-01-10 15:09:10 UTC
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



Comment 53 Brian Morrison 2008-01-10 15:11:23 UTC
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.


Comment 54 Alex Lancaster 2008-01-10 15:29:44 UTC
(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

Comment 55 Alex Lancaster 2008-01-10 15:32:03 UTC
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.

Comment 56 Brian Morrison 2008-01-10 15:41:24 UTC
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.


Comment 57 Ivana Varekova 2008-01-10 15:49:39 UTC
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. 

Comment 58 Gustavo Maciel Dias Vieira 2008-01-11 01:21:56 UTC
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.


Comment 59 Ivana Varekova 2008-01-11 08:10:51 UTC
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.

Comment 60 Ivana Varekova 2008-01-11 08:15:42 UTC
David, could you please look at #58 (the second paragraph), where could be the
problem?
Thanks. 
Ivana 

Comment 61 Alex Lancaster 2008-01-11 08:29:56 UTC
(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.

Comment 62 Kevin R. Page 2008-01-11 10:02:05 UTC
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.

Comment 63 Kevin R. Page 2008-01-11 21:18:40 UTC
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?

Comment 64 Fedora Update System 2008-01-11 22:11:07 UTC
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'

Comment 65 Kevin R. Page 2008-01-11 22:29:03 UTC
(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!

Comment 66 Gustavo Maciel Dias Vieira 2008-01-12 00:40:22 UTC
(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!



Comment 67 Kevin R. Page 2008-01-17 16:17:12 UTC
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.

Comment 68 Kevin R. Page 2008-01-17 21:14:29 UTC
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.

Comment 69 Gustavo Maciel Dias Vieira 2008-01-21 21:46:05 UTC
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.


Comment 70 Alex Lancaster 2008-01-24 08:59:01 UTC
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.

Comment 71 Alex Lancaster 2008-01-24 09:00:25 UTC
(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).



Comment 72 Alex Lancaster 2008-01-30 11:32:48 UTC
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--




Comment 73 Alex Lancaster 2008-01-30 11:36:51 UTC
I do have udev-118-1.fc8 from bug #424331, so that doesn't seem to be the problem.

Comment 74 Kevin R. Page 2008-01-31 12:02:02 UTC
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)

Comment 75 Karsten Hopp 2008-01-31 12:29:17 UTC
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

Comment 76 Brian Morrison 2008-01-31 13:51:01 UTC
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.


Comment 77 Fedora Update System 2008-02-02 09:00:16 UTC
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.

Comment 78 Patrick C. F. Ernzer 2008-02-03 19:58:20 UTC
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

Comment 79 Joe Christy 2008-02-03 20:40:20 UTC
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.

Comment 80 Gustavo Maciel Dias Vieira 2008-02-03 20:43:49 UTC
(In reply to comment #71)
> Yes, probably should be filed separately, but leave a link to the new bug here).
> 

Filled under bug #431377.




Comment 81 Gustavo Maciel Dias Vieira 2008-02-03 20:47:13 UTC
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.


Comment 82 Kevin R. Page 2008-02-04 09:34:36 UTC
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.

Comment 83 Joe Christy 2008-02-04 23:20:11 UTC
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.


Comment 84 Kevin R. Page 2008-02-05 00:46:49 UTC
(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)

Comment 85 Patrick C. F. Ernzer 2008-02-05 15:33:27 UTC
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.

Comment 86 Kevin R. Page 2008-02-05 15:45:24 UTC
(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.

Comment 87 Brian Morrison 2008-02-05 15:59:51 UTC
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?


Comment 88 Joe Christy 2008-02-06 02:53:44 UTC
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.

Comment 89 Kevin R. Page 2008-02-06 08:44:00 UTC
(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.

Comment 90 Patrick C. F. Ernzer 2008-02-06 13:26:37 UTC
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--


Comment 91 Ivana Varekova 2008-02-06 13:31:29 UTC
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)?

Comment 92 Gustavo Maciel Dias Vieira 2008-02-06 13:45:48 UTC
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.

Comment 93 Kevin R. Page 2008-02-06 13:51:17 UTC
(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).

Comment 94 Kevin R. Page 2008-02-06 14:17:55 UTC
(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 ;)

Comment 95 Brian Morrison 2008-02-06 15:54:42 UTC
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.


Comment 96 Joe Christy 2008-02-06 18:30:06 UTC
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.



Comment 97 Joe Christy 2008-02-06 18:49:14 UTC
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.

Comment 98 Gustavo Maciel Dias Vieira 2008-02-06 19:10:22 UTC
(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.


Comment 99 Kevin R. Page 2008-02-06 19:26:31 UTC
(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).

Comment 100 Kevin R. Page 2008-02-10 22:51:46 UTC
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)

Comment 101 Kevin R. Page 2008-02-10 22:55:29 UTC
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?

Comment 102 Ivana Varekova 2008-02-12 15:00:56 UTC
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).

Comment 103 Kevin R. Page 2008-02-14 18:44:28 UTC
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.

Comment 104 Joe Christy 2008-02-17 21:44:58 UTC
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].

Comment 105 Kevin R. Page 2008-02-17 22:55:25 UTC
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.

Comment 106 Ivana Varekova 2008-02-20 13:01:24 UTC
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.


Comment 107 Wyatt Alverson 2008-02-24 05:43:20 UTC
(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!



Comment 108 Steve Baker 2008-02-24 14:20:47 UTC
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, 

Comment 109 Kevin R. Page 2008-02-24 19:51:28 UTC
(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)

Comment 110 Kevin R. Page 2008-02-24 20:04:20 UTC
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!

Comment 111 Kevin R. Page 2008-02-24 20:09:58 UTC
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).

Comment 112 Steve Baker 2008-02-24 22:22:02 UTC
(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!

Comment 113 Kevin R. Page 2008-02-24 23:17:26 UTC
(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!

Comment 114 Kevin R. Page 2008-02-24 23:27:00 UTC
(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"?



Comment 115 Steve Baker 2008-02-25 13:00:15 UTC
> 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




Comment 116 Kevin R. Page 2008-02-25 13:30:55 UTC
(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.

Comment 117 Steve Baker 2008-02-25 15:20:20 UTC
Created attachment 295803 [details]
Original Fedora8 policy file currently installed.

Comment 118 Steve Baker 2008-02-25 15:41:10 UTC
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




Comment 119 Kevin R. Page 2008-02-26 09:13:24 UTC
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.

Comment 120 Kevin R. Page 2008-02-26 15:15:23 UTC
(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)

Comment 121 Andrew Gilmore 2008-02-27 20:29:52 UTC
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.

Comment 122 Garrett Mitchener 2008-02-28 16:16:21 UTC
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--



Comment 123 Kevin R. Page 2008-02-28 16:31:54 UTC
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.

Comment 124 Garrett Mitchener 2008-02-28 18:43:34 UTC
(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.

Comment 125 Kevin R. Page 2008-02-28 18:56:32 UTC
(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

Comment 126 Garrett Mitchener 2008-02-28 22:34:01 UTC
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...

Comment 127 Kevin R. Page 2008-03-04 01:35:59 UTC
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!

Comment 128 Alex Lancaster 2008-03-16 09:06:16 UTC
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.


Comment 129 Alex Lancaster 2008-03-16 09:22:51 UTC
(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.

Comment 130 Kevin R. Page 2008-03-16 10:25:41 UTC
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.

Comment 131 Kevin R. Page 2008-03-27 00:16:49 UTC
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.

Comment 132 Alex Lancaster 2008-03-27 01:55:00 UTC
(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.

Comment 133 Kevin R. Page 2008-03-27 08:43:37 UTC
(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...

Comment 134 Jiri Moskovcak 2008-04-11 11:38:45 UTC
*** Bug 435266 has been marked as a duplicate of this bug. ***

Comment 135 Kevin R. Page 2008-04-11 13:25:09 UTC
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?

Comment 136 Ivana Varekova 2008-04-11 13:36:33 UTC
Good idea - I'm discussing it with release notes team.

Comment 137 Alex Lancaster 2008-04-11 13:37:36 UTC
(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.


Comment 138 Alex Lancaster 2008-04-11 13:39:52 UTC
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.

Comment 139 Aaron Kaplan 2008-04-11 13:40:38 UTC
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.

Comment 140 Alex Lancaster 2008-04-11 13:42:47 UTC
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.

Comment 141 Alex Lancaster 2008-04-11 13:45:05 UTC
(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.

Comment 142 Brian Morrison 2008-04-11 14:15:21 UTC
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.


Comment 143 Kevin R. Page 2008-04-11 14:22:50 UTC
(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.

Comment 144 Ivana Varekova 2008-04-14 10:59:42 UTC
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. 

Comment 145 Alex Lancaster 2008-04-14 11:51:24 UTC
(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).







Comment 146 Karsten Wade 2008-04-14 17:57:26 UTC
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.

Comment 147 Ivana Varekova 2008-04-15 13:38:38 UTC
I just edit release notes text:
http://fedoraproject.org/wiki/Docs/Beats/PackageNotes
If there is any problem please write a comment.
Thanks.

Comment 148 Kevin R. Page 2008-04-15 15:14:43 UTC
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.

Comment 149 Ivana Varekova 2008-04-16 08:25:48 UTC
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.

Comment 150 Kevin R. Page 2008-04-16 09:22:04 UTC
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.
"

Comment 151 Kevin R. Page 2008-04-16 09:35:40 UTC
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!

Comment 152 Ivana Varekova 2008-04-17 11:14:08 UTC
OK - you are right this version could be more useful for palm users then the
first one - thanks for your help.

Comment 153 Kevin R. Page 2008-04-19 18:21:25 UTC
Pleased to confirm that everything is working as it should in the F9 Preview
Release.

Comment 154 Ivana Varekova 2008-04-21 07:25:18 UTC
*** Bug 443189 has been marked as a duplicate of this bug. ***

Comment 155 Alex Lancaster 2008-05-03 22:16:13 UTC
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.

Comment 156 Paul Johnson 2008-05-06 17:41:57 UTC
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

Comment 157 Alex Lancaster 2008-05-08 07:14:49 UTC
(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.

Comment 158 Kevin R. Page 2008-05-08 09:32:01 UTC
(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.

Comment 159 Kevin R. Page 2008-05-23 23:22:20 UTC
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.

Comment 160 Alex Lancaster 2008-05-24 00:06:12 UTC
(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.


Comment 161 Kevin R. Page 2008-05-27 21:36:54 UTC
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.

Comment 162 Alex Lancaster 2008-05-28 00:53:50 UTC
(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.

Comment 163 Alex Lancaster 2008-05-28 01:07:34 UTC
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).

Comment 164 Kevin R. Page 2008-05-28 13:16:45 UTC
(In reply to comment #163)
> Kevin: can you test them?

The i386 build works for me.

Comment 165 Kevin R. Page 2008-06-06 08:21:50 UTC
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

Comment 166 Kevin R. Page 2008-06-06 08:25:05 UTC
By the way, did the koji scratch build work for others?

Comment 167 Alex Lancaster 2008-06-10 07:35:06 UTC
(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.

Comment 168 Alex Lancaster 2008-06-10 07:37:50 UTC
(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)?

Comment 169 Kevin R. Page 2008-06-10 08:44:18 UTC
(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.


Comment 170 Kevin R. Page 2008-06-15 21:51:34 UTC
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.

Comment 171 Alex Lancaster 2008-06-17 08:34:29 UTC
(*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).


Comment 172 Kevin R. Page 2008-06-19 08:00:22 UTC
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?

Comment 173 Alex Lancaster 2008-06-19 09:21:35 UTC
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.

Comment 174 Kevin R. Page 2008-06-24 09:33:19 UTC
(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...?

Comment 175 Kevin R. Page 2008-07-05 15:22:01 UTC
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.

Comment 176 Alex Lancaster 2008-07-06 01:52:26 UTC
(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.

Comment 177 Kevin R. Page 2008-07-06 02:19:33 UTC
(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.

Comment 178 Alex Lancaster 2008-07-06 02:29:20 UTC
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?)

Comment 179 Kevin R. Page 2008-07-06 13:03:42 UTC
(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.

Comment 180 Alex Lancaster 2008-07-09 08:25:38 UTC
(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.

Comment 181 Alex Lancaster 2008-07-09 08:35:29 UTC
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

Comment 182 Kevin R. Page 2008-07-09 08:47:50 UTC
(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 ;) )


Comment 183 Alex Lancaster 2008-07-09 08:49:06 UTC
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.

Comment 184 Fedora Update System 2008-07-09 08:56:57 UTC
pilot-link-0.12.2-21.fc8 has been submitted as an update for Fedora 8

Comment 185 Fedora Update System 2008-07-09 21:47:42 UTC
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

Comment 186 Kevin R. Page 2008-07-14 10:49:19 UTC
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.

Comment 187 Andrew Gilmore 2008-07-14 16:50:33 UTC
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.


Comment 188 Kevin R. Page 2008-07-14 17:06:36 UTC
(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.

Comment 189 Alex Lancaster 2008-07-16 00:53:08 UTC
(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... ;)




Comment 190 Fedora Update System 2008-07-18 08:05:57 UTC
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.

Comment 191 Alex Lancaster 2008-07-18 08:48:17 UTC
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.


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