Discussion:
Where to begin
Norman P. B. Joseph
2008-07-16 21:42:58 UTC
Permalink
Hello, all.

I've been fooling around with the Brutus packages here for a few days
without too much success, and I've pored over the list archives also
with mixed success, and I still have lots of questions, so I'm hoping
you can help set me on the right track.

As far as the Brutus Server, I have it installed right now on a VMware
image running XP Pro which I am using as a desktop, so I have Outlook
installed there as well. I gather from what I came across on the list
this is a bad idea, and that I ought to use a host without Outlook
installed but rather the MS MAPI and CDO 1.2.1 package from Microsoft.
Is this correct?

Also, my Linux desktop is Red Hat Enterprise v5.2, so I guess I'm left
to build my own packages (or borrow from the Fedora ones), but the
version numbers of the src RPMs and tarballs are a bit confusing to my
feeble mind.

For example, I first got the source tarballs for brutus-keyring which
were listed as version 0.9.11 and managed to get the
configure/make/install to work. I then got the source tarball for
evolution-brutus, which I found at version 1.2.17. I also got that to
configure/make/install with some tweaking. Evolution saw it as an
account type and I configured an account to test, but no luck connecting
to the server.

When I went to check out the src RPMs for brutus-keyring and
evolution-brutus for Fedora 8 I found brutus-keyring version 0.9.24-1,
which built without errors using rpmbuild --rebuild. So I installed the
resulting RPM.

Flush with that success I found evolution-brutus version 1.2.11-1 for
Fedora 8, did an rpmbuild --rebuild and installed the RPM. But when I
ran evolution from the command line it died with the following message:

