Bug 529259

Sounds pretty serious.  Unfortunately I don't have a rawhide/F-12 box to test/reproduce on.

Ivana: have you seen this?  Are able to test on rawhide?

An update: it turns out that it works if I run the pilot-xfer command as root. Sometimes it appears to be necessary to run the command first, and then press sync on the Palm Pilot, but most of the time the ordering isn't important.

So it does appear to primarily be a permission problem.

How do I get further with this? How are the permissions for libusb handled?

Can you post any output from /var/log/messages that you get when you can't connect?  Could be a ConsoleKit / udev / hal issue.

There doesn't seem to be anything of interest in /var/log/messages. All I get is this:

Nov  5 10:49:38 localhost kernel: usb 1-8.3: USB disconnect, address 7
Nov  5 10:49:38 localhost kernel: usb 1-8.3: new full speed USB device using ehci_hcd and address 8
Nov  5 10:49:38 localhost kernel: usb 1-8.3: New USB device found, idVendor=0830, idProduct=0061
Nov  5 10:49:38 localhost kernel: usb 1-8.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Nov  5 10:49:38 localhost kernel: usb 1-8.3: Product: Palm Handheld
Nov  5 10:49:38 localhost kernel: usb 1-8.3: Manufacturer: Palm, Inc.
Nov  5 10:49:38 localhost kernel: usb 1-8.3: SerialNumber: PN70M4D6V3WV
Nov  5 10:49:38 localhost kernel: usb 1-8.3: configuration #1 chosen from 1 choice
Nov  5 10:49:55 localhost kernel: usb 1-8.3: USB disconnect, address 8
Nov  5 10:49:55 localhost kernel: usb 1-8.3: new full speed USB device using ehci_hcd and address 9
Nov  5 10:49:55 localhost kernel: usb 1-8.3: New USB device found, idVendor=0830, idProduct=0061
Nov  5 10:49:55 localhost kernel: usb 1-8.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Nov  5 10:49:55 localhost kernel: usb 1-8.3: Product: Palm Handheld
Nov  5 10:49:55 localhost kernel: usb 1-8.3: Manufacturer: Palm, Inc.
Nov  5 10:49:55 localhost kernel: usb 1-8.3: SerialNumber: PN70M4D6V3WV
Nov  5 10:49:55 localhost kernel: usb 1-8.3: configuration #1 chosen from 1 choice

I have been playing around with udev rules, and here is what I came up with that works:

/etc/udev/rules.d/99-palmpilot.rules:
SUBSYSTEM=="usb",ATTR{product}=="Palm Handheld",MODE="0666"

This may be to basic for other people's usage, but it works for me. It should probably be modified to include something like this:

KERNEL=="ttyUSB[13579]", SYMLINK+="pilot"

to setup device nodes and a symlink for those not using usb: to sync.

Now in what package does a udev rule like that belong?

The way the Fedora package works is that the old-style "visor" (i.e. non-libusb) access is mutually exclusive with the libusb access (which is now the default). This is described in:

/usr/share/doc/pilot-link-0.12.3/README.fedora

which describes how users can re-enable old-style visor support.

Okay. Then just ignore the bits about ttyUSB. The point still stands that it doesn't work for usb: as it is right now.

But perhaps it should be done using PolicyKit instead?

