From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: As part of fixing bug #160278 I determined that the backup conduit is unavailable in FC4. It turns out that this is for two reasons: 1) the backup conduit was explicitly disabled in the .spec file, presumably because it hadn't been updated for the new pilot-link API 2) the patch to change the install locations for the backup and file conduits was incomplete, so neither was available once built and installed The following patches will fix these problems. Note that they assume that the following patch which I've reported upstream has also been applied: http://bugzilla.gnome.org/show_bug.cgi?id=309130 Version-Release number of selected component (if applicable): gnome-pilot-2.0.13-2 How reproducible: Always Steps to Reproduce: Notice that backup conduit is unavailable in conduits list. Additional info:
Created attachment 116013 [details] Update backup conduit to new pilot-link API
Created attachment 116014 [details] Finish install patch change begun in gnome-pilot-2.0.10-fix_64bit.patch included in .spec file
Created attachment 116015 [details] .spec file fixes for installing .conduit files in correct location
Many thanks for these patches. I've been working on getting them into both FC4 updates and rawhide. The location for .conduit files should be ${libdir}/gnome-pilot/conduits rather than ${datadir}/gnome-pilot/conduits This is to allow parallel installation of 32-bit and 64-bit packages that contain conduits. I've updated gnome-pilot and evolution to use this location, which should be reflected in tomorrow's rawhide. I also found a bug in attachment 116013 [details]; if there are no changes since the last sync, the cleanup calls pi_buffer_free (NULL), which crashes gpilotd (it reads through the buffer pointer). I'm about to attach a slightly modified version of the patch which handles this, which again will be going into tomorrow's rawhide. Thanks again for all the work you've done on this.
Created attachment 116094 [details] Revised version of attachment 116013 [details] which avoids pi_buffer_free (NULL) when no changes have occurred
You're welcome. As has been asked on fedora-devel-list, I'm quite curious why the decision was made to go with the beta pilot-link. As for the conduit files, I wasn't sure which was desired, so I just went with expediency and put them where gnome-pilot was looking for them. Regarding the pi_buffer_free(), I could have sworn I checked that calling it with NULL was safe... In fact, that sure looks safe here. Are you certain you're looking at the pre4 version? In my copy here, pi_buffer_free does an 'if (buf)' which will catch buf == NULL.
Aha - my testing has been with pilot-link-0.12.0-0.pre2.0 I'll update my development machine now... thanks. Going with the beta pilot-link is now clearly a mistake. I'm sorry about the pain this has caused (FWIW it wasn't me who pushed it, but I didn't fight hard enough to get it reverted, so I guess you can still blame me)
Glad to have that mystery solved. As for going with the beta software, I'm personally not looking for someone to point a finger at; I'm just really curious what the argument was for making the move, given that even the primary developers of pilot-link have said not to ship it. Anyways, the main thing from my perspective is just to get the functionality working again. So thank you for being quick at working on getting new packages together.
Any idea when these patches will make it into FC4 updates? I just "yum check-update; yum update" yesterday and this is still very broken.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
The distribution against which this bug was reported is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as INSUFFICIENT_DATA. Setting status to NEEDINFO, and awaiting information from the reporter. Thanks in advance.
Closing as INSUFFICIENT_DATA.