% evolution
CalDAV Eplugin starting up ...
evolution-shell-Message: Killing old version of
evolution-data-server...
libnm_glib_nm_state_cb: dbus returned an error.
(org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service
files
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/libcamelbrutus.so: undefined symbol: brutus_D

So, without any other clue, I considered there may be some library
version match-up problem. So, I went to look for the Fedora 7 package,
and found version 1.1.28.7-1. Wait, wasn't I just building version
1.2.11? Then I remembered the original source tarball I downloaded was
1.2.17.

So, what version should I be looking to build for my RHEL 5 desktop?
Should I bother with the Fedora source (or binary) packages? Just go
straight to source tarballs and configure/make/install (but the versions
seem behind some of the src RPMs)? What do you recommend?

Thanks for your advice,

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-17 11:32:19 UTC
Permalink
Hi Norman,
Post by Norman P. B. Joseph
I've been fooling around with the Brutus packages here for a few days
without too much success, and I've pored over the list archives also
with mixed success, and I still have lots of questions, so I'm hoping
you can help set me on the right track.
I'll try my best ;-)
Post by Norman P. B. Joseph
As far as the Brutus Server, I have it installed right now on a VMware
image running XP Pro which I am using as a desktop, so I have Outlook
installed there as well. I gather from what I came across on the list
this is a bad idea, and that I ought to use a host without Outlook
installed but rather the MS MAPI and CDO 1.2.1 package from Microsoft.
Is this correct?
Yes. Using the MAPI DLLs from Outlook is a big no-no. It may work, but
more likely it doesn't.
Post by Norman P. B. Joseph
Also, my Linux desktop is Red Hat Enterprise v5.2, so I guess I'm left
to build my own packages (or borrow from the Fedora ones), but the
version numbers of the src RPMs and tarballs are a bit confusing to my
feeble mind.
I'd always recommend build from svn. It is really easy if you are
building on a supported platform and only mildly difficult if not.
Just get the repositories doing this:

svn co http://svn.42tools.net/repos/brutus-keyring/trunk/ brutus-
keyring
svn co http://svn.42tools.net/repos/evolution-brutus/trunk/
evolution-brutus

Then decent into brutus-keyring and do:

$ ./autogen.sh
$ make distfiles


The "./autogen.sh" step will complain loudly if any of the build or
run dependancies are missing. You can now install brutus-keyring and
its devel package:

$ cd $HOME/rpmbuild/RPMS/i386
$ rpm -Uvh ./brutus-keyring*.rpm

Now decent into the evolution-brutus source directory and repeat the
steps above - and you're done :-)

The source might need to be adapted to RHEL 5.2 but we'll look into
that later.

Best regards,
jules
Post by Norman P. B. Joseph
For example, I first got the source tarballs for brutus-keyring which
were listed as version 0.9.11 and managed to get the
configure/make/install to work. I then got the source tarball for
evolution-brutus, which I found at version 1.2.17. I also got that to
configure/make/install with some tweaking. Evolution saw it as an
account type and I configured an account to test, but no luck
connecting
to the server.
When I went to check out the src RPMs for brutus-keyring and
evolution-brutus for Fedora 8 I found brutus-keyring version 0.9.24-1,
which built without errors using rpmbuild --rebuild. So I installed the
resulting RPM.
Flush with that success I found evolution-brutus version 1.2.11-1 for
Fedora 8, did an rpmbuild --rebuild and installed the RPM. But when I
ran evolution from the command line it died with the following
% evolution
CalDAV Eplugin starting up ...
evolution-shell-Message: Killing old version of
evolution-data-server...
libnm_glib_nm_state_cb: dbus returned an error.
(org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service
files
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so: undefined symbol: brutus_D
So, without any other clue, I considered there may be some library
version match-up problem. So, I went to look for the Fedora 7
package,
and found version 1.1.28.7-1. Wait, wasn't I just building version
1.2.11? Then I remembered the original source tarball I downloaded was
1.2.17.
So, what version should I be looking to build for my RHEL 5 desktop?
Should I bother with the Fedora source (or binary) packages? Just go
straight to source tarballs and configure/make/install (but the versions
seem behind some of the src RPMs)? What do you recommend?
Thanks for your advice,
-Norm
--
Norman Joseph, Senior System Engineer
Concurrent Technologies Corporation
814.269.2633 --+--
Information Systems Management Office
(ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-
------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
_______________________________________________
brutus mailing list
http://www.42tools.com/mailman/listinfo/brutus
Luis Correia
2008-07-17 12:27:52 UTC
Permalink
Hi
Post by Jules Colding
Hi Norman,
Post by Norman P. B. Joseph
I've been fooling around with the Brutus packages here for a few days
without too much success, and I've pored over the list archives also
with mixed success, and I still have lots of questions, so I'm hoping
you can help set me on the right track.
I'll try my best ;-)
Post by Norman P. B. Joseph
As far as the Brutus Server, I have it installed right now on a VMware
image running XP Pro which I am using as a desktop, so I have Outlook
installed there as well. I gather from what I came across on the list
this is a bad idea, and that I ought to use a host without Outlook
installed but rather the MS MAPI and CDO 1.2.1 package from Microsoft.
Is this correct?
Yes. Using the MAPI DLLs from Outlook is a big no-no. It may work, but
more likely it doesn't.
Post by Norman P. B. Joseph
Also, my Linux desktop is Red Hat Enterprise v5.2, so I guess I'm left
to build my own packages (or borrow from the Fedora ones), but the
version numbers of the src RPMs and tarballs are a bit confusing to my
feeble mind.
I'd always recommend build from svn. It is really easy if you are
building on a supported platform and only mildly difficult if not.
svn co http://svn.42tools.net/repos/brutus-keyring/trunk/ brutus-
keyring
svn co http://svn.42tools.net/repos/evolution-brutus/trunk/
evolution-brutus
$ ./autogen.sh
$ make distfiles
The "./autogen.sh" step will complain loudly if any of the build or
run dependancies are missing. You can now install brutus-keyring and
$ cd $HOME/rpmbuild/RPMS/i386
$ rpm -Uvh ./brutus-keyring*.rpm
Now decent into the evolution-brutus source directory and repeat the
steps above - and you're done :-)
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Post by Jules Colding
Best regards,
jules
Luis Correia
Jules Colding
2008-07-17 12:31:25 UTC
Permalink
Hi
On Thu, Jul 17, 2008 at 12:32 PM, Jules Colding
Post by Jules Colding
Hi Norman,
Post by Norman P. B. Joseph
I've been fooling around with the Brutus packages here for a few days
without too much success, and I've pored over the list archives also
with mixed success, and I still have lots of questions, so I'm hoping
you can help set me on the right track.
I'll try my best ;-)
Post by Norman P. B. Joseph
As far as the Brutus Server, I have it installed right now on a VMware
image running XP Pro which I am using as a desktop, so I have Outlook
installed there as well. I gather from what I came across on the list
this is a bad idea, and that I ought to use a host without Outlook
installed but rather the MS MAPI and CDO 1.2.1 package from
Microsoft.
Is this correct?
Yes. Using the MAPI DLLs from Outlook is a big no-no. It may work, but
more likely it doesn't.
Post by Norman P. B. Joseph
Also, my Linux desktop is Red Hat Enterprise v5.2, so I guess I'm left
to build my own packages (or borrow from the Fedora ones), but the
version numbers of the src RPMs and tarballs are a bit confusing to my
feeble mind.
I'd always recommend build from svn. It is really easy if you are
building on a supported platform and only mildly difficult if not.
svn co http://svn.42tools.net/repos/brutus-keyring/trunk/ brutus-
keyring
svn co http://svn.42tools.net/repos/evolution-brutus/trunk/
evolution-brutus
$ ./autogen.sh
$ make distfiles
The "./autogen.sh" step will complain loudly if any of the build or
run dependancies are missing. You can now install brutus-keyring and
$ cd $HOME/rpmbuild/RPMS/i386
$ rpm -Uvh ./brutus-keyring*.rpm
Now decent into the evolution-brutus source directory and repeat the
steps above - and you're done :-)
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Except for the obligatory acinclude.m4 fixes ;-)

BR,
jules
Luis Correia
2008-07-17 12:33:35 UTC
Permalink
Hi!
Post by Jules Colding
Hi
On Thu, Jul 17, 2008 at 12:32 PM, Jules Colding
Post by Jules Colding
Hi Norman,
Post by Norman P. B. Joseph
I've been fooling around with the Brutus packages here for a few days
without too much success, and I've pored over the list archives also
with mixed success, and I still have lots of questions, so I'm hoping
you can help set me on the right track.
I'll try my best ;-)
Post by Norman P. B. Joseph
As far as the Brutus Server, I have it installed right now on a VMware
image running XP Pro which I am using as a desktop, so I have Outlook
installed there as well. I gather from what I came across on the list
this is a bad idea, and that I ought to use a host without Outlook
installed but rather the MS MAPI and CDO 1.2.1 package from
Microsoft.
Is this correct?
Yes. Using the MAPI DLLs from Outlook is a big no-no. It may work, but
more likely it doesn't.
Post by Norman P. B. Joseph
Also, my Linux desktop is Red Hat Enterprise v5.2, so I guess I'm left
to build my own packages (or borrow from the Fedora ones), but the
version numbers of the src RPMs and tarballs are a bit confusing to my
feeble mind.
I'd always recommend build from svn. It is really easy if you are
building on a supported platform and only mildly difficult if not.
svn co http://svn.42tools.net/repos/brutus-keyring/trunk/ brutus-
keyring
svn co http://svn.42tools.net/repos/evolution-brutus/trunk/
evolution-brutus
$ ./autogen.sh
$ make distfiles
The "./autogen.sh" step will complain loudly if any of the build or
run dependancies are missing. You can now install brutus-keyring and
$ cd $HOME/rpmbuild/RPMS/i386
$ rpm -Uvh ./brutus-keyring*.rpm
Now decent into the evolution-brutus source directory and repeat the
steps above - and you're done :-)
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Except for the obligatory acinclude.m4 fixes ;-)
Sure, but what I meant to say is only about the binary compatibility
and development packages.

Although I seem to see that autoconf 2.6 is needed (don't know why :)
Post by Jules Colding
BR,
jules
Luis Correia
Jules Colding
2008-07-17 12:50:19 UTC
Permalink
Hi Luis,
Post by Luis Correia
Post by Jules Colding
Post by Luis Correia
Post by Jules Colding
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Except for the obligatory acinclude.m4 fixes ;-)
Sure, but what I meant to say is only about the binary compatibility
and development packages.
Although I seem to see that autoconf 2.6 is needed (don't know why :)
Not 2.6 but 2.60. Do CentOS not ship with 2.60? I can easily revert
that requirement.

BR,
jules
Luis Correia
2008-07-17 12:54:56 UTC
Permalink
Hi!
Post by Jules Colding
Hi Luis,
Post by Luis Correia
Post by Jules Colding
Post by Luis Correia
Post by Jules Colding
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Except for the obligatory acinclude.m4 fixes ;-)
Sure, but what I meant to say is only about the binary compatibility
and development packages.
Although I seem to see that autoconf 2.6 is needed (don't know why :)
Not 2.6 but 2.60. Do CentOS not ship with 2.60? I can easily revert
that requirement.
The latest CentOS 5.2 ships with this:

autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.9.6

I can supply more info if need be
Post by Jules Colding
BR,
jules
Luis Correia
Luis Correia
2008-07-17 13:14:45 UTC
Permalink
Hi,

The latest CentOS 5.2 ships with this:

autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.9.6
libtoolize (GNU libtool) 1.5.22

gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)


Luis Correia
Norman P. B. Joseph
2008-07-17 14:26:00 UTC
Permalink
Post by Jules Colding
Hi Luis,
Post by Luis Correia
Post by Jules Colding
Post by Luis Correia
Post by Jules Colding
The source might need to be adapted to RHEL 5.2 but we'll look into
that later.
CentOS 5.2 is built from the RHEL 5.2 SRPMS, so if it works for me it
will work for you.
Except for the obligatory acinclude.m4 fixes ;-)
OK, now that the autogen.sh in evolution-brutus fails for me I'm
intrigued. Not being a full-time developer, can I ask what "the
obligatory acinclude.m4 fixes" entail? :)
Post by Jules Colding
Post by Luis Correia
Sure, but what I meant to say is only about the binary compatibility
and development packages.
Although I seem to see that autoconf 2.6 is needed (don't know why :)
Not 2.6 but 2.60. Do CentOS not ship with 2.60? I can easily revert
that requirement.
Well, here's how the build in evolution-brutus fails for me:

% ./autogen.sh --prefix=/usr
/usr/bin/gnome-autogen.sh
checking for autoconf >= 2.53...
testing autoconf2.50... not found.
testing autoconf... found 2.59
checking for automake >= 1.6...
testing automake-1.10... not found.
testing automake-1.9... found 1.9.6
checking for libtool >= 1.4.3...
testing libtoolize... found 1.5.22
checking for glib-gettext >= 2.2.0...
testing glib-gettextize... found 2.12.3
checking for intltool >= 0.25...
testing intltoolize... found 0.35.0
checking for pkg-config >= 0.14.0...
testing pkg-config... found 0.21
Checking for required M4 macros...
Checking for forbidden M4 macros...
Processing ./configure.in
Running libtoolize...
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
Running glib-gettextize... Ignore non-fatal messages.
Copying file mkinstalldirs
Copying file po/Makefile.in.in

Please add the files
codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
progtest.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

Running intltoolize...
Running aclocal-1.9...
configure.in:24: error: Autoconf version 2.61 or higher is required <-----
configure.in:24: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal-1.9: autom4te failed with exit status: 63
%

Is this requirement for autoconf >= 2.61 a hard requirement?

Thanks, all.

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- In the end I'll know, but on the way I'll wonder -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Norman P. B. Joseph
2008-07-17 17:24:27 UTC
Permalink
Forgive the breach of etiquette replying to my own post. It appears
that simply editing configure.in for evolution-brutus and changing
AC_PREREQ(2.61) to AC_PREREQ(2.59) was sufficient for a successful build
and install on my RHEL 5.2 box (I did "make dist-rpm" in both svn
directories and installed the resulting RPMs).

So now with the following packages installed:

brutus-keyring-devel-0.9.30-1
evolution-brutus-1.2.22-1
brutus-keyring-0.9.30-1

I start up evolution without problems, except until I try to add a new
email account, then BOOM! Evolution dies. When I run evolution from
the command line, this is the last message it prints on the console
before dying:

evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/libcamelbrutus.so: undefined symbol: brutus_D

Wow. Anyone know what I am missing here?

Thanks,

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-17 18:15:33 UTC
Permalink
Post by Norman P. B. Joseph
Forgive the breach of etiquette replying to my own post. It appears
that simply editing configure.in for evolution-brutus and changing
AC_PREREQ(2.61) to AC_PREREQ(2.59) was sufficient for a successful build
and install on my RHEL 5.2 box (I did "make dist-rpm" in both svn
directories and installed the resulting RPMs).
brutus-keyring-devel-0.9.30-1
evolution-brutus-1.2.22-1
brutus-keyring-0.9.30-1
I start up evolution without problems, except until I try to add a new
email account, then BOOM! Evolution dies. When I run evolution from
the command line, this is the last message it prints on the console
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so: undefined symbol: brutus_D
Wow. Anyone know what I am missing here?
Linking. What does ldd on libcamelbrutus say?

BR,
jules
Norman P. B. Joseph
2008-07-17 18:23:50 UTC
Permalink
Post by Jules Colding
Linking. What does ldd on libcamelbrutus say?
ldd /usr/lib64/evolution-data-server-1.2/camel-providers/libcamelbrutus.so
libBrutus-1.0.so.1 => /usr/lib/libBrutus-1.0.so.1 (0x00002b470cb38000)
libBrutusSTUBS-1.0.so.1 => /usr/lib/libBrutusSTUBS-1.0.so.1 (0x00002b470cd67000)
libBrutusd-1.0.so.1 => /usr/lib/libBrutusd-1.0.so.1 (0x00002b470cfca000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b470d1cd000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002b470d3e5000)
libORBit-2.so.0 => /usr/lib64/libORBit-2.so.0 (0x00002b470d683000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b470d8f0000)
libc.so.6 => /lib64/libc.so.6 (0x00002b470db0a000)
libWand.so.10 => /usr/lib64/libWand.so.10 (0x00002b470de5d000)
libMagick.so.10 => /usr/lib64/libMagick.so.10 (0x00002b470e108000)
libecal-1.2.so.7 => /usr/lib64/libecal-1.2.so.7 (0x00002b470e4d5000)
libcamel-1.2.so.0 => /usr/lib64/libcamel-1.2.so.0 (0x00002b470e794000)
libBrutusKeyringd-1.0.so.1 => /usr/lib/libBrutusKeyringd-1.0.so.1 (0x00002b470e9ee000)
libBrutusLogd-1.0.so.1 => /usr/lib/libBrutusLogd-1.0.so.1 (0x00002b470ebf0000)
libBrutusSKELS-1.0.so.1 => /usr/lib/libBrutusSKELS-1.0.so.1 (0x00002b470edf1000)
librt.so.1 => /lib64/librt.so.1 (0x00002b470eff8000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00002b470f201000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b470f404000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002b470f609000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00002b470f849000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a55800000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00002b470fa4d000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002b470fcd2000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002b470fedc000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002b47100f7000)
libm.so.6 => /lib64/libm.so.6 (0x00002b4710404000)
liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x00002b4710687000)
libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002b47108bb000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002b4710b15000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00002b4710d37000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002b4710f6b000)
libXt.so.6 => /usr/lib64/libXt.so.6 (0x00002b471117d000)
libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00002b47113de000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00002b47115ee000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002b4711803000)
libgnome-2.so.0 => /usr/lib64/libgnome-2.so.0 (0x00002b4711b40000)
libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x00002b4711d57000)
libbonobo-2.so.0 => /usr/lib64/libbonobo-2.so.0 (0x00002b4711f60000)
libbonobo-activation.so.4 => /usr/lib64/libbonobo-activation.so.4 (0x00002b47121d3000)
libgnomevfs-2.so.0 => /usr/lib64/libgnomevfs-2.so.0 (0x00002b47123ed000)
libgconf-2.so.4 => /usr/lib64/libgconf-2.so.4 (0x00002b4712664000)
libedataserver-1.2.so.7 => /usr/lib64/libedataserver-1.2.so.7 (0x00002b47128a0000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b4712aca000)
libssl.so.6 => /lib64/libssl.so.6 (0x00002b4712ce4000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b4712f2d000)
libssl3.so => /usr/lib64/libssl3.so (0x00002b4713275000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00002b47134a9000)
libnss3.so => /usr/lib64/libnss3.so (0x00002b47136d3000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002b4713a15000)
libplds4.so => /usr/lib64/libplds4.so (0x00002b4713c32000)
libplc4.so => /usr/lib64/libplc4.so (0x00002b4713e35000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00002b4714039000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b4714274000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b4714506000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b471472b000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b471492e000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00002b4714b5c000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b4714daa000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002b4714fac000)
libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b47151b1000)
libesd.so.0 => /usr/lib64/libesd.so.0 (0x00002b47153d4000)
libaudiofile.so.0 => /usr/lib64/libaudiofile.so.0 (0x00002b47155de000)
libORBitCosNaming-2.so.0 => /usr/lib64/libORBitCosNaming-2.so.0 (0x00002b471580a000)
libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x00002b4715a10000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00002b4715c2e000)
libavahi-glib.so.1 => /usr/lib64/libavahi-glib.so.1 (0x00002b4715e66000)
libavahi-common.so.3 => /usr/lib64/libavahi-common.so.3 (0x00002b4716069000)
libavahi-client.so.3 => /usr/lib64/libavahi-client.so.3 (0x00002b4716274000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b4716485000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b471669a000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002b47168b2000)
libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b4716ab6000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b4716dab000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b4716fe4000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b47171ec000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00002b47173ee000)
libasound.so.2 => /lib64/libasound.so.2 (0x00002b47175f2000)
libcap.so.1 => /lib64/libcap.so.1 (0x00002b47178cd000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b4717ad2000)
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-17 19:58:24 UTC
Permalink
Hi Norman,
Post by Jules Colding
Linking. What does ldd on libcamelbrutus say?
ldd /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so
<snip>