(In reply to comment #7)
> Okay. Then just ignore the bits about ttyUSB. The point still stands that it
> doesn't work for usb: as it is right now.

Sure, I was hoping that the main maintainer (Ivana) could chime in on this.  I don't currently have a rawhide/F-12 box to test.

> But perhaps it should be done using PolicyKit instead?  

I believe in the case of libusb it is being done using some of the *Kits.

Now that I have upgraded to F-12/rawhide I can now duplicate this error: /var/log/messages shows that the kernel recognises the device, but pilot-link doesn't do anything.

We probably need to investigate with upstream.

I don't necessarily think it has something to do with upstream. I made a quick grep through /usr/share/hal/fdi/policy/ and I was unable to find anything having to do with Palm Pilots.

Is it possible that we just need to create a PolicyKit and ship it with pilot-link?

I'll be glad to help with that if needed.

Mads, you are right, looks like the file with the appropriate info:

http://cgit.freedesktop.org/hal/tree/fdi/policy/10osvendor/20-acl-management.fdi

which normally resides in:

/usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi

has been removed because acl management is now supposed to be handled by udev according to:


* Wed Jul 22 2009 David Zeuthen <davidz> - 0.5.12-26.20090226git.4
- Disable ConsoleKit+PolicyKit support and lock down most interfaces with at_console
- Disable ACL management, this is now handled by udev >= 145 

Reassigning to udev maintainer.

udev maintainer: please advise on how to proceed with this because the removal of this hal file breaks *all* Palm Pilots.  I can't seem to find a corresponding file in the udev package.

This used to be handled within the pilot-link package at one time, but was removed by Ivana because it was moved to upstream hal.  It would be useful to know from the udev maintainer whether this will be added to udev upstream, if not, I guess we will have to figure out how to re-enable the code in the pilot-link package.

It would have been nice if the consequences of this removal had been communicated with the pilot-link maintainers as it took a long time to get pilot-link and libusb working nice with hal/udev and caused many users frustration for over a year, now with this sudden removal, we're back to square one.

(In reply to comment #10)
> I don't necessarily think it has something to do with upstream. I made a quick
> grep through /usr/share/hal/fdi/policy/ and I was unable to find anything
> having to do with Palm Pilots.
> 
> Is it possible that we just need to create a PolicyKit and ship it with
> pilot-link?
> 
> I'll be glad to help with that if needed.  

Mads, here is the commit that removed this from pilot-link when it was moved upstream:

http://cvs.fedoraproject.org/viewvc/rpms/pilot-link/F-12/pilot-link.spec?r1=1.77&r2=1.78

reversing this patch would be an initial starting point to re-enable appropriate udev/policykit stuff if udev maintainer is not able to, or it takes a while for it to be done in udev upstream.

Also reported this on f-d-l, to get some more general feedback on fixing this ASAP:

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00735.html

Cc'ing Kevin Page who helped getting the original hal / udev / consolekit in place back in the last great pilot-link mess in 2007-2008 (the infamous bug 280251 which took 1 year to get pushed out to updates).

ACLs now need to be handled through udev.

If you install a /lib/udev/69-pilot-link.rules file with the following single line as a content (ignore/fix any wrapping from Bugzilla):

BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*",KERNEL=="ttyUSB[13579]", ENV{ACL_MANAGE}="1"

it should work. (It's important that the number is less than 70 because the rules file which handles ACL_MANAGE and actually applies the ACLs is numbered 70.)

You could also base the rules on upstream's rules which list USB IDs instead of this one-liner, but the important thing is to have all the rules set ENV{ACL_MANAGE}="1" (and the file numbered 69 and installed to /lib/udev).

(In reply to comment #15)
> ACLs now need to be handled through udev.

OK, thanks, but my larger question is where should the rules ultimately "live"?  I mean should this be in the udev package itself or in pilot-link?   

I'm also really confused, because we *used* to have udev rules (way back when) and the switched to using hal (i.e. fdi files) in pilot-link, then they were added to hal and removed from pilot-link, now you're saying we should add the udev rules back to the pilot-link package? 

> If you install a /lib/udev/69-pilot-link.rules file with the following single
> line as a content (ignore/fix any wrapping from Bugzilla):
> 
> BUS=="usb", SYSFS{product}=="Palm
> Handheld*|Handspring*",KERNEL=="ttyUSB[13579]", ENV{ACL_MANAGE}="1"
> 
> it should work. (It's important that the number is less than 70 because the
> rules file which handles ACL_MANAGE and actually applies the ACLs is numbered
> 70.)  

Also everything you're describing above is definitely for the libusb way of accessing the Palm not for the old-style kernel "visor" module, right?

> OK, thanks, but my larger question is where should the rules ultimately "live"?
> I mean should this be in the udev package itself or in pilot-link?

Ultimately, these rules should probably be part of that 70-acl.rules file in udev itself. But having pilot-link drop in a 69-pilot-link.rules file will work fine, too.

> I'm also really confused, because we *used* to have udev rules (way back when)
> and the switched to using hal (i.e. fdi files) in pilot-link, then they were
> added to hal and removed from pilot-link, now you're saying we should add the
> udev rules back to the pilot-link package?

Yes, the logic needs to be in udev again, but in a slightly different format. Back in the pam_console days, what we did to handle device ACLs is that we had udev set some symlink with a special name (with the SYMLINK+= rule), and then matched that special name in a pam_console rule. Now we don't use pam_console anymore, instead the udev rules need to set ENV{ACL_MANAGE}="1", which is then handled within udev by using the udev-acl tool and information from ConsoleKit.

And yes, I'm also annoyed by how this is changing all the time! I really hope the latest method is here to stay! Having to change the rules at about every other Fedora release (i.e. about once a year) really sucks!

> Also everything you're describing above is definitely for the libusb way of
> accessing the Palm not for the old-style kernel "visor" module, right?

Well, there I must say I'm not sure, I don't know what the difference between these is. I'm not familiar with pilot-link, just with the ACL handling stuff because I need it for libticables2/libcalccables too.

The device matching rule I used is taken from that 60-pilot.rules file which was in Fedora's CVS. I just changed it to set ENV{ACL_MANAGE} instead of adding a symlink for pam_console.

What that rule does is that it matches any USB device called /dev/ttyUSB1, /dev/ttyUSB3, /dev/ttyUSB5, /dev/ttyUSB7 or /dev/ttyUSB9 and with a product name starting with "Palm Handheld" or "Handspring" and enables ConsoleKit-based ACL management for those devices. Whether that's the right test is something I don't know, I'd expect the pilot-link maintainer to know that best.

(In reply to comment #18)

> > Also everything you're describing above is definitely for the libusb way of
> > accessing the Palm not for the old-style kernel "visor" module, right?
> 
> Well, there I must say I'm not sure, I don't know what the difference between
> these is. I'm not familiar with pilot-link, just with the ACL handling stuff
> because I need it for libticables2/libcalccables too.
> 
> The device matching rule I used is taken from that 60-pilot.rules file which
> was in Fedora's CVS. I just changed it to set ENV{ACL_MANAGE} instead of adding
> a symlink for pam_console.

Where exactly did you get that rule, was it in CVS, or in the actual package?  I believe that rule was originally designed for the visor module, not for the libusb one.

> What that rule does is that it matches any USB device called /dev/ttyUSB1,
> /dev/ttyUSB3, /dev/ttyUSB5, /dev/ttyUSB7 or /dev/ttyUSB9 and with a product
> name starting with "Palm Handheld" or "Handspring" and enables ConsoleKit-based
> ACL management for those devices. Whether that's the right test is something I
> don't know, I'd expect the pilot-link maintainer to know that best.  

Yeah, unfortunately that doesn't seem to work with libusb.  I created a scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1807308

with /lib/udev/rules.d/69-pilot-link.rules with the contents as you suggested and installed it, and even rebooted to make sure udev was updated, but it still doesn't sync, although I now get messages in /var/log/messages upon pressing the hotsync on the Palm.

Initial messages on plug-in of Palm:


Nov 15 04:36:46 allele3 kernel: usb 3-1: new full speed USB device using uhci_hcd and address 2
Nov 15 04:36:46 allele3 kernel: usb 3-1: New USB device found, idVendor=0830, idProduct=0061
Nov 15 04:36:46 allele3 kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Nov 15 04:36:46 allele3 kernel: usb 3-1: Product: Palm Handheld
Nov 15 04:36:46 allele3 kernel: usb 3-1: Manufacturer: Palm, Inc.
Nov 15 04:36:46 allele3 kernel: usb 3-1: SerialNumber: PalmSN12345678
Nov 15 04:36:46 allele3 kernel: usb 3-1: configuration #1 chosen from 1 choice

then trying:

pilot-xfer -l -p usb:

I get new messages upon pressing hotsync on Palm:

Nov 15 04:37:01 allele3 kernel: usb 3-1: USB disconnect, address 2
Nov 15 04:37:02 allele3 kernel: usb 3-1: new full speed USB device using uhci_hcd and address 3
Nov 15 04:37:02 allele3 kernel: usb 3-1: New USB device found, idVendor=0830, idProduct=0061
Nov 15 04:37:02 allele3 kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Nov 15 04:37:02 allele3 kernel: usb 3-1: Product: Palm Handheld
Nov 15 04:37:02 allele3 kernel: usb 3-1: Manufacturer: Palm, Inc.
Nov 15 04:37:02 allele3 kernel: usb 3-1: SerialNumber: PalmSN12345678
Nov 15 04:37:02 allele3 kernel: usb 3-1: configuration #1 chosen from 1 choice

Ivana or Kevin: help?

(In reply to comment #19)

> Ivana or Kevin: help?  

That was intended to be Kevin Page, not Kevin Kofler.

Using the following content for the rule works for me:

BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*", ENV{ACL_MANAGE}="1"

I guess that including ttyUSB makes it not work for the libusb case

(In reply to comment #21)
> Using the following content for the rule works for me:
> 
> BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring*", ENV{ACL_MANAGE}="1"
> 
> I guess that including ttyUSB makes it not work for the libusb case  

Co-incidentally I just this second got it working using:

SUBSYSTEM=="usb", SYSFS{product}=="Palm Handheld*|Handspring*",ENV{ACL_MANAGE}="1"

Not sure what the difference is between SUBSYSTEM and BUS and which is preferred.

Mads: can you test the koji scratch builds I made here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1807419

if they work for you, I'll push a 0-day update for F-12 ASAP.

pilot-link-0.12.4-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pilot-link-0.12.4-3.fc12

Just tried it out. Works for me, so go ahead and push it.

I am running Fedora 12 64 bit. Installed the updated proposed package and it fixed my problem. I can now sink with my Tungsten T.

Hi. Oh dear, not again :(

N.B. I don't know exactly what's going on with the move from HAL back to udev+PolicyKit. I don't think the current suggestions are quite right, so I'll share opinion without having had time to investigate in sufficient detail, really...

(In reply to comment #18)
> The device matching rule I used is taken from that 60-pilot.rules file which
> was in Fedora's CVS. I just changed it to set ENV{ACL_MANAGE} instead of 
> adding a symlink for pam_console.

So, as Alex says, this definitely isn't right, since 60-pilot.rules is deprecated in favour of using libusb (in turn because it's an incorrect approximation to assume that the Palm will appear on ttyUSB[13579]. I really wish people would stop doing that. It might work for your device, but it'll break for others).

Surely the correct solution will involve updating the *current* ruleset to the new regime? The files that do this are in F11 are:
/usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi
/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi

From this, I also suspect matching on "Palm Handheld*|Handspring*" (comment #22) is too approximate/crude and may cause unintended consequences down the line - it's certainly not the logic used upstream (e.g. will WebOS devices will match on this?).

Anyway, in the old setup 10-usb-pda.fdi sets pda.platform to "palm" and pda.palm.hotsync_interface to the correct USB device file. 20-acl-management.fdi then checks for these and sets info.capabilities and access_control.type

So as far as the matching that needs to be in udev, I'd suggest it needs to look like that in 10-usb-pda.fdi - and not there are actually 2 sections, one to set serial devices so that visor still works if needed, followed by a section for libusb.

The matching for libusb is done by vendor_id and product_id - i.e. there's a maintained list of PalmOS devices encapsulated in 10-usb-pda.fdi (and let's face it, it's unlikely to grow any more).

e.g.
<match key="usb_device.vendor_id" int="0x0830">
   <!-- m500,m505,m515,2xunknown,i705,Tungsten Z,Tungsten W,m125,m130,3x unknown, (Tungsten series, Zire 71), 3x(Zire 21, 31, 72, Z22, Tungsten E2, T3, TX, Treo 650, 680, LifeDrive), 2x Zire, m100, 2y unknown -->
   <match key="usb_device.product_id" int_outof="0x0001;0x0002;0x0003;0x0010;0x0011;0x0020;0x0030;0x0031;0x0040;0x0050;0x0051;0x0052;0x0053;0x0060;0x0061;0x0062;0x0063;0x0070;0x0071;0x0080;0x0099;0x0100">
      <merge key="pda.platform" type="string">palm</merge>
      <merge key="pda.palm.hotsync_interface" type="copy_property">linux.device_file</merge>
   </match>
</match>

If someone can give the new udev stanza corresponding to the above we'll be able to translate all the existing rules.

It seems like we just might need to set ENV{ACL_MANAGE}="1" for all the relevant vendor_id/product_id combos? Though given PolicyKit is a security mechanism I'm concerned about making it work by templating without really understanding what (device files?), or why ACL_MANAGE is being set.

I'll attach the two files from F11 in case these aren't available to anyone looking.

I'm somewhat aghast that when this logic was removed from HAL it wasn't re-implemented in udev. Surely it should be obvious it was doing *something*, and perhaps that something was there for a reason?!?

I'll try and take a look at how to do the translation to udev, but don't rely on me - I can't guarantee I'll have the time given the need for a 0-day update.

Sigh.

Created attachment 369602 [details]
10-usb-pda.fdi in F11 (device matching logic)

Created attachment 369603 [details]
20-acl-management.fdi in F11 (after device matching sets keys for PolicyKit)

> Not sure what the difference is between SUBSYSTEM and BUS and which is
> preferred.

BUS is deprecated, SUBSYSTEM is better. It's my fault for copying the obsolete key, sorry. I'm going to post an updated rules file which matches the USB IDs from the 10-usb-pda.fdi you attached.

> I'm somewhat aghast that when this logic was removed from HAL it wasn't
> re-implemented in udev. Surely it should be obvious it was doing *something*,
> and perhaps that something was there for a reason?!?

I think that's something the maintainers of the affected packages were expected to do, some announcement about this was posted to the fedora-devel-list a few months ago. On the other hand, udev ships its own rules for many of the affected devices, but clearly not all the devices which need ACLs are covered.

Created attachment 369623 [details]
/lib/udev/69-pilot-link.rules

I've attached a rules file which matches all the USB IDs for libusb. I also recommend using this one, it's much cleaner, more complete and possibly even faster than the name matching. (I'd just recommend double-checking the USB IDs against the originals in 10-usb-pda.fdi to make sure I didn't screw them up or forget any.)

Thanks for the patch. I would say I'll test it with F12 beta, but it'll probably be a few days before I have the chance to install, so I'll likely just use the main release :)

I'm still a bit unclear about what the interaction between udev and PolicyKit is - and this should become clearer once I can poke at an F12 system - but from 70-acl.rules in udev git it looks like some systems are setting an ENV first (e.g. ID_HPLIP, or perhaps ID_PDA for us?) which is then matched to set ENV{ACL_MANAGE} in 70-acl.rules.

Perhaps so that setting ENV{ID_PDA} can be kept in the package (e.g. pilot_link), while all the ENV{ACL_MANAGE}  are together in udev-extras/70-acl.rules? It's also more like the 10-usb-pda.fdi/20-acl-management.fdi split in hal.

This seems to tally with the final paragraph here:
http://lists.freedesktop.org/archives/devkit-devel/2009-July/000354.html


(In reply to comment #30)
> I think that's something the maintainers of the affected packages were expected
> to do, some announcement about this was posted to the fedora-devel-list a few
> months ago. On the other hand, udev ships its own rules for many of the
> affected devices, but clearly not all the devices which need ACLs are covered.  

I'd perhaps buy that if 10-usb-pda.fdi had been part of the pilot-link package, but it isn't, it's part of hal-info. Indeed one of the reasons for moving it upstream into hal-info was to make pilot-link less susceptible to the frequent changes in hal/PolicyKit/udev/whatever comes next...

(In reply to comment #30)
> > Not sure what the difference is between SUBSYSTEM and BUS and which is
> > preferred.
> 
> BUS is deprecated, SUBSYSTEM is better. It's my fault for copying the obsolete
> key, sorry. I'm going to post an updated rules file which matches the USB IDs
> from the 10-usb-pda.fdi you attached.

Thanks, that looks much better, I'll see if I can test it and create a new update ASAP.

> > I'm somewhat aghast that when this logic was removed from HAL it wasn't
> > re-implemented in udev. Surely it should be obvious it was doing *something*,
> > and perhaps that something was there for a reason?!?
> 
> I think that's something the maintainers of the affected packages were expected
> to do, some announcement about this was posted to the fedora-devel-list a few
> months ago. On the other hand, udev ships its own rules for many of the
> affected devices, but clearly not all the devices which need ACLs are covered.  

When pilot-link carried those files in the package itself, that would be reasonable to expect since we had direct control over those files.  However once they were included in upstream hal, I would have expected upstream hal / udev make a bit more of an effort to directly contact the maintainers of affected packages directly, since they now maintained the relevant files since it's very likely they were completely unaware of this going away.  

At the very they should have posted on fedora-devel-announce (rather than relying on f-d-l, which has so much traffic I hardly have time to read it).

(In reply to comment #32)
> This seems to tally with the final paragraph here:
> http://lists.freedesktop.org/archives/devkit-devel/2009-July/000354.html

Probably also:
http://lists.freedesktop.org/archives/devkit-devel/2009-June/000204.html

"The ACL_MANAGE trigger should be in udev only and not in the gphoto
rules, it's udev "policy stuff" which should not leak into generic
infrastructure."

OK, in the absence of action in the udev space, in the meantime I'm going to create a new update for F-12 updates-testing using Kevin Kofler's new udev rules, as it should better match devices and has less risk of false positives.

(In reply to comment #35)
> OK, in the absence of action in the udev space, in the meantime I'm going to
> create a new update for F-12 updates-testing using Kevin Kofler's new udev
> rules, as it should better match devices and has less risk of false positives.  

Scratch build underway here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1808450

pilot-link-0.12.4-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pilot-link-0.12.4-4.fc12

I agree that setting ENV{ACL_MANAGE} directly from a rule shipped by pilot-link is a hack and that in the long run this should be done either entirely in udev (especially considering that information was previously in hal-info and not pilot-link) or split across 2 rules with one shipped in pilot-link (setting something like ENV{pilot_link_matched}) and one in udev (setting ENV{ACL_MANAGE} based on that) as it's done for libsane. But the hack works. ;-)

pilot-link-0.12.4-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #38)
> But the hack works.
> ;-)  

Indeed, and thanks for moving with this so quickly! I somehow doubt it'd be fixed in time going through the udev packages.

However, can we leave this bug open until we have a longer term fix as per comment #38 please?

It is preferred, if packages maintain their own databases and install them into /lib/udev/rules.d/, instead of adding device matches to udev itself.

BUS is the same a SUBSYSTEM, but BUS is from the early days of udev and will be removed some day. Only the keys mentioned in the udev(7) man page are supported.

ACL_MANAGE can be set by custom rules files, it will work fine, but there is ongoing work to support multi-seat setups. It's unsure at the moment, when the multi-seat support will land, but it's possible, that ACL_MANAGE will be changed or needs to go away entirely, but we will only know when the guys are ready with their infrastructure.

For now, it might be safer to set some variable that tells the udev-acl file to trigger the ACL setting, like sane and some other packages are doing it.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Can people also please test the update in updates-testing, this is a slightly improved set of udev by Kevin Kofler in comment #31:

https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11663

Ultimately we need to get this by using the approach in comment #41.

(In reply to comment #43)
> Can people also please test the update in updates-testing, this is a slightly
> improved set of udev by Kevin Kofler in comment #31:
> 
> https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11663

And post +1 or -1 karma votes too (especially if you have an FAS account).

pilot-link-0.12.4-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

pilot-link-0.12.4-4.fc12 works fine for me.

I think this bug needs to remain open until we have a more correct fix as per comment #41. The current fix is a bit of a sticking plaster.

(Haven't had a chance to do anything myself, but hope to find time eventually).

Well, the solution might not be cleanest from a developer's standpoint, but it solves the problem, so I don't see why we'd need to keep the bug open.