Hi, Hope this is the right list for this problem.
For FC4, there are loads of people trying to get their Palm PDA's syncing with the shipped gnome-pilot, but with no success.
I've spent about 4 hours researching the problem, and agree with Mark Adams, unpatched, the Fedora "version" of gnome-pilot will not work for udev-created /dev/ttyUSBx based connections due to many problems:
Please see: http://bugzilla.gnome.org/show_bug.cgi?id=274032#c24 and: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116025
It would be a shame to have a FC3 vmware image just to sync my Palm!
Can we spin a new rawhide version with the patches applied?
Thanks, Richard Hughes
On Mon, 2005-06-27 at 18:15 +0100, Richard Hughes wrote:
Hi, Hope this is the right list for this problem.
For FC4, there are loads of people trying to get their Palm PDA's syncing with the shipped gnome-pilot, but with no success.
I've spent about 4 hours researching the problem, and agree with Mark Adams, unpatched, the Fedora "version" of gnome-pilot will not work for udev-created /dev/ttyUSBx based connections due to many problems:
Please see: http://bugzilla.gnome.org/show_bug.cgi?id=274032#c24 and: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116025
It would be a shame to have a FC3 vmware image just to sync my Palm!
Can we spin a new rawhide version with the patches applied?
I'm on it.
Palm support seems to be especially cursed in FC4. There are some really low level problems - something that appears to be kernel/udev/hotplug (or quite likely a timing related bug in that set) that prevents even the command line pilot-xfer tools working in many cases (which completely destroys the possibility of gnome-pilot working).
Then gnome-pilot has a batch of bugs including timing related on ttyUSB, broken API wrt to pilot-link (which it links to), broken conduits and broken evolution integration.
Someone really really doesn't like this stuff :-/
Nigel.
"NM" == Nigel Metheringham writes:
NM> Palm support seems to be especially cursed in FC4. There are some NM> really low level problems - something that appears to be NM> kernel/udev/hotplug (or quite likely a timing related bug in that NM> set) that prevents even the command line pilot-xfer tools working NM> in many cases (which completely destroys the possibility of NM> gnome-pilot working).
NM> Then gnome-pilot has a batch of bugs including timing related on NM> ttyUSB, broken API wrt to pilot-link (which it links to), broken NM> conduits and broken evolution integration.
NM> Someone really really doesn't like this stuff :-/
I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I don't even try gnome-pilot let alone evolution integration), and seems to be working OK. I'll file some bugs on bugzilla.redhat.com on the current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get time. Interestingly, the pilot-link maintainer, David Desrosiers, has specifically admonished distributions not to include any of pilot-link 0.12 pre-test versions and wait until the official 0.12.0 release:
See the first announcement of pilot-link-0.12-pre1:
http://www.pilot-link.org/node/129
and a recent posting here:
http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html
I know Fedora is supposed to be bleeding edge, but is it wise to include a version in the distro that it's maintainer specifically suggests not to? I'm curious to know the reasoning behind including this version in FC4.
Alex
On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote:
I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I don't even try gnome-pilot let alone evolution integration), and seems to be working OK. I'll file some bugs on bugzilla.redhat.com on the current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get time.
Actualy that doesn't work for me either - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161058
It basically looks like being a problem down to the udev/hotplug mechanism taking so long to get around to build the devices (on a 2 year old laptop with reasonable memory load) that the palm has got bored and stopped sending initiation messages by the time you can connect to the new devices.
By putting a static device in place I can make this stuff work reliably. Not tried venturing near gnome-pilot yet - I know that stuff is broken.
Nigel.
"NM" == Nigel Metheringham writes:
[...]
NM> Actualy that doesn't work for me either - see NM> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161058
NM> It basically looks like being a problem down to the udev/hotplug NM> mechanism taking so long to get around to build the devices (on a NM> 2 year old laptop with reasonable memory load) that the palm has NM> got bored and stopped sending initiation messages by the time you NM> can connect to the new devices.
NM> By putting a static device in place I can make this stuff work NM> reliably. Not tried venturing near gnome-pilot yet - I know that NM> stuff is broken.
Interesting, I notice the greater latency you mention on FC4 compared with FC3, but for some reason the older pilot-link is more tolerant of the increased delay. I am using a locally built-from-SRPM on FC4 version of pilot-link-0.11.8-3 which has a patch to enable the Perl bindings (which I need for SyncBBDB). Have you tried rebuilding the earlier binaries from the last FC3 SRPM on your new FC4 installation and using them?
If this gets too off-topic, I'll followup on the Bugzilla entry.
Alex
On Tue, 2005-06-28 at 03:55 -0700, Alex Lancaster wrote:
Interesting, I notice the greater latency you mention on FC4 compared with FC3, but for some reason the older pilot-link is more tolerant of the increased delay. I am using a locally built-from-SRPM on FC4 version of pilot-link-0.11.8-3 which has a patch to enable the Perl bindings (which I need for SyncBBDB). Have you tried rebuilding the earlier binaries from the last FC3 SRPM on your new FC4 installation and using them?
Yes. Also using the FC3 binary rpm directly, and using a static linked FC3 pilot-xfer.
There is a narrow window which I can hit now I know I am aiming for getting to /dev/ttyUSB1 as early as possible with any of those. I have only been attempting to get it working at all so just using the list function - rather than seriously using pilot-xfer to do work.
Personally I think that we should just drop everything back down to a 0.11.x pilot-tools release and use a tool chain which basically works throughout - although it will be painful to release a down-reved update due to packaging side effects.
Maybe I should open a bug against udev/hotplug to see why things are so damn slow now.
Nigel.
"NM" == Nigel Metheringham writes:
NM> On Tue, 2005-06-28 at 03:55 -0700, Alex Lancaster wrote:
Interesting, I notice the greater latency you mention on FC4 compared with FC3, but for some reason the older pilot-link is more tolerant of the increased delay. I am using a locally built-from-SRPM on FC4 version of pilot-link-0.11.8-3 which has a patch to enable the Perl bindings (which I need for SyncBBDB). Have you tried rebuilding the earlier binaries from the last FC3 SRPM on your new FC4 installation and using them?
NM> Yes. Also using the FC3 binary rpm directly, and using a static NM> linked FC3 pilot-xfer.
NM> There is a narrow window which I can hit now I know I am aiming NM> for getting to /dev/ttyUSB1 as early as possible with any of NM> those.
[...]
Yes, I have the same problem, this little bash script wrapper ~/bin/pilot-link does the trick (most of the time) without having to manually hit the HotSync button in the exact window:
#!/bin/sh echo "Waiting for hotsync button" until [ -e /dev/pilot ]; do sleep 1; done exec /usr/bin/pilot-xfer "$@"
I use the udev facility for creating the symlink to /dev/pilot in /etc/udev/rules.d/
(Last post on this issue, I'll followup on http://bugzilla.redhat.com/161058)
Alex
On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote:
I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I don't even try gnome-pilot let alone evolution integration), and seems to be working OK. I'll file some bugs on bugzilla.redhat.com on the current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get time. Interestingly, the pilot-link maintainer, David Desrosiers, has specifically admonished distributions not to include any of pilot-link 0.12 pre-test versions and wait until the official 0.12.0 release:
I was talking to him last night in #gnome, and he's not happy what fedora are doing - he's getting loads of bugreports that are specific to FC4, and not present in the main release. Is there a specific reason we went so bleeding edge?
See the first announcement of pilot-link-0.12-pre1:
http://www.pilot-link.org/node/129
and a recent posting here:
http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html
I know Fedora is supposed to be bleeding edge, but is it wise to include a version in the distro that it's maintainer specifically suggests not to? I'm curious to know the reasoning behind including this version in FC4.
Similar. The rawhide patches allow me to sync my palm using gnome-pilot (thanks!) but also delete all my contacts and todo's on my palm! Just a warning for all those of you who don't believe in backups!
Richard
On Wed, 2005-06-29 at 00:43 +0530, Rahul Sundaram wrote:
Hi
Similar. The rawhide patches allow me to sync my palm using gnome-pilot (thanks!) but also delete all my contacts and todo's on my palm! Just a warning for all those of you who don't believe in backups!
Richard
Kindly file a bug report on this.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161963
Richard
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Rahul Sundaram Sent: Tuesday, June 28, 2005 2:13 PM To: Development discussions related to Fedora Core Subject: Re: gnome-pilot patches need applying
Hi
Similar. The rawhide patches allow me to sync my palm using gnome-pilot (thanks!) but also delete all my contacts and todo's on my palm! Just a warning for all those of you who don't believe in backups!
Richard
Kindly file a bug report on this.
regards Rahul
I am not sure this is a error, did you check the settings for your syncing, whether it was set computer to pda, or pda to computer, it makes a difference, if it is computer overwrites pda and this is the first time of use then all data on the pda will be erased with whatever data is on the pc, the first use should be pda overwrites computer. So there needs to be more info on what you did. But, having said that it could also be a bug so you probably need to explain what you did.
On Tue, 2005-06-28 at 18:21 -0500, Otto Haliburton wrote:
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Rahul Sundaram Sent: Tuesday, June 28, 2005 2:13 PM To: Development discussions related to Fedora Core Subject: Re: gnome-pilot patches need applying
Hi
Similar. The rawhide patches allow me to sync my palm using gnome-pilot (thanks!) but also delete all my contacts and todo's on my palm! Just a warning for all those of you who don't believe in backups!
Richard
Kindly file a bug report on this.
regards Rahul
I am not sure this is a error, did you check the settings for your syncing, whether it was set computer to pda, or pda to computer, it makes a difference, if it is computer overwrites pda and this is the first time of use then all data on the pda will be erased with whatever data is on the pc, the first use should be pda overwrites computer. So there needs to be more info on what you did. But, having said that it could also be a bug so you probably need to explain what you did.
Yes, I've tried everything from deleting the pilot stuff in ~/.evolution, hard-reseting the palm, and trying all the different conduit options. There's more info in the bugzilla.
Richard.
On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote:
"NM" == Nigel Metheringham writes:
NM> Palm support seems to be especially cursed in FC4. There are some NM> really low level problems - something that appears to be NM> kernel/udev/hotplug (or quite likely a timing related bug in that NM> set) that prevents even the command line pilot-xfer tools working NM> in many cases (which completely destroys the possibility of NM> gnome-pilot working).
NM> Then gnome-pilot has a batch of bugs including timing related on NM> ttyUSB, broken API wrt to pilot-link (which it links to), broken NM> conduits and broken evolution integration.
NM> Someone really really doesn't like this stuff :-/
I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I don't even try gnome-pilot let alone evolution integration), and seems to be working OK. I'll file some bugs on bugzilla.redhat.com on the current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get time. Interestingly, the pilot-link maintainer, David Desrosiers, has specifically admonished distributions not to include any of pilot-link 0.12 pre-test versions and wait until the official 0.12.0 release:
See the first announcement of pilot-link-0.12-pre1:
http://www.pilot-link.org/node/129
and a recent posting here:
http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html
I know Fedora is supposed to be bleeding edge, but is it wise to include a version in the distro that it's maintainer specifically suggests not to? I'm curious to know the reasoning behind including this version in FC4.
I think we made a mistake with this. I'm sorry for the pain this is causing everybody.
I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero.
I'll report back when I've got more information
On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote:
I think we made a mistake with this. I'm sorry for the pain this is causing everybody.
n/p :-)
I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero.
I've just installed:
evolution-data-server-1.2.2-4.fc5 evolution-2.2.2-11.fc5 evolution-webcal-2.2.0-1 pilot-link-0.12.0-0.pre4.2 gnome-pilot-conduits-2.0.13-1 gnome-pilot-2.0.13-6.fc5
(i.e. todays rawhide) and I have lots of funnies in gnome-pilot:
In the Devices tab I just get the following: Name Port Speed Type USB USB USB USB
And similar sort of thing for the Conduit Tab.
Not added to bugzilla yet, as you've probably got the same yourself!
I'll report back when I've got more information
Cheers!
Richard
On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote:
On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote:
I think we made a mistake with this. I'm sorry for the pain this is causing everybody.
n/p :-)
I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero.
I've just installed:
evolution-data-server-1.2.2-4.fc5 evolution-2.2.2-11.fc5 evolution-webcal-2.2.0-1 pilot-link-0.12.0-0.pre4.2 gnome-pilot-conduits-2.0.13-1 gnome-pilot-2.0.13-6.fc5
(i.e. todays rawhide) and I have lots of funnies in gnome-pilot:
In the Devices tab I just get the following: Name Port Speed Type USB USB USB USB
And similar sort of thing for the Conduit Tab.
Thanks. I'm not seeing that, I'm seeing sane column content. What you report is vaguely reminiscent of this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001
In particular, see this screenshot: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098
In both cases, every column is being displayed with the final column's content.
So I'm wondering if this is a separate, lower level issue with the GtkTreeView... are tree views working for you? Are you seeing the same behaviour as in that bug?
On Wed, 2005-06-29 at 16:07 -0400, David Malcolm wrote:
On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote:
On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote:
I think we made a mistake with this. I'm sorry for the pain this is causing everybody.
n/p :-)
I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero.
I've just installed:
evolution-data-server-1.2.2-4.fc5 evolution-2.2.2-11.fc5 evolution-webcal-2.2.0-1 pilot-link-0.12.0-0.pre4.2 gnome-pilot-conduits-2.0.13-1 gnome-pilot-2.0.13-6.fc5
(i.e. todays rawhide) and I have lots of funnies in gnome-pilot:
In the Devices tab I just get the following: Name Port Speed Type USB USB USB USB
And similar sort of thing for the Conduit Tab.
Thanks. I'm not seeing that, I'm seeing sane column content. What you report is vaguely reminiscent of this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001
In particular, see this screenshot: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098
In both cases, every column is being displayed with the final column's content.
So I'm wondering if this is a separate, lower level issue with the GtkTreeView... are tree views working for you? Are you seeing the same behaviour as in that bug?
Yep, you're right, sorry for the noise. It's in all TreeViews, not just gpilot.
Richard.
On Wed, 2005-06-29 at 21:12 +0100, Richard Hughes wrote:
On Wed, 2005-06-29 at 16:07 -0400, David Malcolm wrote:
On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote:
On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote:
I think we made a mistake with this. I'm sorry for the pain this is causing everybody.
n/p :-)
I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero.
I've just installed:
evolution-data-server-1.2.2-4.fc5 evolution-2.2.2-11.fc5 evolution-webcal-2.2.0-1 pilot-link-0.12.0-0.pre4.2 gnome-pilot-conduits-2.0.13-1 gnome-pilot-2.0.13-6.fc5
(i.e. todays rawhide) and I have lots of funnies in gnome-pilot:
In the Devices tab I just get the following: Name Port Speed Type USB USB USB USB
And similar sort of thing for the Conduit Tab.
Thanks. I'm not seeing that, I'm seeing sane column content. What you report is vaguely reminiscent of this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001
In particular, see this screenshot: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098
In both cases, every column is being displayed with the final column's content.
So I'm wondering if this is a separate, lower level issue with the GtkTreeView... are tree views working for you? Are you seeing the same behaviour as in that bug?
Yep, you're right, sorry for the noise. It's in all TreeViews, not just gpilot.
Thanks - that's useful information. I've commented on and changed the component of that bug to gtk2 accordingly.
So apart from that problem, how well is rawhide gnome-pilot working for you? For me, with a USB pilot it picks up on a sync about 50% of the time (possibly the timing issues suggested by Nigel Metheringham), and when it does, the UI appears and appears to run the conduits correctly. Backing up appears to work, but synchronization doesn't seem to be actually synchronizing - only calendars seem to sync OK.
On Wed, 2005-06-29 at 16:24 -0400, David Malcolm wrote:
Yep, you're right, sorry for the noise. It's in all TreeViews, not just gpilot.
Thanks - that's useful information. I've commented on and changed the component of that bug to gtk2 accordingly.
So apart from that problem, how well is rawhide gnome-pilot working for you? For me, with a USB pilot it picks up on a sync about 50% of the time (possibly the timing issues suggested by Nigel Metheringham), and when it does, the UI appears and appears to run the conduits correctly. Backing up appears to work, but synchronization doesn't seem to be actually synchronizing - only calendars seem to sync OK.
Well, it gets to sync's pretty much every time - except it seems to delete all the data on my palm, i.e. it seems to /move/ the data to evolution as a one way transfer!
Using pilot-link directly seems to work okay, but I think some of the API porting has broken jpilot, as that doesn't seem to work anymore.
Anyway, gpilotd seems much happier (i.e. it does something, but I think we need to nail the deleting issue) before an updates-released is released. What about putting versions in updates-testing so that less-brave-than-rawhide people can try out gnome-pilot?
Richard.
So I'm wondering if this is a separate, lower level issue with the GtkTreeView... are tree views working for you? Are you seeing the same behaviour as in that bug?
Yep, you're right, sorry for the noise. It's in all TreeViews, not just gpilot.
Thanks - that's useful information. I've commented on and changed the component of that bug to gtk2 accordingly.
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001
Rodd
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001
Rodd
Damn, do I feel stupid, that's the same bug report that was mentioned earlier in my thread.
<slap where="head" repeat>
Rodd
-
Alex Lancaster -
David Malcolm -
Nigel Metheringham -
Otto Haliburton -
Rahul Sundaram -
Richard Hughes -
Rodd Clarkson