OK, it all looks normal. I might as well adjust b-k and e-b to RHEL
5.2 and then let you try once more with the distfiles target. What does:

lsb_release -si
lsb_release -sr
cat /etc/redhat-release

say?

Thanks,
jules
Norman P. B. Joseph
2008-07-17 20:13:33 UTC
Permalink
Post by Jules Colding
OK, it all looks normal. I might as well adjust b-k and e-b to RHEL
lsb_release -si
lsb_release -sr
cat /etc/redhat-release
say?
In order:
1. RedHatEnterpriseClient
2. 5.2
3. Red Hat Enterprise Linux Client release 5.2 (Tikanga)


Thanks,

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-17 20:31:26 UTC
Permalink
Post by Norman P. B. Joseph
Post by Jules Colding
OK, it all looks normal. I might as well adjust b-k and e-b to RHEL
lsb_release -si
lsb_release -sr
cat /etc/redhat-release
say?
1. RedHatEnterpriseClient
2. 5.2
3. Red Hat Enterprise Linux Client release 5.2 (Tikanga)
OK, thanks. I'll try to have it done by tomorrow.

Best regards,
jules
Jules Colding
2008-07-21 10:05:35 UTC
Permalink
Post by Jules Colding
Post by Norman P. B. Joseph
Post by Jules Colding
OK, it all looks normal. I might as well adjust b-k and e-b to RHEL
lsb_release -si
lsb_release -sr
cat /etc/redhat-release
say?
1. RedHatEnterpriseClient
2. 5.2
3. Red Hat Enterprise Linux Client release 5.2 (Tikanga)
OK, thanks. I'll try to have it done by tomorrow.
Done in svn.


