Bug 166547 - Review Request: multisync - Calendar (and other PIM data) synchronization program
Review Request: multisync - Calendar (and other PIM data) synchronization pro...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Mahowald
David Lawrence
http://multisync.sourceforge.net/
:
Depends On: 174486
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-08-23 05:33 EDT by Andreas Bierfert
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-13 04:44:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
crashdump for multisync 0.82-4 with SonyEricsson K700i (5.60 KB, text/plain)
2005-10-23 07:10 EDT, Pontus Enhager
no flags Details

  None (edit)
Description Andreas Bierfert 2005-08-23 05:33:45 EDT
Spec Name or Url: http://fedora.lowlatency.de/review/multisync.spec
SRPM Name or Url: http://fedora.lowlatency.de/review/multisync-0.82-3.src.rpm
Description:
MultiSync is a program to synchronize calendars, addressbooks and other PIM
data between programs on your computer and other computers, mobile devices,
PDAs or cell phones. It is packaged with plugins for Ximian Evolution, IrMC
mobile devices, Opie / Zaurus PDAs, SyncML, ldap and for backup.
Comment 1 Michael Schwendt 2005-08-26 15:33:45 EDT
> %post -p /sbin/ldconfig
> 
> %postun -p /sbin/ldconfig

doesn't do anything useful when the package only contains plugin DSOs
in %_libdir/multisync/


> %{_datadir}/multisync/pixmaps/

is unowned. You could include it and its contents recursively.


> %package devel
> Summary:  Files needed for software development with %{name}
> Group:    Development/Libraries
> Requires: %{name} = %{version}-%{release}
> Requires:  openobex-devel
> Requires:  bluez-libs-devel
> Requires:  evolution-devel
> Requires:  evolution-data-server-devel
> Requires:  wbxml2-devel
> Requires:  curl-devel
> Requires:  expat-devel
> Requires:  openldap-devel
> Requires:  pilot-link-devel

It does not become clear at all, why all these requirements?

The multisync API header wants gtk2-devel, glib2-devel [and glibc-devel].


> #ldap
> %{_libdir}/multisync/libldap_plugin.so.*
> 
> #evolution (we only have so for this one)
> %{_libdir}/multisync/libevolution2_sync.so

This is the major thing that needs a review or a comment in the spec.
All these DSOs are used as plugins. Does the multisync engine really
load the versioned ones at run-time? Or does it prefer the non-versioned
*.so ones? And in case it loads the versioned ones, and since these
are plugins, there is not much point in shipping the *.so files in the
-devel package. Particularly not, because the DSOs don't live in dynamic
linker's default search path. On the contrary, some packagers like to
include "everything that's there", because some unknown corner-case program
might (!) want to link against a plugin like it's a library (oh well...)
even if it needed an rpath for that.
Comment 2 Andreas Bierfert 2005-08-26 19:16:59 EDT
Hm I guess you have a point there. I highly doubt that anything will link
against this as multisync does not seem to be running anywhere soon. In the
current spec I fixed the stuff you mentioned and removed the so files from the
devel package as it does not make much sense.

http://fedora.lowlatency.de/review/multisync.spec
http://fedora.lowlatency.de/review/multisync-0.82-4.src.rpm
Comment 3 Linus Walleij 2005-10-18 16:12:48 EDT
Hi Andreas, thanks for taking on this package which is much wanted
and would be very nice to have in the Extras. I will be using it for
sure... now some fixes:

%post
update-desktop-database %{_datadir}/applications &> /dev/null

%postun
if [ "$1" = "0" ]; then
  update-desktop-database %{_datadir}/applications &> /dev/null
fi

is needed to update the application database after installation.
This also means you need:

Requires(post): desktop-file-utils
Requires(postun): desktop-file-utils

And on the main package:

> Requires: gtk2-devel
> Requires: glib2-devel

Why are these two needed at runtime? Should they not be
BuildRequires:?
Comment 4 Andreas Bierfert 2005-10-18 16:31:14 EDT
%post
update-desktop-database %{_datadir}/applications &> /dev/null

%postun
>if [ "$1" = "0" ]; then
>  update-desktop-database %{_datadir}/applications &> /dev/null
>fi
>
>is needed to update the application database after installation.
>This also means you need:
>
>Requires(post): desktop-file-utils
>Requires(postun): desktop-file-utils

why is that exaclty?

Requires sure are a mistake ^^
Comment 5 Linus Walleij 2005-10-18 16:47:49 EDT
Says on:
http://www.fedoraproject.org/wiki/ScriptletSnippets

But for MIME types registration only and I guess Multisync does
not install such types, and then you're clear. But I do believe
the other stuff in the .desktop file isn't read in to the database
either, so couldn't hurt?

However adding the %{_datadir}/applications is superfluous so skip
that.
Comment 6 Linus Walleij 2005-10-18 17:11:57 EDT
One more thing: the autogen.sh script called here seems to add
a number of additional BuildRequires for autoconf, libtool,
intltool, and that xml-i18n thing atleast.
Comment 7 Pontus Enhager 2005-10-23 07:10:58 EDT
Created attachment 120285 [details]
crashdump for multisync 0.82-4 with SonyEricsson K700i

I can reproduce a crash with this package. 