Best regards,
jules
Norman P. B. Joseph
2008-07-21 12:21:19 UTC
Permalink
Thanks, Jules.

I've built and installed the RPM package
(evolution-brutus-1.2.23-1.x86_64.rpm), but I still get the same error
in Evolution when I try to add a new account:

evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/libcamelbrutus.so: undefined symbol: brutus_D

What am I missing?

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-21 13:09:30 UTC
Permalink
Hi Norman,
Post by Norman P. B. Joseph
I've built and installed the RPM package
(evolution-brutus-1.2.23-1.x86_64.rpm), but I still get the same error
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so: undefined symbol: brutus_D
What am I missing?
Good question. "brutus_D" is defined in libBrutus-1.0.so.1 which is
linked by libcamelbrutus. Hmmm.... OK please try to update from svn.
I've checked a possible fix in.

Thanks,
jules
Norman P. B. Joseph
2008-07-21 13:41:21 UTC
Permalink
Post by Jules Colding
Hi Norman,
Post by Norman P. B. Joseph
I've built and installed the RPM package
(evolution-brutus-1.2.23-1.x86_64.rpm), but I still get the same error
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so: undefined symbol: brutus_D
What am I missing?
Good question. "brutus_D" is defined in libBrutus-1.0.so.1 which is
linked by libcamelbrutus. Hmmm.... OK please try to update from svn.
I've checked a possible fix in.
Jules,

No luck. I still get the same error as before. Let me know what other
information or actions might be helpful in tracking this one down.

Thanks for your help,

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Jules Colding
2008-07-22 09:59:57 UTC
Permalink
Hi Norman,
Post by Norman P. B. Joseph
Post by Jules Colding
Hi Norman,
Post by Norman P. B. Joseph
I've built and installed the RPM package
(evolution-brutus-1.2.23-1.x86_64.rpm), but I still get the same error
evolution: symbol lookup
error: /usr/lib64/evolution-data-server-1.2/camel-providers/
libcamelbrutus.so: undefined symbol: brutus_D
What am I missing?
Good question. "brutus_D" is defined in libBrutus-1.0.so.1 which is
linked by libcamelbrutus. Hmmm.... OK please try to update from svn.
I've checked a possible fix in.
Jules,
No luck. I still get the same error as before. Let me know what other
information or actions might be helpful in tracking this one down.
I really have no idea. You're on a 64 bit box, but that should not be
a problem although I haven't tested on 64 bit.

Sorry,
jules

Norman P. B. Joseph
2008-07-17 12:32:40 UTC
Permalink
Hi
Post by Jules Colding
Hi Norman,
Thanks to both for the confirmations and the "howto". This will be my
project this morning.

-Norm
--
Norman Joseph, Senior System Engineer joseph-***@public.gmane.org IC|XC
Concurrent Technologies Corporation 814.269.2633 --+--
Information Systems Management Office (ISMO) NI|KA
-~- Things are more like they are now than they have ever been. - Gerald R. Ford -~-


------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may
contain company sensitive information. If you are not the
intended recipient, notify the sender immediately and delete
this message. Publication, reproduction, forwarding, or
content disclosure is prohibited without the consent of the
original sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
------------------------------------------------------------
Loading...