(Although i do not know whteher this is the right bug to put it in)
Comment 8 Pontus Enhager 2005-10-23 15:09:39 EDT
Should add that i run FC4 now
Comment 9 Linus Walleij 2005-10-24 02:46:34 EDT
Pontus, I think this is more of a bug in Multisync itself than in
the packaging. Can you verify if the bug appears also if you install
from source?
Comment 10 John Mahowald 2005-11-26 00:39:54 EST
Missing BuildRequires: libtool, got some autoconf error cannot execute @LIBTOOL@
or something without it.

rpmlint as of release 4:

E: multisync devel-dependency glib2-devel
W: multisync no-version-in-last-changelog
E: multisync zero-length /usr/share/doc/multisync-0.82/ChangeLog
E: multisync zero-length /usr/share/doc/multisync-0.82/AUTHORS
E: multisync zero-length /usr/share/doc/multisync-0.82/NEWS
W: multisync-debuginfo no-version-in-last-changelog
E: multisync-debuginfo script-without-shellbang
/usr/src/debug/multisync-0.82/plugins/irmc_sync/src/irmc_obex.c
E: multisync-debuginfo script-without-shellbang
/usr/src/debug/multisync-0.82/plugins/irmc_sync/src/irmc_obex.h
E: multisync-debuginfo script-without-shellbang
/usr/src/debug/multisync-0.82/plugins/ldap_plugin/src/xml.c
E: multisync-debuginfo script-without-shellbang
/usr/src/debug/multisync-0.82/plugins/ldap_plugin/src/ldap.c
W: multisync-devel no-version-in-last-changelog
W: multisync-devel no-documentation
Comment 12 John Mahowald 2005-12-19 12:28:11 EST
Build fails, needs BuildRequires: libgnomeui-devel

make doesn't use smp flags, either add them or a comment as to why not. 
http://fedoraproject.org/wiki/PackagingGuidelines#parallelmake

Your patch disables -Werror. Haven't got to compiling this yet, but the authors
should know about any warnings.
Comment 13 Andreas Bierfert 2005-12-31 04:03:45 EST
I fixed th BR und commented on the missing smp flags (they don't work as of now).

As libopensync and in conjunction with this multisync is still in the early
stages of the project stuff is instable. I am trying to establish an upstream
contact...

Here is the new version:
http://fedora.lowlatency.de/review/multisync-0.90.18-2.src.rpm
http://fedora.lowlatency.de/review/multisync.spec
Comment 14 John Mahowald 2006-02-11 11:55:41 EST
Needs a bit more work:
* multisync-gui lacks a .desktop file.
* ** (multisync:13317): WARNING **: Couldn't find pixmap file:
multisync-0.90/multisync_small.png    upon start, which means it lacks an icon
in the window list
* Help > About doesn't work


Some of this may be due to the (Experimental) label on the title bar. How
unstable is this?
Comment 15 Andreas Bierfert 2006-02-17 03:27:40 EST
I think it is quiet unstable at this point altough I managed to get some data of
my synce device (the plugin is not release yet). Tough due to a lack of
alternatives I rather get this into the repo (otherwise libopensync-* is kind of
useless)...

I will add a desktop file and repost a new rpm...
Comment 16 Andreas Bierfert 2006-02-21 06:17:48 EST
Here is a fixed up version. Sadly it just segfaults here on x86_64/rawhide...

http://fedora.lowlatency.de/review/multisync-0.90.18-3.src.rpm
http://fedora.lowlatency.de/review/multisync.spec
Comment 17 Andreas Bierfert 2006-03-01 05:33:56 EST
Ok here is a fixed version... I also applied some stuff from svn and coded a
little bit so some of the menu enties work. Should be as good as it gets for now.

http://fedora.lowlatency.de/review/multisync-0.90.18-3.src.rpm
http://fedora.lowlatency.de/review/multisync.spec
Comment 18 Andreas Bierfert 2006-03-01 05:34:42 EST
hm should be http://fedora.lowlatency.de/review/multisync-0.90.18-4.src.rpm
Comment 19 Aurelien Bompard 2006-03-05 13:21:23 EST
Review for release 4:
* RPM name is OK
* This is the latest version
* Builds fine in mock
* Source is the same as upstream's
* Starts up, seems to work most of the time

Notes:
* Is %makeinstall needed ? We usually use "make install DESTDIR=%{buildroot}"
* The about box does not work, I don't know why.
Comment 20 Andreas Bierfert 2006-03-07 04:17:39 EST
If I remember correctly it did not work with make install because of a broken
autotoolchain :/ so I used classic %makeinstall which does the trick.

Yes the about box is s/broken/unimplemented/ as are some of the menu items... I
did not have time to implement all that code... need to bug upstream about
this... but its no fault of the package itself =)
Comment 21 Aurelien Bompard 2006-03-12 17:10:36 EST
OK, APPROVED then.
Comment 22 Andreas Bierfert 2006-03-13 04:44:35 EST
Thanks :) Build and pushed...
Comment 23 Pawel Salek 2006-04-04 08:37:11 EDT
Actually, comment in #19 re %makeinstall is perfectly valid: it puts some C
headers in a wrong place, directly in /usr/include instead of /usr/include/rra

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