Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 15:13 +0200, Milan Crha wrote: > seems to be better than autotools, gives more freedom and easily > allows the sources to be built much faster than with autotools (it > builds here in ~1/3 of the time which uses autotools, still using > "Unix Makefiles"). I know it's caused mostly by not having one giant > Makefile.am, but this way it's easier (at least for me). I have nothing really against CMake (we use it at work to excellent effect as our product builds on GNU/Linux, OS X, and Windows). Since I don't build Evo myself anymore, it doesn't impact me anyway and developers should definitely do what makes their lives simpler and more productive. I will point out that (a) I've had a lot of problems using CMake in a cross-compilation environment, where autotools works flawlessly and painlessly (at least as much as is possible when cross-compiling) and also (b) autoconf's support for command line options that select different features, etc. is IMO much simpler to work with and use than CMake's. But, maybe those things are not so important for Evolution since it's probably not often cross-compiled and it relies on the GNOME infrastructure and so maybe has fewer configuration options available. Cheers! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GSoC Ideas
What I'd really love to have is the ability to select multiple messages (using CTRL-click etc.) and then choose reply and have it create a new message replying to the set of people the original message was addressed to (removing duplicates), and including quoted copies of all the selected message. And including the proper References header. Alternatively to that, even better would be to have the paste quotation menu item include the proper attribute line before the quote... and add the quoted message ID to the References header as well. This seems hard, but maybe not depending on what info you can send along with the select request. I'm constantly trying to reply to multiple messages in a single message and it is kind of a pain right now. However I'm not sure this is a GSOC-level project. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, 2013-07-24 at 10:58 +0100, David Woodhouse wrote: My concern is that it could also be longer before new features and fixes actually make it into a release. For example, if we were on an annual schedule and people were still using Evolution 3.6 today instead of Evolution 3.8 we'd still be having to kill evolution-source-registry after connecting to the VPN if we actually want to see our calendars. And if a distribution ships a few weeks before a release, that now means they can be shipping a version of Evolution which is a *year* old, instead of only six months old. I agree with David. My main frustration with Evo right now is that I'm always a release behind because my distribution appears to be chronically one Gnome release back (I understand this is due to my distribution and not the responsibility of the developers), for whatever reason. That means I was stuck on 3.4 until May (which was bad as there were numerous problems with 3.4), and will be using 3.6 for most of the rest of the year. If the distributors and the Evo release cycle don't line up nicely you could be working with an Evolution that's more than 18 months old (assuming a 6 month distro release cycle; some distros are longer than that) before you get to the next version. Not being familiar with Evo development I'm not sure how feasible it is, but ideally part of the change in release cycle would mean divorce from the Gnome version lockstep, and Evo being able to build against multiple versions of Gnome. If Evo were changed to be more of a stand-alone utility (at least optionally), rather than being bundled with Gnome, that would be (IMO) a good thing for users. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
On Wed, 2013-01-23 at 13:05 -0500, Paul Smith wrote: I did file a bug (sorry I forgot to post that here). But today I used jhbuild to create a local Evo 3.6.4 and tried that, and it worked fine so that bug has been fixed since 3.6.0 was released and I resolved the bug again. FYI my distro released a new version of Evolution (3.6.2) and I upgraded to that and tested it and this issue is not seen there either. And, I get back my theme support so that's nice... ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
On Mon, 2013-01-21 at 14:51 -0500, Paul Smith wrote: On Mon, 2013-01-21 at 20:35 +0100, Milan Crha wrote: Yeah, I also think the backend doesn't matter. It'll be good to save the message as mbox, strip private information from it and share it at [1], which seems to be the same crash, I only wasn't able to find the message or otherwise reproduce it again. OK, I'll try to do this. I did file a bug (sorry I forgot to post that here). But today I used jhbuild to create a local Evo 3.6.4 and tried that, and it worked fine so that bug has been fixed since 3.6.0 was released and I resolved the bug again. The new Evo seems to work great, but it doesn't use any of my local desktop theming since I installed it into /opt/gnome (?). So it looks somewhat clunky and old-school with the base theming and icons. However, it works better and that's more important to me than having it look pretty :-). The only really annoying thing is that when I use mouse selection, I get black foreground AND background resulting in unreadable selected text. If anyone knows how to fix that I'd appreciate it. I did note with interest the recently-reported possibility of Ubuntu moving to a rolling release model in between the Long Term Support releases. If they did that I wonder if they could be convinced to package the Gnome point releases as they come out. That would be a huge advantage (to me anyway). ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Regular core dumps in Evo 3.6.0
Hi all; I'm using Evolution 3.6.0 in GNU/Linux Mint 14 with Cinnamon as
the desktop.
I'm using IMAP+ to access 3 different IMAP accounts: two Google accounts
and one normal IMAP (from my ISP; I think using Dovecot).
I'm finding that I'm getting core dumps in Evolution fairly often: once
every couple of days (from SIGTRAP?), and I can also get Evo to dump
core (with SIGSEGV) every time I visit a particular email (received
through one of the Google accounts, but the dump appears to happen in
the display engine so the backend is probably not relevant).
I realize that I'm not using the latest (it really bugs me how the
standard distributions never seem to bother to package the Gnome point
releases :-/). Is it worthwhile sending along backtraces (I've
installed the evolution-dbg packages at least)?
Should I just build my own latest versions? In the past (but this was
Gnome 2.x) I've had problems with this: confusing dbus between the
different installations, etc. Maybe this is more cleanly supported now?
Cheers!
Just FYI, I'll include the stack trace of the reproducible core, on a
particular email; unfortunately the libcamel library doesn't seem to
have a debug package available:
(gdb) bt full
#0 __memcpy_ssse3_back () at
../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1432
No locals.
#1 0x7f1cffb264ee in memcpy (__len=optimized out, __src=0x7f1cb811a7c0,
__dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
No locals.
#2 g_array_append_vals (farray=farray@entry=0x7f1cdc00b730,
data=0x7f1cb811a7c0, len=387) at
/build/buildd/glib2.0-2.34.1/./glib/garray.c:419
array = 0x7f1cdc00b730
__PRETTY_FUNCTION__ = g_array_append_vals
#3 0x7f1cffb27569 in g_byte_array_append (array=0x7f1cdc00b730,
data=optimized out, len=optimized out) at
/build/buildd/glib2.0-2.34.1/./glib/garray.c:1639
No locals.
#4 0x7f1d0266916a in ?? () from /usr/lib/libcamel-1.2.so.40
No symbol table info available.
#5 0x7f1d0266a3da in camel_stream_write () from /usr/lib/libcamel-1.2.so.40
No symbol table info available.
#6 0x7f1ce56504a8 in emfe_text_html_format (extension=0x7f1d05d97e80,
formatter=0x7f1cb8124600, context=0x7f1cb81252d0, part=0x7f1cb812a040,
stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at
e-mail-formatter-text-html.c:328
uri = 0x7f1cb811b660
mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2
str = 0x7f1cb811a7c0 div class=\part-container-nostyle\iframe
width=\100%\ height=\10\ frameborder=\0\
src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\
id...
#7 0x7f1ce5648a55 in e_mail_formatter_format_as
(formatter=formatter@entry=0x7f1cb8124600,
context=context@entry=0x7f1cb81252d0, part=part@entry=0x7f1cb812a040,
stream=stream@entry=0x7f1cb8109d20, as_mime_type=optimized out,
cancellable=cancellable@entry=0x7f1d062b2f80) at e-mail-formatter.c:951
extension = optimized out
reg = 0x7f1ca805ef40
formatters = optimized out
iter = 0x7f1d05d97ec0
ok = 0
__PRETTY_FUNCTION__ = e_mail_formatter_format_as
#8 0x7f1ce5648d19 in mail_formatter_run (formatter=0x7f1cb8124600,
context=0x7f1cb81252d0, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at
e-mail-formatter.c:124
part = 0x7f1cb812a040
ok = optimized out
iter = 0x7f1cb81265b0
hdr = optimized out
#9 0x7f1ce56484e8 in e_mail_formatter_format_sync
(formatter=0x7f1cb8124600, parts=0x7f1cb8124540, stream=0x7f1cb8109d20,
flags=1, mode=E_MAIL_FORMATTER_MODE_NORMAL, cancellable=0x7f1d062b2f80) at
e-mail-formatter.c:784
context = 0x7f1cb81252d0
formatter_class = optimized out
__PRETTY_FUNCTION__ = e_mail_formatter_format_sync
#10 0x7f1ce5d092c0 in handle_mail_request (res=0x7f1d06213900,
object=optimized out, cancellable=0x7f1d062b2f80) at e-mail-request.c:144
request = 0x7f1d0622a190
stream = optimized out
formatter = 0x7f1cb8124600
part_list = 0x7f1cb8124540
registry = optimized out
ba = optimized out
part_id = 0x0
val = optimized out
context = {message = 0x7f1d0608b810, folder = 0x7f1d057fa660,
message_uid = 0x7f1cb8110d70 183, parts = 0x7f1cb8126560, mode =
E_MAIL_FORMATTER_MODE_NORMAL, flags = 1, uri = 0x7f1d0625a5c0
mail://1357328483.21150.3/pdsdesk/INBOX/183?mode=0headers_collapsable=1headers_collapsed=0}
__PRETTY_FUNCTION__ = handle_mail_request
#11 0x7f1d000bde3e in run_in_thread (job=optimized out, c=0x7f1d062b2f80,
_data=0x7f1d0625c7d0) at
/build/buildd/glib2.0-2.34.1/./gio/gsimpleasyncresult.c:869
data = 0x7f1d0625c7d0
simple = 0x7f1d06213900
source = optimized out
#12 0x7f1d000ac236 in io_job_thread (data=0x7f1d062b4970,
user_data=optimized out) at
/build/buildd/glib2.0-2.34.1/./gio/gioscheduler.c:162
job =
Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
Hi Milan; On Mon, 2013-01-21 at 20:35 +0100, Milan Crha wrote: Yeah, I also think the backend doesn't matter. It'll be good to save the message as mbox, strip private information from it and share it at [1], which seems to be the same crash, I only wasn't able to find the message or otherwise reproduce it again. OK, I'll try to do this. The problem is that that I can't display the email at all in the preview buffer; if I even select the message Evo immediately dumps core. So saving it is a challenge. I'll try turning off the preview pane and see if I can select and save it that way. You're right about the libcamel debug: there's a separate libcamel package which doesn't have a debug variant, but when I installed the debug package for evolution-data-server it gave me the debug info for libcamel. Thanks! In case it matters, here's the trace with all debugging. It doesn't seem to be related to GMutex, but if it's a memory corruption who knows. (gdb) bt full #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1432 No locals. #1 0x7f1cffb264ee in memcpy (__len=optimized out, __src=0x7f1cb811a7c0, __dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 No locals. #2 g_array_append_vals (farray=farray@entry=0x7f1cdc00b730, data=data@entry=0x7f1cb811a7c0, len=len@entry=387) at /build/buildd/glib2.0-2.34.1/./glib/garray.c:419 array = 0x7f1cdc00b730 __PRETTY_FUNCTION__ = g_array_append_vals #3 0x7f1cffb27569 in g_byte_array_append (array=0x7f1cdc00b730, data=data@entry=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., len=len@entry=387) at /build/buildd/glib2.0-2.34.1/./glib/garray.c:1639 No locals. #4 0x7f1d0266916a in stream_mem_write (stream=optimized out, buffer=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., n=387, cancellable=optimized out, error=optimized out) at camel-stream-mem.c:131 priv = 0x7f1cb8109d60 nwrite = 387 #5 0x7f1d0266a3da in camel_stream_write (stream=stream@entry=0x7f1cb8109d20, buffer=buffer@entry=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., n=387, cancellable=cancellable@entry=0x7f1d062b2f80, error=error@entry=0x0) at camel-stream.c:158 class = 0x7f1c9c003e10 n_bytes = optimized out __PRETTY_FUNCTION__ = camel_stream_write #6 0x7f1d0266a991 in camel_stream_write_string (stream=stream@entry=0x7f1cb8109d20, string=string@entry=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., cancellable=cancellable@entry=0x7f1d062b2f80, error=error@entry=0x0) at camel-stream.c:265 __PRETTY_FUNCTION__ = camel_stream_write_string #7 0x7f1ce56504a8 in emfe_text_html_format (extension=0x7f1d05d97e80, formatter=0x7f1cb8124600, context=0x7f1cb81252d0, part=0x7f1cb812a040, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at e-mail-formatter-text-html.c:328 uri = 0x7f1cb811b660 mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2 str = 0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id... #8 0x7f1ce5648a55 in e_mail_formatter_format_as (formatter=formatter@entry=0x7f1cb8124600, context=context@entry=0x7f1cb81252d0, part=part@entry=0x7f1cb812a040, stream=stream@entry=0x7f1cb8109d20, as_mime_type=optimized out, cancellable=cancellable@entry=0x7f1d062b2f80) at e-mail-formatter.c:951 extension = optimized out reg = 0x7f1ca805ef40 formatters = optimized out iter = 0x7f1d05d97ec0 ok = 0 __PRETTY_FUNCTION__ = e_mail_formatter_format_as #9 0x7f1ce5648d19 in mail_formatter_run (formatter=0x7f1cb8124600, context=0x7f1cb81252d0, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at e-mail-formatter.c:124 part = 0x7f1cb812a040 ok = optimized out iter = 0x7f1cb81265b0 hdr = optimized out #10 0x7f1ce56484e8 in e_mail_formatter_format_sync (formatter=0x7f1cb8124600, parts=0x7f1cb8124540, stream=0x7f1cb8109d20, flags=1, mode=E_MAIL_FORMATTER_MODE_NORMAL, cancellable=0x7f1d062b2f80) at e-mail-formatter.c:784 context = 0x7f1cb81252d0 formatter_class
Re: [Evolution-hackers] ExchangeServer 2003: MAPI or Exchange?
On Mon, 2010-11-29 at 19:23 +, Herbert Stiftler wrote: in my company we use an Exchange server 2003. As I'm planning to switching to ubuntu, I'm interested in using evolution for email. As i see, there are two options to connect to exchange server: evolution-mapi and evolution-exchange - What are the differences between them? - Which one is more stable? - Which one is more complete? - Which one you would suggest to use? Evolution-exchange is far and away the more stable and complete, and it's definitely the one you should use. I had no problems with this backend for the last year or so that I used it; it was very stable and well-behaved. The evolution-mapi backend is (IMO) barely usable (it's NOT usable for me, and I have very minimal needs: just email and basic group calendaring). I'm not sure it works with Exchange 2003 at all. Here's the trick: evolution-exchange will not work with Exchange 2007 or above: it's a dead-end project in that sense. So you're in luck since you have Exchange 2003: use evolution-exchange and be happy. And you can hope that by the time your IT guys decide to update to Exchange 2007, the exchange-mapi backend will be working. Cheers! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Wrong factories starting after alternative installs?
Hi all; So, I've been using my makefile to build Evolution 2.32 (latest gnome-2-32 branch actually) on my Ubuntu 10.10 (Maverick) system and it's basically working. However, when I start Evolution it's invoking the wrong factory apps. To start with I run evolution --force-shutdown and verify that no Evolution processes are running at all. Then I start Evolution. Now when I look for Evolution processes I see the right Evolution front-end: psmith 18271 17539 1 15:20 ?00:00:04 /opt/evo-2.32/bin/evolution But I see this incorrect (old) psmith 26043 1 0 15:21 ?00:00:00 /usr/lib/evolution/e-addressbook-factory I did already create a file So my question is, where/how does Evolution get this factory invoked? I already have added a /etc/dbus-1/session.d/evo-2.32.conf file containing: busconfigservicedir/opt/evo-2.32/share/dbus-1/services//servicedir/busconfig which is what I had to do last time (and I've rebooted since this, by the way, for other reasons). Is this still what I need for Evo 2.32, or is there something different? Any way to debug why the other factory is being invoked instead of mine? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution build script
On Mon, 2010-11-29 at 15:00 -0500, Kenny,Vale wrote: I'm trying to build Evolution using Paul Smith's script and having virtually 0 luck. I get the following: http://pastebin.ca/2006084 I've just tried this and sure enough, there's a bug in the evolution builds. Applying this patch fixed it for me (Matt/et.al., this should be checked into the master branch for evolution): diff --git a/mail/importers/Makefile.am b/mail/importers/Makefile.am index 0c18649..f46708b 100644 --- a/mail/importers/Makefile.am +++ b/mail/importers/Makefile.am @@ -7,6 +7,7 @@ libevolution_mail_importers_la_CPPFLAGS = \ -I$(top_srcdir) \ -I$(top_srcdir)/widgets \ $(GNOME_PLATFORM_CFLAGS)\ + $(CAMEL_CFLAGS) \ $(EVOLUTION_MAIL_CFLAGS)\ -DG_LOG_DOMAIN=\evolution-mail-importer\ \ -DEVOLUTION_PRIVDATADIR=\$(privdatadir)\\ @@ -28,8 +29,10 @@ libevolution_mail_importers_la_LIBADD = \ $(top_builddir)/mail/libevolution-mail.la \ $(top_builddir)/shell/libeshell.la \ $(top_builddir)/widgets/misc/libemiscwidgets.la \ + $(CAMEL_LIBS) \ $(GNOME_PLATFORM_LIBS) \ $(EVOLUTION_MAIL_LIBS) \ - $(IMPORTERS_LIBS) + $(IMPORTERS_LIBS) \ + $(CAMEL_LIBS) -include $(top_srcdir)/git.mk ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Wrong factories starting after alternative installs?
On Mon, 2010-11-29 at 14:51 -0600, Matthew Barnes wrote: The config file looks right to me. I gave a similar example awhile back which you might try copying verbatim: http://mail.gnome.org/archives/evolution-hackers/2010-March/msg00023.html That's exactly where I got my version originally. I did, just to be sure, try copying that verbatim into session.local.conf then logging out and back in, but it didn't help. I even renamed the default factories that were being started, and now I get an error when I try to access my contacts list: Detailed error message: Error calling StartServiceByName for org.gnome.evolution.dataserver.AddressBook: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/evolution/e-addressbook-factory: Success That's to be expected I suppose but it clearly shows that dbus is not interested in my customized servicedir settings. How can I figure this out??!! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] New evo build makefile available
Hi all; I've updated my makefile for building Evolution from git: http://mad-scientist.net/evolution.html This version supports Lucid and Maverick. Note it is NOT completely tested. I was able to successfully build the 2.32 version of Evolution on Ubuntu 10.10 (Maverick), building only these packages: gtkhtml evolution-data-server evolution evolution-webcal Using this content for local.mk: DISTRO := maverick evo-VER := 2.32 BRANCH := gnome-$(evo-VER) PREFIX := /opt/evo-$(evo-VER) BRANCH_evolution-webcal := master BRANCH_libgweather := master gtkhtml_CONFIG_OPTS := --disable-deprecated-warning-flags ENABLE_libgweather := n ENABLE_exchange := n ENABLE_mapi := n ENABLE_openchange := n There are some annoying things going on in the build that I'll email about to the hackers list separately if anyone cares. I haven't tried to build Exchange support yet, nor build the current master branch (but I will). ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] issues trying to build 2.32 from git
Hi all; just wanted to give a heads-up on issues I found while trying to get my makefile working with the gnome-2.32 branch. Note I've not even attempted most of the extra add-ons like evolution-mapi etc. First, Evo 2.32 requires a newer gtkhtml, but the gtkhtml master configure.ac turns on the *_DISABLE_DEPRECATED flags by default. According to configure.ac this is billed as showing warnings if deprecated content is used, but that's not true: without these flags we get compile errors because functions are not defined, etc. I had to pass a flag --disable-deprecated-warning-flags to the gtkhtml configure to get around this. Second, there is no gnome-2.32 branch in the either the evolution-webcal or libgweather git repos, so we have to make do with master (this is a common problem, I've found, among the libraries etc.: they don't create branches when they release). Third, evolution requres a newer libgweather, but the current master libgweather reaquires GTK+ 3.0 (at least), and I don't have that and don't feel like installing all the 3.0 stuff. So I had to use --disable-weather flag to evolution. If libgweather is going to be modified to REQUIRE GTK+ (etc.) 3.0, then a gnome-2.32 branch should be created at the point where it last worked with older GTK+ (etc.). ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Patch for build failures in gnome-2.32 branch
The current head of the gnome-2.32 git branch in evolution-data-server fails to compile cleanly because necessary -I options are not provided. Not sure if this needs to be applied to the master head as well. diff --git a/calendar/backends/file/Makefile.am b/calendar/backends/file/Makefile.am index c672157..79ab777 100644 --- a/calendar/backends/file/Makefile.am +++ b/calendar/backends/file/Makefile.am @@ -44,7 +44,8 @@ test_interval_searches_LDADD = \ test_interval_searches_CPPFLAGS = \ $(AM_CPPFLAGS) \ - -I$(top_builddir)/calendar \ + -I$(top_srcdir) \ + -I$(top_srcdir)/calendar\ $(EVOLUTION_CALENDAR_CFLAGS)\ -DTEST_QUERY_RESULT=1 diff --git a/calendar/libedata-cal/Makefile.am b/calendar/libedata-cal/Makefile.am index 2b5edde..82dd911 100644 --- a/calendar/libedata-cal/Makefile.am +++ b/calendar/libedata-cal/Makefile.am @@ -121,6 +121,7 @@ e_calendar_factory_LDADD = \ test_e_sexp_SOURCES = e-cal-backend-sexp.c e-cal-backend-sexp.h test_e_sexp_CPPFLAGS = \ $(AM_CPPFLAGS) \ + -I$(top_srcdir) \ -I$(top_srcdir)/calendar\ -I$(top_builddir)/calendar \ $(EVOLUTION_CALENDAR_CFLAGS)\ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Gnome 3.0 delay Evo?
I wonder if Matthew or Milan or anyone have any thoughts on what the delay in Gnome 3.0 means for Evolution. Is the current git master buildable and usable without Gnome 3.0 components? Do you expect distros to build and ship both Gnome 2.x and 3.0 versions, to make transitions simpler? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo won't display special characters
On Mon, 2010-07-12 at 09:51 +0200, Milan Crha wrote: yup, I've this in my todo list, since 21/06/2010, but due to other work I didn't get to it yet. I'm sorry. No problem. Just to summarize, you've an issue involving https://bugzilla.gnome.org/show_bug.cgi?id=610797 that with a patch the reading is mostly fixed (when message is refetched, maybe - as I prefer the recent evolution-mapi git master due to its changes which couldn't be done in gnome-2-30, and recent openchange svn trunk (or say at least revision 1922) due to its changes with unicodeness and such, which are not part of openchange 0.9), but the patch also broke composer. To be clear, I'm seeing this with the IMAP (and IMAPX) backends, not with MAPI (it might happen with MAPI, too, but it's not MAPI-related). I'm using the gnome-2.30 branch at the moment because building master is not working for me; something related to the new Gnome 3.0 changes or whatever I suppose. I'll try to get back and get this working again soon. Since composer broke so completely I backed out the patch again after about 10 minutes and can't be sure there wasn't more, but yes, in the time that I used it I was able to read email without any problems and the only issue I noticed was the composer issue. Thanks Milan! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] IMAP vs. IMAPX in Evo 2.30--recommendations?
On Wed, 2010-06-30 at 11:03 +0100, David Woodhouse wrote: On Tue, 2010-06-29 at 15:22 -0400, Paul Smith wrote: Hi all. I'm wondering if anyone can provide a summary/recommendation for IMAP vs. IMAP+ (IMAPX) in Evo 2.30 (I'm actually building the very latest gnome-2.30 branch from git)? I use a dovecot IMAP server which I don't think supports any of the advanced IMAP features (?), Um, I'm using Dovecot to test the QRESYNC support (which I just committed to master). I have an older version than you, I guess, because I don't have all those things (although I see I do have IDLE which is nice): * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 QUOTA AUTH=PLAIN AUTH=LOGIN This is the standard IMAP server at my ISP so I can't really change it (as far as I know). What about (does anyone know) connecting to Exchange servers using Exchange's IMAP? Should I be using IMAPX there? As long as you're using 2.30.2 or later, yes. There are some IMAPX fixes in 2.30.2 which you wouldn't want to be without, including a workaround for the fact that the crappy Exchange server lies to clients about RFC822.SIZE, leading to truncated mails. Yep, I'm using the latest content of the git gnome-2.30 branch, checked out/built this morning. I've switched over so I'll let you know if there are any issues, thanks! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo won't display special characters
On Wed, 2010-04-28 at 14:14 +0200, Milan Crha wrote: On Sat, 2010-04-17 at 23:13 -0400, Paul Smith wrote: Hi all. Occasionally I get email from someone and they include a special character in the email (this is html mail). When this happens, the entire paragraph/section of that email is completely elided and only a [?] token is shown in the email, no matter how large the HTML segment is. Hi, there is filled a very similar MAPI bug here: https://bugzilla.gnome.org/show_bug.cgi?id=600386 though with respect of sanitizing incorrect letters is filled: https://bugzilla.gnome.org/show_bug.cgi?id=610797 Hi Milan; I finally got around to trying this (sorry for the delay). The patch attached to the second bug did indeed fix my problem and I was able to read my emails with only occasional ? glyphs instead of entire paragraphs elided. Yay! Unfortunately, I realized that this completely messed up the Evo composer, so that when I tried to send an email every character I typed showed that character, then 3-4 bizarre graphical glyphs afterwards. So, I had to remove the patch again. It would be really, really nice if someone could provide a patch that fixes the display issue without crushing the composer. I'll be happy to test it and hopefully it won't take me so long next time. Cheers! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Build failure on gnome-2-30 branch
Hi all; trying to build the latest git changes from the 2.30 branch gives me: make[4]: Entering directory `/opt/src/evo/evo-2.30/obj/evolution/smime/lib' CC libessmime_la-e-cert.lo CC libessmime_la-e-cert-db.lo CC libessmime_la-e-pkcs12.lo CCLD libessmime.la .libs/libessmime_la-e-cert-db.o: In function `initialize_nss': /opt/src/evo/evo-2.30/obj/evolution/smime/lib/../../../../evolution/smime/lib/e-cert-db.c:210: undefined reference to `camel_init' collect2: ld returned 1 exit status make[4]: *** [libessmime.la] Error 1 make[4]: Leaving directory `/opt/src/evo/evo-2.30/obj/evolution/smime/lib' Another nit (just a warning, not failure): make[5]: Entering directory `/opt/src/evo/evo-2.30/obj/evolution/shell' CC libeshell_la-e-shell.lo CC libeshell_la-e-shell-backend.lo CC libeshell_la-e-shell-content.lo CC libeshell_la-e-shell-searchbar.lo CC libeshell_la-e-shell-utils.lo CC libeshell_la-e-shell-view.lo CC libeshell_la-e-shell-window.lo CC libeshell_la-e-shell-window-private.lo CC libeshell_la-e-shell-migrate.lo CC libeshell_la-e-shell-window-actions.lo CCLD libeshell.la CC evolution-e-config-upgrade.o CC evolution-main.o ../../../evolution/shell/main.c: In function 'idle_cb': ../../../evolution/shell/main.c:262: warning: assignment discards qualifiers from pointer target type CCLD evolution ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo 2.30 git branch: not junk icon enormous?
On Thu, 2010-04-29 at 17:28 -0400, Matthew Barnes wrote: Log into Bugzilla, go to Preferences - Email Preferences and make sure things are set the way you want. I did, and they were, but I'm not getting any email. I take it your response means you are getting bugzilla mail? I was wondering if it was a problem with their mail server in general, or if it was just me. Thanks for the fix! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-mapi is failing to compile on gnome-2.30 branch
On Mon, 2010-04-26 at 14:37 +0200, Milan Crha wrote: you've too new OpenChange, the API for this function changed. It is fixed on master, and now on gnome-2-30 too. Please update your git repo or download 0.30.1 tar-ball. Thanks Milan; I'm trying it now... and success! Thanks. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evo 2.30 git branch: not junk icon enormous?
Hi all. I finally succeeded in building Evo from the gnome-2.30 git branch head, and It's running. One thing I notice is that the not junk icon is really huge: about twice as high, it looks like, as the other icons (it's a crumpled piece of paper in an inbox tray, with a red x button overlayed). This causes my icon menu bar AND the next one (with the Show/Search stuff) to be extra-high and funny looking. Any thoughts on this? I can attach a screenshot if you like. Anyone else see it? Maybe there's something wrong with my installation? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-mapi is failing to compile on gnome-2.30 branch
Hi all; trying to build the gnome-2.30 branch of the evolution-mapi component is currently failing to compile: make[3]: Entering directory `/home/src/evo/evo-2.30/obj/evolution-mapi/src' Making all in libexchangemapi make[4]: Entering directory `/home/src/evo/evo-2.30/obj/evolution-mapi/src/libexchangemapi' CC exchange-mapi-folder.lo CC exchange-mapi-connection.lo ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c: In function 'exchange_mapi_connection_fetch_item': ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:1492: warning: pointer targets in assignment differ in signedness ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c: In function 'exchange_mapi_events_init': ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:3160: error: too few arguments to function 'RegisterNotification' make[4]: *** [exchange-mapi-connection.lo] Error 1 make[4]: Leaving directory `/home/src/evo/evo-2.30/obj/evolution-mapi/src/libexchangemapi' Help? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GIT master failing evolution-data-server build...
Hi all. Trying to build the current git master of evolution-data-server is failing to link test-ebook-remove: Making all in ebook make[5]: Entering directory `/home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook' CC libebook_test_utils_la-ebook-test-utils.lo CCLD libebook-test-utils.la CC test_ebook_remove-test-ebook-remove.o CCLD test-ebook-remove ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o): In function `ebook_test_utils_book_async_add_contact': /home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:160: undefined reference to `g_malloc0_n' ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o): In function `ebook_test_utils_book_async_commit_contact': /home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:215: undefined reference to `g_malloc0_n' ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o): In function `ebook_test_utils_book_async_get_contact': /home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:276: undefined reference to `g_malloc0_n' ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o): In function `ebook_test_utils_book_async_get_required_fields': /home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:334: undefined reference to `g_malloc0_n' ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o): In function `ebook_test_utils_book_async_get_supported_auth_methods': /home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:411: undefined reference to `g_malloc0_n' ./.libs/libebook-test-utils.a(libebook_test_utils_la-ebook-test-utils.o):/home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook/../../../../../evolution-data-server/addressbook/tests/ebook/ebook-test-utils.c:469: more undefined references to `g_malloc0_n' follow ../../../addressbook/libebook/.libs/libebook-1.2.so: undefined reference to `g_malloc_n' collect2: ld returned 1 exit status make[5]: *** [test-ebook-remove] Error 1 make[5]: Leaving directory `/home/psmith/src/evo/evo-master/obj/evolution-data-server/addressbook/tests/ebook' This failed yesterday too, FWIW. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Failing to configure libgdata from git master?
Hi Philip; all the docs I saw for libgdata list just your address as a contact; if there's a mailing list or similar you'd like me to CC please let me know. I maintain a makefile that allows people to build Evolution from the latest git sources along with a significant chunk of other Gnome (and some non-Gnome) libraries that Evo also uses. One of the new requirements for the latest Evo git master is libgdata. It requires 0.6.3 or above, but the version that comes on my Ubuntu (9.04) box is 0.4.0, so too old. So, I've added support for building libgdata from git to my makefile... or started to. The checkout of the git code works fine but the configure command fails right away: Running config for libgdata /usr/bin/gnome-autogen.sh checking for autoconf = 2.53... testing autoconf2.50... not found. testing autoconf... found 2.64 checking for automake = 1.9... testing automake-1.11... found 1.11 checking for libtool = 1.5... testing libtoolize... found 2.2.6 checking for glib-gettext = 2.2.0... testing glib-gettextize... found 2.25.0 checking for intltool = 0.30... testing intltoolize... found 0.41.0 checking for pkg-config = 0.17.1... testing pkg-config... found 0.22 checking for gtk-doc = 1.0... testing gtkdocize... found 1.11 Checking for required M4 macros... introspection.m4 not found ***Error***: some autoconf macros required to build gdata were not found in your aclocal path, or some forbidden macros were found. Perhaps you need to adjust your ACLOCAL_FLAGS? Looking around I found copies of introspection.m4 in the git source trees for atk and gtk+. However, neither of those packages install that file as part of their normal builds. I think if you need this you should be including it in the sources of libgdata, or else maybe file a bug against gtk+ or similar asking them to install it during their builds? I worked around this locally by manually copying introspection.m4 from gtk+ into my target $prefix/share/aclocal, where autoconf found it. Thanks! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failing in the gnome-2.30 branch
On Thu, 2010-04-08 at 14:08 -0400, Matthew Barnes wrote: On Thu, 2010-04-08 at 12:23 -0400, Paul Smith wrote: Hi all; I'm trying to build the gnome-2.30 branch using my makefile and I'm getting this compile error (last build was successful from this branch, last week or so): Mea culpa. Try it again with this commit: Works now, thanks! ___ evolution-hackers mailing list evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evo master branch depends on gtk+ 2.20, but no git tag?
Hi all. The Evo master git branch now has a dependency on gtk+ 2.20, but when I go to the gtk+ GIT repository there is no branch for gtk-2.20. http://git.gnome.org/browse/gtk+/ shows a branch for gtk-2-18 and gtk-2-90. Is there a branch for bugfixes, etc. to gtk+ 2.20? Or should I be using master for this? Or...? Cheers! ___ evolution-hackers mailing list evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution master does not build
On Mon, 2010-03-15 at 19:17 -0400, Matthew Barnes wrote: On Mon, 2010-03-15 at 18:25 -0400, Paul Smith wrote: Hi Matt; where were they committed? I pulled the latest git HEAD and I don't see these changes... see my previous email (sorry I posted without reading this but my Evo has been offline so I could rebuild it :-p :-)) Maybe they went onto a branch or something? I'm no git expert so I'm not sure how to check this. Does everyone else see this change? Bah, I fixed the wrong Makefile.am. Try it again. http://git.gnome.org/browse/evolution/commit/?id=ab9d256343093b6dc7002c4242230c241dc3a353 Better, but still fails later on in evolution/capplet directory itself. Adding this patch allows all to work: diff --git a/capplet/Makefile.am b/capplet/Makefile.am index 51e17dc..196f62a 100644 --- a/capplet/Makefile.am +++ b/capplet/Makefile.am @@ -59,5 +59,6 @@ evolution_settings_LDADD =\ $(top_builddir)/widgets/misc/libemiscwidgets.la \ $(top_builddir)/filter/libfilter.la \ $(top_builddir)/mail/libevolution-mail.la \ - $(top_builddir)/capplet/settings/libevolution-mail-settings.la - + $(top_builddir)/capplet/settings/libevolution-mail-settings.la \ + $(top_builddir)/shell/libeshell.la \ + $(top_builddir)/e-util/libeutil.la ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Build failure on git HEAD
Hi all; the latest changes in caplet/settings are not compiling properly. I just pulled the very latest git HEAD as of 6pm EDT; I saw Matt's change regarding link libraries but that didn't help my builds (I tried a completely clean rebuild) (run with AM_V_CCLD= so we can see the command): /bin/sh ../../libtool --silent --tag=CC --mode=link ccache gcc -DANJAL_SETTINGS -g -Wl,--no-undefined -o libevolution-mail-settings.la -rpath /opt/evo-master/lib/evolution/2.30 libevolution_mail_settings_la-mail-settings-view.lo libevolution_mail_settings_la-mail-account-view.lo libevolution_mail_settings_la-mail-view.lo libevolution_mail_settings_la-mail-capplet-shell.lo libevolution_mail_settings_la-mail-decoration.lo libevolution_mail_settings_la-anjal-mail-view.lo libevolution_mail_settings_la-mail-guess-servers.lo -L/opt/evo-master/lib -L/lib -lcamel-provider-1.2 -lcamel-1.2 -lsqlite3 -lgtkhtml-editor -lgtkhtml-3.14 -lenchant -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -ldl -ledataserverui-1.2 -lgtk-x11-2.0 -lebook-1.2 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -ledataserver-1.2 -ldbus-glib-1 -lxml2 -lgconf-2 -lsoup-2.4 -lgio-2.0 -lgmodule-2.0 -ldbus-1 -lpthread -lrt -lgobject-2 .0 -lglib-2.0-lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl-pthread -L/opt/evo-master/lib -L/lib -ledataserverui-1.2 -lgtk-x11-2.0 -lebook-1.2 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -ledataserver-1.2 -ldbus-glib-1 -lxml2 -lgconf-2 -lsoup-2.4 -lgio-2.0 -lgmodule-2.0 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0-lcanberra-gtk -lcanberra -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -L/opt/evo-master/lib -lgtkhtml-3.14 -lgtk-x11-2.0 -lenchant -lgconf-2 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -L/opt/evo-master/lib -L/lib -ledataserverui-1.2 -lebook-1.2 -ledataserver-1.2 -ldbus-g lib-1 -lxml2 -lsoup-2.4 -ldbus-1 -lpthread -lrt -lgtkhtml-editor -lgtkhtml-3.14 -lgtk-x11-2.0 -lenchant -lgconf-2 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -pthread -L/opt/evo-master/lib -lgthread-2.0 -lrt -lgconf-2 -lgnomecanvas-2 -lart_lgpl_2 -lxml2 -lgnome-desktop-2 -lstartup-notification-1 -lunique-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 ../../widgets/misc/libemiscwidgets.la ../../filter/libfilter.la ../../mail/libevolution-mail.la .libs/libevolution_mail_settings_la-mail-settings-view.o: In function `msv_delete_account': /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-settings-view.c:110: undefined reference to `e_get_account_list' .libs/libevolution_mail_settings_la-mail-settings-view.o: In function `mail_settings_view_construct': /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-settings-view.c:209: undefined reference to `e_get_account_list' .libs/libevolution_mail_settings_la-mail-account-view.o: In function `mail_account_view_construct': /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-account-view.c:667: undefined reference to `e_shell_get_default' /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-account-view.c:667: undefined reference to `e_shell_get_express_mode' .libs/libevolution_mail_settings_la-mail-capplet-shell.o: In function `mail_capplet_shell_construct': /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-capplet-shell.c:356: undefined reference to `e_get_user_data_dir' .libs/libevolution_mail_settings_la-mail-capplet-shell.o: In function `setup_abooks': /opt/src/evo/evo-master/obj/evolution/capplet/settings/../../../../evolution/capplet/settings/mail-capplet-shell.c:405: undefined reference to `e_get_user_data_dir' collect2: ld returned 1 exit status make[4]: *** [libevolution-mail-settings.la] Error 1 make[4]: Leaving directory `/opt/src/evo/evo-master/obj/evolution/capplet/settings' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/src/evo/evo-master/obj/evolution/capplet' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/src/evo/evo-master/obj/evolution' make[1]: *** [all] Error 2 make[1]: Leaving directory
Re: [Evolution-hackers] Another build failure
On Mon, 2010-02-08 at 07:09 -0500, Reid Thompson wrote: Works now, thanks. I'm updating my web page related to my Makefile. I'm not sure how difficult it would be to get it working on Red Hat. I would think not very hard, all the dependencies should already be there. Getting it to work on gentoo was easy enough. I set distro to empty and to install in /opt/evo. I'll update and kick of a build this morning also. I put up the latest Makefile version, and updated the build page for it. http://mad-scientist.net/evolution.html Note that this version really requires you to have a modern system; for example I don't think you'll be able to use it with any version of Ubuntu before 9.10. Possibly with 9.04, but definitely not anything earlier. This is because Evo now relies on a new libxml2, and SO MANY things link with that: if you rebuild libxml2 for the local Evo install then a huge number of other standard libraries Evo links with also have to be rebuilt otherwise Badness Happens. I started down the path of adding entries in the Makefile for all of them but I got tired and gave up. Who knows, maybe I was almost there; if this is really something you want I'm happy to describe how you can keep going and get everything built that you need. I should also mention that this makefile pulls and builds against the very latest openchange libraries from the Samba SVN repository. That has caused issues in the past although the Evo team has been great about fixing them. Just FYI. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Another build failure
On Sun, 2010-02-07 at 16:36 -0500, Matthew Barnes wrote: I still can't reproduce these build failures myself for some reason, so if you could verify there are no more linking problems I'd appreciate it greatly since we have a release tomorrow. Works now, thanks. I'm updating my web page related to my Makefile. I'm not sure how difficult it would be to get it working on Red Hat. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Build failing in evolution/shell in latest MASTER git
Hi all; I just did an update of my git workspaces and tried a clean build, and the compile of evolution is failing in the evolution/shell directory, as below. I do have libunique 1.1.2-1 installed, including the dev package, so the configure test passes and even the compilation works as you can see. It seems like the link line, at least for the libeshell.so, is not correctly including libunique as a prerequisite? CCLD libeshell.la .libs/libeshell_la-e-shell.o: In function `shell_finalize': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:613: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:613: undefined reference to `unique_app_is_running' .libs/libeshell_la-e-shell.o: In function `shell_constructed': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:635: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:635: undefined reference to `unique_app_is_running' .libs/libeshell_la-e-shell.o: In function `shell_message_handle_new': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:653: undefined reference to `unique_message_data_get_text' .libs/libeshell_la-e-shell.o: In function `shell_message_handle_open': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:666: undefined reference to `unique_message_data_get_uris' .libs/libeshell_la-e-shell.o: In function `shell_message_received': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:729: undefined reference to `unique_app_get_type' .libs/libeshell_la-e-shell.o: In function `shell_class_init': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:756: undefined reference to `unique_app_get_type' .libs/libeshell_la-e-shell.o: In function `e_shell_get_type': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1139: undefined reference to `unique_app_get_type' .libs/libeshell_la-e-shell.o: In function `e_shell_create_shell_window': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1310: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1312: undefined reference to `unique_app_is_running' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1353: undefined reference to `unique_message_data_new' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1354: undefined reference to `unique_message_data_set_text' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1355: undefined reference to `unique_app_send_message' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1356: undefined reference to `unique_message_data_free' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1358: undefined reference to `unique_app_send_message' .libs/libeshell_la-e-shell.o: In function `e_shell_handle_uris': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1386: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1388: undefined reference to `unique_app_is_running' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1413: undefined reference to `unique_message_data_new' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1425: undefined reference to `unique_message_data_set_uris' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1429: undefined reference to `unique_message_data_set_uris' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1431: undefined reference to `unique_app_send_message' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1432: undefined reference to `unique_message_data_free' .libs/libeshell_la-e-shell.o: In function `e_shell_watch_window': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1469: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1469: undefined reference to `unique_app_watch_window' .libs/libeshell_la-e-shell.o: In function `e_shell_quit': /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1743: undefined reference to `unique_app_get_type' /home/psmith/src/evo/evo-master/obj/evolution/shell/../../../evolution/shell/e-shell.c:1745: undefined reference to `unique_app_is_running'
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 11:05 -0500, Jeffrey Stedfast wrote: Paul Smith wrote: On Mon, 2010-02-01 at 11:52 -0500, Jeffrey Stedfast wrote: This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc would mistakenly optimize out important sections of code when it encountered a particular trick used in a ton of places inside Evolution (EDList and pretty much everywhere custom single-linked lists are used inside at least Camel and likely other places as well). A temporary solution is to pass the -fno-strict-aliasing argument to gcc. Unfortunately, the gcc developers claim that this is not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 It is not a bug in GCC: GCC will compile a program that conforms to the C standard 100% correctly. Evolution is relying on behavior that is left as undefined by the standard. Optimizations often cause undefined code to behave incorrectly, defined as contrary to the author's intent, where non-optimized versions of the code work. That doesn't mean that the compiler has a bug. s/C standard/C99 standard/ Well, if you try adding -std=c89 to your compiles and GCC still uses this optimization, I guess I would agree that's a bug :-). In C89, a type-cast was a type-cast and had well understood and defined behavior. And in C89, aliasing was legal and widely used. Aliasing is still legal in C99, of course: it would be a completely different language if it weren't legal. However, there are restrictions on how it can be used (and result in defined behavior) that weren't present before, that's true. So while it might not /technically/ be a bug in gcc now that it's focusing on c99, it can be argued it's a bug since it broke previous behavior. Well, new optimizations OFTEN break previous behavior, if that behavior took advantage of aspects of the language that weren't defined. I'm not sure that means we should never attempt any new optimizations. It can also easily be argued that, in the case of undefined behavior, a compiler should default to doing what the other (and/or older versions of the same) compilers do. In this case, other compilers (and older versions of gcc) handle aliasing the same, but the new gcc 4.4 behavior changed. Sure, all things being equal that's obviously the right answer. The problem comes when there are actually very good reasons to change the behavior. C is actually surprisingly difficult to optimize and one of the big reasons this is so is C's aliasing requirements. You have to forgo all kinds of useful optimizations if you have to treat almost every pointer as if it could possibly alias almost every other pointer (if any two pointers might point to the same memory). This leads to very inefficient load/store behaviors, severe restrictions on the types of code hoisting you can do, etc. etc. This hurts especially on register-starved architectures like the x86. The aliasing rules introduced in C99 are not that strong (compared to other languages), but nevertheless they allow a whole new class of optimization opportunities that otherwise would not exist. For some code, the difference in the quality of the assembly produced can be stark. I'm pretty confident the GCC developers didn't add this optimization just to screw over developers for the sake of the letter of the standard. They genuinely feel that the advantages outweigh the drawbacks, and they added the -fno-strict-alias flag so that people who disagree have a solution as well. It may have been better to leave it off in -O2 and have people turn it on if they wanted it, rather than vice versa; I don't know. That's why I say it's really a QOI issue. Hence why I call it a bug ;-) Potayto, potahto! :-) Anyway, I agree with you that if Evo makes use of this type of aliasing then we should definitely add that flag to the default makefile flags. Configure can check for it and use it if present. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 14:30 -0500, Jeffrey Stedfast wrote: Matthew Barnes wrote: On Tue, 2010-02-02 at 12:27 -0500, Paul Smith wrote: Anyway, I agree with you that if Evo makes use of this type of aliasing then we should definitely add that flag to the default makefile flags. Configure can check for it and use it if present. Done. Although, I imagine many distros have already disabled strict aliasing optimization due to all the compiler warnings we used to have about it. If GCC or even LLVM ever learns to detect cases like what Jeff ran into and -warn- about them, I'd love to know about it so I can it to our already lengthy list of warning flags we build with by default now. If you want to get warnings about the aliasing stuff, it seems that -Wstrict-aliasing=2 is the one you want. Yep, as Jeff points out GCC does provide warnings; in fact, -Wall already includes -Wstrict-aliasing=3 which is the least aggressive level. Note this is another of those warnings (like variables used before initialized) which only can be seen when you build with optimization on. You should check the GCC docs for details before choosing a particular value. The problem is that these warnings can be false positives, that's why there are different levels of aggressiveness. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Build failures with latest git in evolution-mapi
Hi all; Since the openchange project recently added a new feature, I think there are compile problems in evolution-mapi. Doing a full git upgrade (and svn upgrade of openchange) an hour or two ago, then a complete clean build, I get these warnings (the warnings MIGHT have been there before, I can't remember) and then the compile errors, which definitely were not there before. Hopefully this can be resolved soon so I can continue my testing of Evo 2.29. Cheers! CC exchange-mapi-utils.lo In file included from /opt/evo-master/include/util.h:26, from /opt/evo-master/include/ndr.h:32, from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/charset.h:125: warning: redundant redeclaration of 'strchr_m' /opt/evo-master/include/charset.h:104: note: previous declaration of 'strchr_m' was here In file included from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/ndr.h:517: warning: redundant redeclaration of 'ndr_print_bitmap_flag' /opt/evo-master/include/ndr.h:516: note: previous declaration of 'ndr_print_bitmap_flag' was here In file included from /opt/evo-master/include/gen_ndr/exchange.h:9, from /opt/evo-master/include/libmapi/libmapi.h:57, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/gen_ndr/ndr_misc.h:12: warning: redundant redeclaration of 'ndr_print_GUID' /opt/evo-master/include/ndr.h:375: note: previous declaration of 'ndr_print_GUID' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:17: warning: redundant redeclaration of 'ndr_push_policy_handle' /opt/evo-master/include/ndr.h:493: note: previous declaration of 'ndr_push_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:18: warning: redundant redeclaration of 'ndr_pull_policy_handle' /opt/evo-master/include/ndr.h:492: note: previous declaration of 'ndr_pull_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:19: warning: redundant redeclaration of 'ndr_print_policy_handle' /opt/evo-master/include/ndr.h:494: note: previous declaration of 'ndr_print_policy_handle' was here ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c: In function 'utf8tolinux': ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: error: implicit declaration of function 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: nested extern declaration of 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: assignment makes pointer from integer without a cast make[4]: *** [exchange-mapi-utils.lo] Error 1 make[4]: Leaving directory `/opt/src/evo/evo-master/obj/evolution-mapi/src/libexchangemapi' ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-mapi exchange 2007 fails to send messages encoding in non-english characters
On Mon, 2010-02-01 at 11:37 +0100, Milan Crha wrote: On Fri, 2010-01-29 at 01:04 -0800, Fred Liu wrote: Is there anyone who has ever met this? Hi, there have been some bug reports in https://bugzilla.gnome.org but the fix came to the quite recent: https://bugzilla.gnome.org/show_bug.cgi?id=608320 Hi Milan; in addition to that issue (I'll try to test this early this week, thanks for the fix!) you can see the Fred is suffering from another bug I reported and still see; this one: https://bugzilla.gnome.org/show_bug.cgi?id=607107 It would be great if someone can investigate this as well. Having these attachments added means, really, I can't use Evo for sending mail through the Exchange server (would you accept that behavior in all the email you send?) Cheers!! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Git MASTER won't build
Hi all; someone (POC?) mentioned this a few hours ago but silly me, I didn't notice and tried to grab the latest stuff to test some of the bug fixes going in. Currently the git master is quite broken; I'm getting compile errors due to diff3 fragments left in the code: # modified: calendar/gui/cal-editor-utils.c # modified: calendar/gui/e-calendar-view.c # modified: calendar/gui/e-memo-table.c It looks like these, at least, were caused by Fridrich's commit this morning. Then, after fixing this (I just removed the changes) I got this makefile error: make[5]: Entering directory `/opt/src/evo/evo-master/obj/evolution/plugins/mail-to-task' CC liborg_gnome_mail_to_task_la-mail-to-task.lo make[5]: *** No rule to make target `../../calendar/gui/libevolution-cal-shared.la', needed by `liborg-gnome-mail-to-task.la'. Stop. Anyone have any thoughts about this? BTW, I just noticed that there seem to be some .in files that aren't checked into git; doing a git status in my evolution tree shows these external files: # Untracked files: # (use git add file... to include in what will be committed) # # calendar/conduits/calendar/Makefile.in # calendar/conduits/common/Makefile.in # calendar/conduits/memo/Makefile.in # calendar/conduits/todo/Makefile.in Personally in my projects I never commit the .in files (I don't commit translation files either: I have my makefiles dynamically download the latest every time I build a kit, which saves all those translation commits), but it seems like the standard practice in Gnome (or at least Evo) is to commit them so maybe these should be added? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Git MASTER won't build
On Thu, 2010-01-28 at 16:30 -0500, Paul Smith wrote: Then, after fixing this (I just removed the changes) I got this makefile error: make[5]: Entering directory `/opt/src/evo/evo-master/obj/evolution/plugins/mail-to-task' CC liborg_gnome_mail_to_task_la-mail-to-task.lo make[5]: *** No rule to make target `../../calendar/gui/libevolution-cal-shared.la', needed by `liborg-gnome-mail-to-task.la'. Stop. Anyone have any thoughts about this? I backed out Fridrich's change to plugins/mail-to-task/Makefile.am and that fixed the problem. Cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mail address validation
On Thu, 2010-01-21 at 20:17 +0100, Roberto -MadBob- Guido wrote: In the first version of the patch ( http://bugzilla-attachments.gnome.org/attachment.cgi?id=146701 ) I've provided a routine built on regular expressions (regcomp() and regexec()). Opinions about that? Please read my comment to the bug report, that I just added this morning. As Tobias mentions that RE is way too restrictive. My suggestion was this: ^[^;, \...@[-_.a-za-z0-9]+$ https://bugzilla.gnome.org/show_bug.cgi?id=213724 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting a core in latest git Evolution view Junk folder
On Thu, 2010-01-07 at 13:13 +0100, Milan Crha wrote: I'm on actual master as well, and I do not see this. I tried to select Junk folder of my IMAP account, under On This Computer, but none of these exhibits your issue. To be clear, it doesn't happen to me ALL the time. Only sometimes; maybe with certain email in my Junk folder? Since the failure appears to be related to determining something about attachments. I was using a build I did a few days ago just fine, then suddenly this started happening. I updated to the latest git (without changing anything in my account) and built that and it still happened. What account type is your Junk folder from? Do it all Junk folders or only some of them? When you close evolution and move out (do not delete it) folders.db file for that account, will it fix itself? I've no doubt I can fix it in various ways, I was just wondering if there was any information anyone wants me to collect before I do. As I mentioned, it's connecting to an IMAP server. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting a core in latest git Evolution view Junk folder
On Thu, 2010-01-07 at 14:50 +0100, Milan Crha wrote: On Thu, 2010-01-07 at 08:04 -0500, Paul Smith wrote: ... Since the failure appears to be related to determining something about attachments. ... As I mentioned, it's connecting to an IMAP server. Oh, my fault, IMAP with mail with an attachment in junk folder. I can reproduce it too, with a message as an attachment. Please file a bug report about it. Thanks. OK done: https://bugzilla.gnome.org/show_bug.cgi?id=606316 Cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Getting a core in latest git Evolution view Junk folder
Hi all. I have a situation in the very latest git Evolution built earlier today (also happened with my previous build which was a few days old). Whenever I click on my Junk folder Evo dumps core. It seems to be an error displaying the summary of my Junk folder. I'm avoiding it right now. FYI, this was compiled with -O0 -g on my Ubuntu 9.10 system, fully up-to-date. In addition to Evo et.al. I also build the latest gtkhtml, libxml2, libsoup, libgweather, samba4 and openchange. I'm connecting to a Dovecot IMAP server over SSL. Here's some stack info, followed by a bit of spelunking. It looks like the results returned from camel_folder_summary_uid() in efhd_attachment_button() are bogus; we're getting back a CamelMessageInfo pointer which looks OK, but then when we cast it into a CamelMessageInfoBase we see the rest of the structure it points to seems to be garbage. This has happened to me before (recently) as well. That time I was able to get into the junk folder and delete/expunge and it was fixed. If this doesn't seem familiar to anyone I'll file a bug report. Does anyone want more details than this? I'm willing to provide them! Core was generated by `/opt/evo-master/bin/evolution'. Program terminated with signal 11, Segmentation fault. #0 0x7f05ac1181c7 in match_content_type (info_ctype=0x25, ctype=0x2e49d00) at ../../../evolution-data-server/camel/camel-folder-summary.c:5066 5066if (!compare_strings (info_ctype-type, ctype-type)) (gdb) bt #0 0x7f05ac1181c7 in match_content_type (info_ctype=0x25, ctype=0x2e49d00) at ../../../evolution-data-server/camel/camel-folder-summary.c:5066 #1 0x7f05ac1182a1 in camel_folder_summary_guess_content_info (mi=0x7f05981c2990, ctype=0x2e49d00) at ../../../evolution-data-server/camel/camel-folder-summary.c:5089 #2 0x7f05a2829ad1 in efhd_attachment_button (efh=0x1f63380, eb=0x274ccb0, pobject=0x7f05982be5a0) at ../../../evolution/mail/em-format-html-display.c:812 #3 0x7f05a2824a74 in efh_object_requested (html=0x2173e60, eb=0x274ccb0, efh=0x1f63380) at ../../../evolution/mail/em-format-html.c:1519 #4 0x7f05b29e3819 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x225f690, return_value=0x7fff71920670, n_param_values=2, param_values=0x2479360, invocation_hint=0x7fff719204e0, marshal_data=0x0) at ../../../gtkhtml/gtkhtml/htmlmarshal.c:81 #5 0x7f05ae1015ae in IA__g_closure_invoke (closure=0x225f690, return_value=0x7fff71920670, n_param_values=2, param_values=0x2479360, invocation_hint=0x7fff719204e0) at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c:767 #6 0x7f05ae116983 in signal_emit_unlocked_R (node=0x20b6620, detail=value optimized out, instance=value optimized out, emission_return=value optimized out, instance_and_params=value optimized out) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:3247 #7 0x7f05ae117bcc in IA__g_signal_emit_valist (instance=0x2173e60, signal_id=value optimized out, detail=0, var_args=0x7fff719206d0) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:2990 #8 0x7f05ae118283 in IA__g_signal_emit (instance=0x25, signal_id=48536832, detail=2553762352) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:3037 #9 0x7f05b2985321 in html_engine_object_requested_cb (engine=0x1fd7c30, eb=0x274ccb0, data=0x2173e60) at ../../../gtkhtml/gtkhtml/gtkhtml.c:549 #10 0x7f05b29e3819 in html_g_cclosure_marshal_BOOLEAN__OBJECT (closure=0x227c510, return_value=0x7fff71920b30, n_param_values=2, param_values=0x24b3210, invocation_hint=0x7fff719209a0, marshal_data=0x0) at ../../../gtkhtml/gtkhtml/htmlmarshal.c:81 #11 0x7f05ae1015ae in IA__g_closure_invoke (closure=0x227c510, return_value=0x7fff71920b30, n_param_values=2, param_values=0x24b3210, invocation_hint=0x7fff719209a0) at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c:767 #12 0x7f05ae116983 in signal_emit_unlocked_R (node=0x1dd8c10, detail=value optimized out, instance=value optimized out, emission_return=value optimized out, instance_and_params=value optimized out) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:3247 #13 0x7f05ae117bcc in IA__g_signal_emit_valist (instance=0x1fd7c30, signal_id=value optimized out, detail=0, var_args=0x7fff71920b90) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:2990 #14 0x7f05ae118283 in IA__g_signal_emit (instance=0x25, signal_id=48536832, detail=2553762352) at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c:3037 #15 0x7f05b29c6d86 in element_parse_object (e=0x1fd7c30, clue=0x2653040, attr=0x26fad12 object classid=\attachment.0x1dcddd0.4GhLr6_8166295.mixed.1\) at ../../../gtkhtml/gtkhtml/htmlengine.c:1624 #16 0x7f05b29cf6cf in parse_one_token (e=0x1fd7c30, clue=0x2653040, str=0x26fad12 object classid=\attachment.0x1dcddd0.4GhLr6_8166295.mixed.1\) at ../../../gtkhtml/gtkhtml/htmlengine.c:3975 #17 0x7f05b29c622c in new_parse_body (e=0x1fd7c30, end=0x7f05b2c4c288) at ../../../gtkhtml/gtkhtml/htmlengine.c:1429 #18
[Evolution-hackers] Code typo in current evolution-mapi git master head
Hi guys; please apply this patch to fix a build error.
Cheers!
diff --git a/src/libexchangemapi/exchange-mapi-connection.c b/src/libexchangemapi/exchange-mapi-connection.c
index c7ce8f8..76ad8b9 100644
--- a/src/libexchangemapi/exchange-mapi-connection.c
+++ b/src/libexchangemapi/exchange-mapi-connection.c
@@ -3107,7 +3107,7 @@ exchange_mapi_create_profile (const char *username, const char *password, const
d(g_print(MapiLogonProvider : succeeded \n));
retval = ProcessNetworkProfile(session, username, callback, data);
- If (retval != MAPI_E_SUCCESS) {
+ if (retval != MAPI_E_SUCCESS) {
manage_mapi_error (ProcessNetworkProfile, GetLastError(), error_msg);
g_debug (Deleting profile %s , profname);
DeleteProfile(profname);
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Openchange website/svn/etc. down?
Anyone know what's going on with Openchange? I can't reach their website, their SVN repository, etc...? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Thu, 2009-12-03 at 22:34 +0100, Thomas Novin wrote: On Mon, 2009-11-30 at 14:42 -0500, Paul Smith wrote: Hi all. I'm really confused by messages from people who say they're using Evolution with MAPI support and it's working just fine for them. I can't understand it: it's so far from working for me that there must be something I'm doing wrong or something about my environment which is very different from others. I tried evolution-mapi 2.28.1 in Ubuntu Karmic 32-bit (read bug https://bugs.launchpad.net/bugs/472552 about getting 2.28.1 in karmic). Except that all my calendar entries are off by one hour, they are one hour early I actually haven't found one bug. I have read lots of emails in different folder, looked at calendar entries back and forth. I tried this and it's a disaster. Every single attempt to connect to the Exchange 2007 server causes Evolution to dump core. I had to start it with --offline to keep it up long enough that I could delete my Exchange MAPI account. I then tried to re-add my Exchange MAPI account and the instant I clicked the Authenticate button in the add new account wizard, Evolution dumped core again. At least with the latest code on the gnome-2.28 branch (built from git) Evo doesn't crash. Of course I still have tons of bugs, but it stays up! :-) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Mon, 2009-12-07 at 14:25 -0500, Paul Smith wrote: I tried this and it's a disaster. Every single attempt to connect to the Exchange 2007 server causes Evolution to dump core. I had to start it with --offline to keep it up long enough that I could delete my Exchange MAPI account. I vaguely remembered that you have to use the Exchange server IP address, not hostname (lame!!) so I tried that and I did get it to connect without crashing this time (uber-lame!!) However, I still see some of the same problems as before: about half of my inbox has no subject line listed in the summary window. The calendar does seem to work better but there are still a number of meetings missing that should be there. I can't query free/busy information on other attendees when I create meetings (critically important!) I haven't tried things like sending meeting invites. Any email I send to external addresses still has the TNEF attachment. GAL seems to actually work with this, though, which is nice! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Tue, 2009-12-08 at 08:47 +0530, Johnny Jacob wrote: I vaguely remembered that you have to use the Exchange server IP address, not hostname (lame!!) so I tried that and I did get it to connect without crashing this time (uber-lame!!) This crash seems to be a issue with the specific distro builds. In suse, this was solved with compiler flags such as -Bsymbolic (nasty!) Odd. If I build Evo myself from source (latest gnome-2.28 git branch and/or latest master git branch) I don't have this problem: using the FQDN works just fine (that's why I'd forgotten about needing to do this). In addition to Evo and its parts, I'm also compiling gtkhtml, libsoup, libxml2, and openchange from source. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Openchange website/svn/etc. down?
On Mon, 2009-12-07 at 12:19 -0500, Suman Manjunath wrote: On Mon, 2009-12-07 at 10:30 -0500, Paul Smith wrote: Anyone know what's going on with Openchange? I can't reach their website, their SVN repository, etc...? Seems to be up again now. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Fri, 2009-12-04 at 09:30 +, Ross Burton wrote: You installed evolution-data-server into a prefix that DBus doesn't know about, so it can't autostart the daemons. Huh. Well, that could definitely be a major part of my problem :-) The question is, isn't there any way to provide a local configuration to d-bus, similar to the BONOBO_ACTIVATION_PATH in bonobo? I looked and it seems that there's a local user dbus-daemon that's started, but it still reads the system session.conf file. And I looked in the session.conf file and it includes session-local.conf which is supposed to be what you customize, if you need to customize dbus locally... but that file appears to be defined to live in /etc/dbus-1 and so it's not REALLY a per-user customizable file. Is there nothing in dbus that lets the user configure things, without requiring root privileges? Thanks! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
Hey Reid; what did you have to do to get this working? I tried modifying my configuration then sending HUP to both the system dbus-daemon and my local dbus-daemon, but when I restart evo I still don't see any extra factory applications start. Did you have to kill them outright? Do they restart? Did you just log out/back in? Reboot? I don't know why the e-d-s-2.28 stuff would start if you're running off of the master branch, since those (IIRC) are bonobo services and we shouldn't be using bonobo anymore? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] MAPI support not even close... ?!?! Can I help?
Hi all. I'm really confused by messages from people who say they're using Evolution with MAPI support and it's working just fine for them. I can't understand it: it's so far from working for me that there must be something I'm doing wrong or something about my environment which is very different from others. As you may know, I've been using Evo with Exchange support for many years, and helped track down (and even fixed a couple of) bugs in the OWA backend. I do know my way around :-). However, about a year ago my company switched from Exchange 2003, which worked great for me with Evo OWA backends circa that timeframe (2.24 or so), to Exchange 2007. Since then I've been running lookOut! in Crossover Linux, which works but is sucky in so many ways. Recently I decided to try again and got my makefile working to build newer versions of Evo from git. My first attempt led to my entire Exchange server Inbox being deleted without warning when I accidentally pressed CTRL-E :-(. After I discovered that such a serious bug had been reported more than two releases ago but never fixed I was put off enough to give up again. After a couple of days off and plenty of turkey, I was mellow enough to give it another try... but it's so fundamentally not working I'm not sure if it's even appropriate to file bugs at this point. Details: I'm running on Ubuntu 9.10 64bit. I am building from the latest git master branch, updated as of this morning, for the following Gnome packages: evolution evolution-data-server evolution-exchange evolution-mapi evolution-webcal gtkhtml libgweather libsoup libxml2 (not in that order obviously). Other libs/etc. are being taken from the *-dev packages provided by Ubuntu (so they're 2.28 versions). The builds install everything into a separate directory (/opt/evo-master) so there's no interference with any libraries installed in /usr on my system. I run Evo via a script that configures PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, and even BONOBO_ACTIVATION_PATH (although I don't think that's needed any longer) to use my version. I've tried building the latest code checked out from the Evo 2.28 git branch, by the way, with similar results. I'm also building and using the latest openmapi code checked out from their SVN trunk as of this morning. I've checked compile lines and .deps files, etc. to verify that I'm using the proper headers, etc. Here's what happens: First, using this version with my personal IMAP account works fine, modulo a few graphical glitches (not remembering window sizes, etc.) I add a new Evolution MAPI account, and enter my Exchange server address etc. It asks me to log into the server to verify my password and this all works fine. After the account creation is set up, things seem fine at first glance: I can see all my Exchange folders etc. But it goes downhill from there. - Missing Subject: content: First, I got an error in the message bar trying to load my main Inbox (just said error--no details). Now I see all the messages that are in my Inbox, but at least half of them have no Subject: shown in the summary window. I do see the From: address, date, even the attachment paper clip is there... but no Subject. If I click on these messages they are displayed OK, but this doesn't add a subject to the summary either. New email I get seems to (small sample size) always have a summary, so it's just retrieving historical email that's problematic I guess. I tried deleting ~/.evolution/mail/mapi/*/folders.db, restarting, etc. but that didn't help; I suppose there's something else I should be deleting to try to get Evo to reread the summary info? - Bogus TNEF message attachment to all sent mail: If I use lookOut! to send an email message to my private account, it shows up fine as a text message. If I use Evo MAPI to send an email message to my private account, it shows up BUT instead of a simple quoted-printable message, it's multipart/mixed and there's an extra application/ms-tnef attachment; looking at the message source I see: --_000_0C8E40D1B3E28947A3EA5E185EF1C9B2B5366DF137MYEXCH01net_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable one two three --_000_0C8E40D1B3E28947A3EA5E185EF1C9B2B5366DF137MYEXCH01net_ Content-Disposition: attachment; filename=winmail.dat Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name=winmail.dat ... The bizarre thing is when I send an email from Evo MAPI to my Exchange account, it's fine: there's no TNEF attachment. So, it seems like the Exchange server is adding this attachment for me to mail that goes out to a remote address, but only for email that comes from Evo MAPI and not for email that comes from lookOut!... what's the difference here? - No calendar available: When I click on my calendar in Evo I see the MAPI calendar listed, but
Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?
On Mon, 2009-11-30 at 19:59 +, Ross Burton wrote: Considering that e-d-s master has just been ported to DBus, and evolution has just had Bonobo removed, I really recommend that you run the gnome-2-28 branches of the GNOME modules. Running master means you acknowledge that stuff may well be broken, and the Evolution modules are known to be broken (and being fixed) in lots of interesting ways. That may be true, but (a) all my IMAP accounts are (so far) working OK, and (b) I had essentially identical behavior in my MAPI account when I built the latest gnome-2.28 branches of these packages (I didn't have the missing subject problem but all the rest of the issues were the same, and I think the missing subject problem is due to some kind of glitch in the initial download of the folder data). So, I don't think the MAPI problems can be laid at the feet of the current churn in master. I chose master because, first, the fixes to the critical bugs that allowed both my entire Exchange Inbox AND my entire Exchange Contacts list to be deleted from the server by Evo without so much as a warning were checked into the master branch first, and it was a week or more with no sign of them being checked into the 2.28 branch. I think they have been now. And second, because I figured developers would be happier about trying to fix issues on the current master branch rather than do bugfixing and development on the older branch. I want MAPI support to actually _work_ in Gnome 2.30. If that means running bleeding edge code I'm willing to do that. If developers prefer that I test on gnome-2.28 to avoid the overlapping change hassle that's fine too. Whatever helps most. PS. I was struck by running ps -aef | grep evo and seeing _NOTHING_ except the actual evolution binary there... bizarre! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Failing to build latest GIT code
On Wed, 2009-11-25 at 11:48 +0100, Milan Crha wrote: hrm, I would like to know why I didn't face that when doing the change there. Maybe an older gcc or something? You will only hit this if you don't already have Evo installed. If you have it installed then the link will use the installed version. Most likely that's the problem: the linker found a different libeshell somewhere on your system. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Failing to build latest GIT code
On Tue, 2009-11-24 at 12:15 -0500, Paul Smith wrote: What am I missing here? found it. Please apply this patch to fix the build: diff --git a/mail/importers/Makefile.am b/mail/importers/Makefile.am index 8851981..e25857c 100644 --- a/mail/importers/Makefile.am +++ b/mail/importers/Makefile.am @@ -29,6 +29,7 @@ libevolution_mail_importers_la_LDFLAGS = $(NO_UNDEFINED) libevolution_mail_importers_la_LIBADD =\ $(WIN32_BOOTSTRAP_LIBS) \ $(top_builddir)/e-util/libeutil.la \ + $(top_builddir)/shell/libeshell.la \ $(top_builddir)/filter/libfilter.la \ $(top_builddir)/mail/libevolution-mail.la \ $(GNOME_PLATFORM_LIBS) \ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evo master dumps core: missing GConf key
I've been using Evo from the 2.28 branch (built using my makefile). Now I wanted to switch to using Evo from the master branch. It built and installed OK, along with e-d-s, evo-mapi, openchange, etc. but, when I try to run it it dumps core immediately: (evolution:30186): e-data-server-DEBUG: Loading categories from /home/psmith/.evolution/categories.xml (evolution:30186): e-data-server-DEBUG: Loaded 29 categories evolution-shell-ERROR **: No schema for GConf key '/apps/evolution/shell/file_chooser_folder' aborting... Aborted (core dumped) I can send the backtrace but I doubt it's needed: it looks like some part of the Evo code is expecting this gconf key to already exist, but for upgrade, if nothing else, Evo will need to create this key if it doesn't exist yet. Let me know if you'd like me to try any kind of fix or workaround: for now I've dropped back to my evo 2.28 build. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo master dumps core: missing GConf key
On Tue, 2009-11-24 at 15:01 -0500, Matthew Barnes wrote: Run this as yourself (not super user): gconftool-2 --install-schema-file .../shell/apps_evolution_shell.schemas That worked, although it still dumped core until I also added the evolution-mail.schemas file. Now it starts OK. I do see a few weird things (minor glitches) in the presentation so I wonder if there are more of these I need to do? I've never needed to do this before when going to a newer version of Evo; is this supposed to happen automatically some how when a newer version starts up? Should I run --install-schema-file for all the *.schema files in that directory, just in case, or might that break things? Cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel Manifesto
On Fri, 2009-11-20 at 14:21 -0500, Jeffrey Stedfast wrote: The sqlite backend stuff could also use some work. As far as I'm aware, the tables are non-optimal. I really think it would be worthwhile engaging someone who has SQL guru on their resume and asking them for help on this. Maybe just an informative query to the sqlite mailing list will get some interest and useful responses. I know just enough SQL to know that I don't know nearly enough to write a robust, efficient SQL schema. As with security protocols, I like to leave this to the experts and just plead for their help :-) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Want to contribute to evolution-mapi
On Thu, 2009-11-12 at 00:54 +0530, Johnny Jacob wrote: On Wed, 2009-11-11 at 08:57 -0500, Matthew Barnes wrote: On Wed, 2009-11-11 at 18:09 +0530, balaji cherukuri wrote: I am a software engineer, I want to contribute to evolution-mapi. Could you give some guidance how would I proceed. Awesome! Some more pointers : http://www.go-evolution.org/MAPIProvider#Download - This page has some information on compiling evolution-mapi (Sadly it is outdated. For evolution-mapi you would need to use git. and for openchange it is still in svn) http://www.go-evolution.org/MAPI_FAQ I also have a version of my makefile, which does work and builds Evo from GIT and openchange from SVN. It will check out the latest stuff, etc. However, it is really geared towards working on Ubuntu 9.10. Trying to do development on older distros means you need to rebuild a LOT of the Gnome libraries, etc. (more than I wanted to bother with). Other (new enough) distributions would surely work, but my makefile doesn't handle them. You can run it there anyway, it's just you'll have to work out what packages you need to install on your own. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Errors logging into MAPI
On Sun, 2009-10-18 at 17:30 -0400, Paul Smith wrote: Hi all. I've been updating my Evo Makefile to build the latest 2.28 version of evolution. When I try to connect to my exchange 2007 server using MAPI, it asks for my password but then says that the login failed. It seems to work to some extent, though, because I see my folders etc. Looking at the log file I see these errors: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:2856: Leaving exchange_mapi_get_folders_list libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:139: exchange_mapi_peek_folder_list: unlock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:3106: exchange_mapi_create_profile: unlock(connect_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:134: exchange_mapi_peek_folder_list: lock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:139: exchange_mapi_peek_folder_list: unlock(folder_lock) e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have group 'Passwords-ExchangeMAPI' Anyone have any idea what need to be done to get the right group in the keyring, or if this is indeed even the right error message? I built a brand new version using my makefile and tried again, and got this same error again. After I got this in the log file, I got a new dialog asking me to re-enter my password: Unable to authenticate to Exchange MAPI server. Please enter the MAPI password for psm...@ I re-entered my password (I was leery of this because the other day I locked my account by Evo asking for my password too many times in a row) but the second time it took and worked. It doesn't seem anyone has any ideas what this problem might be? Which Key file are they talking about here, and who is supposed to create the group Passwords-ExchangeMAPI? Note I had checked the remember this password box. I haven't tried restarting Evo to see if I have to retype it again. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Core dumps from Evolution
On Wed, 2009-10-21 at 08:30 -0400, Reid Thompson wrote: if anyone knows offhand the remedy for this??? Running git checkout for openchange Initialized empty Git repository in /home/rthompso/madscientist/openchange/.git/ error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://svn.openchange.org/openchange/trunk/openchange/info/refs fatal: HTTP request failed make: *** [openchange/.git] Error 128 Something is wonky with your makefile; openchange should be using SVN, not git. There is no openchange GIT server that I'm aware of. This doesn't happen to me... I wonder if it's a difference in your version of GNU make. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Core dumps from Evolution
On Thu, 2009-10-15 at 12:07 -0400, Reid Thompson wrote: I've been building 2.28 using the previously posted modified by someone else for git version of the makefile. My last build was Oct 10, as of yesterday I think the only diffs since then were translations. Evo's been running fine for me. If you'll post me the new makefile, i'll try to get a build with it and see if there's any issues on my box. I sent an announcement to evolution-list but I think I used the wrong address so it's hung up waiting for approval :-/. I'll send you the makefile. I really whacked the hell out of it trying to get Evo 2.28 building on Ubuntu 8.04, which is pretty old... eventually I got tired of adding packages to be rebuilt and gave up. I have it working on Ubuntu 9.04 but I think I still have library version mismatches: building on Ubuntu 9.04 requires a newer libxml2... but almost everything links with libxml2 and I didn't want to rebuild almost everything; that means that some of the shared libraries I link with expect the older libxml2 and some (the ones I rebuilt) expect the newer one. I suspect this is the cause of my pain here. I might just wait a few weeks for Ubuntu 9.10 to be released, which officially supports Evo 2.28, and should resolve at least this issue. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Errors logging into MAPI
Hi all. I've been updating my Evo Makefile to build the latest 2.28 version of evolution. When I try to connect to my exchange 2007 server using MAPI, it asks for my password but then says that the login failed. It seems to work to some extent, though, because I see my folders etc. Looking at the log file I see these errors: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:2856: Leaving exchange_mapi_get_folders_list libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:139: exchange_mapi_peek_folder_list: unlock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.c:3106: exchange_mapi_create_profile: unlock(connect_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:134: exchange_mapi_peek_folder_list: lock(folder_lock) libexchangemapi-Message: ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-folder.c:139: exchange_mapi_peek_folder_list: unlock(folder_lock) e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have group 'Passwords-ExchangeMAPI' Anyone have any idea what need to be done to get the right group in the keyring, or if this is indeed even the right error message? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Core dumps from Evolution
On Sat, 2009-10-17 at 18:42 +0100, Tobias Mueller wrote:
#0 0x7f49a9ddab0a in __xmlParserInputBufferCreateFilename
(URI=0x7f4994045710
/home/psmith/.evolution/mail/config/et-expanded-imap:__paul+mad-scientist...@localhost:40993_INBOX,
enc=XML_CHAR_ENCODING_NONE) at ../../libxml2/xmlIO.c:2521
2521if (((z_stream *)context)-avail_in 4) {
I've had that a couple of month ago and the problem was a 64bit issue. I
don't know remember what exactly the issue was. Something with zlib and
libxml not building wide enough filepointers or so. Anyway, adding
module_autogenargs['libxml2'] = autogenargs + '
CFLAGS=-D_LARGEFILE64_SOURCE'
to my ~/.jhbuildrc fixed that for me.
Hm, interesting. This is a 64bit system I'm building on (although 64bit
filesizes of course don't require 64bit systems). If this is really the
problem then that's a build error in libxml2.
I'll poke through my build logs and see if I can see anything.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Core dumps from Evolution
Hi all; I reconstituted my makefile for building Evo from scratch, and
I'm building from the latest gnome-2.28 GIT branch.
I'm seeing pretty common core dumps, all of which have the same
signature:
#0 0x7f49a9ddab0a in __xmlParserInputBufferCreateFilename
(URI=0x7f4994045710
/home/psmith/.evolution/mail/config/et-expanded-imap:__paul+mad-scientist...@localhost:40993_INBOX,
enc=XML_CHAR_ENCODING_NONE) at ../../libxml2/xmlIO.c:2521
2521if (((z_stream *)context)-avail_in 4) {
Looking into this, it appears that when we're trying to find the right
context for this URI the code is choosing the xmlGzfileOpen method, even
though this file is NOT compressed. The value we get back in context is
not NULL, but it's not a valid pointer either; the value varies quite a
bit actually.
I don't really know how this is happening; the code doesn't look wrong
to me but definitely the value of i here (iterating through
xmlInputCallbackTable) is 1, which is the compressed input method:
(gdb) p xmlInputCallbackTable[i].opencallback
$2 = (xmlInputOpenCallback) 0x7f49a9dd8eaa xmlGzfileOpen
which it shouldn't be. Very confusing.
I wonder if I have a library version mismatch issue.
Anyone have any thoughts/tips/pointers?
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] External editor plugin
On Wed, 2008-09-17 at 08:20 -0400, Reid.Thompson wrote: On Wed, 2008-09-17 at 11:22 +0530, Sankar wrote: Will such a workflow be not best done by having vi/emacs style key-bindings for the composer body area , rather than opening a external program ? Is this being implemented/considered? If so, where is it hosted? The problem with emacs-style key bindings is that, for those of use who've been using Emacs almost as long as we've been using computers, they are never complete enough. Bind-alikes are OK for some small text editing areas, but for something like email you really miss all the extra keybindings that a real Emacs gives. Don't get me wrong: some compatibility is better than none. Invoking an external editor is also useful and something I'd be interested in trying out (I used Emacs VM mode for mail for years and years before I had to connect to an Exchange server, just so I could have full Emacs editing for my mail). However, the most ideal situation that I can imagine would be to figure out how to make Emacs embeddable. Then it can become a universal editor plugin, for Evo, FireFox text boxes, Eclipse, etc. etc. Start up Emacs in the background and have applications that need an editable box contact it to create new child windows containing real Emacs buffers. I would actually cry if I could get that. :-) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Tue, 2008-07-01 at 14:12 +, Jeffrey Stedfast wrote: is anyone else getting duplicates of this message every few days? This has been going on for months and is a bit annoying. Not me. Maybe it's your local mail server? Use C-u in Evo (or select View - Message Source) and look at the Received: headers. You should be able to determine which server is resending the message by looking at the timestamps. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Crasher in evolution-exchange
Hi all; can someone take a look at this bug: http://bugzilla.gnome.org/show_bug.cgi?id=532844 Seems pretty straightfoward: we are not checking for error returns from e2k_context_get(), and simply accessing the result (which is not set, in my case, due to an error return). I don't know why my system is constantly returning this error but at this point I can't even read a single email before evo-exchange dumps core. Patch included; it seems obviously correct even without understanding why the HTTP error is being returned. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Various bugs found by valgrind
Hi all; I've been trying to help Srini find bug http://bugzilla.gnome.org/show_bug.cgi?id=512605 which is a very serious LDAP crasher that is taking down my Evo Exchange connection 3-4 times a day. As part of this I've been running evolution-exchange-server under valgrind. Unfortunately, I haven't been able to reproduce the crasher in this way (I believe it's somewhat timing dependent). However, I have found a few other bugs. These two I have reported and provided patches for: http://bugzilla.gnome.org/show_bug.cgi?id=534077 http://bugzilla.gnome.org/show_bug.cgi?id=534111 I think these should be pretty simple to verify and apply (they are in both the trunk and gnome-2.22 branch). I'm not sure if they are actually causing crashes or incorrect behavior, but they're definitely bugs. This one I can reproduce every time (so far) and have a core dump for but no other information (the core happens in evolution, not in exchange, so no valgrind info): http://bugzilla.gnome.org/show_bug.cgi?id=534082 This one I have no core, because I was running under valgrind, so all I have is the valgrind log. It shows that we tried to access memory after it was freed. I couldn't reproduce it: http://bugzilla.gnome.org/show_bug.cgi?id=534125 Hopefully someone can take a look at these. I'm sad that I can't repro the original LDAP bug, though, since that's by far the worst of all of these. I'll keep trying! I'll try it on my system at work, which is an Intel Core2 (64bit dual-core 2.4G CPUs) with 2G RAM. My system at home is just a P4 2.6G. It does have 2G though. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution Exchange invites not working
Hi all; I've just started seeing a really disabling behavior after my latest update to Ubuntu 8.04; before Tuesday or so things were working fine (well, I was getting a lot of exchange backend crashes but those haven't been fixed with the latest update either). The problem is that every meeting invite I get shows up as ONLY the plain text portion of the multipart message. The VCALENDAR attachment is not recognized and I don't get the ability to accept/decline the meeting. Not only is it not recognized as a VCALENDAR attachment, it's not noticed as any kind of attachment at all! There is no attachment button on the email that would even let me save it. But, if I use C-u and look at the message source it looks fine and I can see the calendar part. Also, my older system running Gutsy still works fine, even connecting to the exact same exchange account and looking at exactly the same invites. I've filed a bug in Launchpad, here: https://bugs.launchpad.net/ubuntu/+source/evolution-exchange/+bug/228244 The changelog for the latest update (note that evolution-exchange was NOT updated; only evolution-data-server, evolution, and evolution-plugins) is below. If anyone has ANY idea what's going on please let me know. I pretty much can't use Evo at work if I can't manage my calendar with it. Thanks! evolution-data-server (2.22.1.1-0ubuntu1) hardy-proposed; urgency=low * New upstream version: Bug Fixes: - #274316: Also copy user tags when copying messages between folders - #338330: (Novell Bugzilla) Internet Based Calendar Events Are Declined By Evolution/GroupWise - #350143: (Novell Bugzilla) Fix a severe memory leak in evolution-data-server - #358584: (Novell Bugzilla) Display of web calendars ignores timezones - #358644: (Novell Bugzilla) Retracted groupwise appointments should disappear as soon as they are retracted. - #358650: (Novell Bugzilla) International clock applet is crashing - #381307: Run a single delta-thread to fetch changes from the server, instead of spawning multiple threads - #473880: Fixed a few compiler warnings - #475616: Use recursive mutex - #502899: Fix a crash - #514300: Make sure we do the Inbox - INBOX translation at the right place - #520532: Support migration from password file to keyring (lp: #178544) - #529339: Fixed a crash when searching with an expression - #530139: Do not ship .svn files - #530323: Don't free the same variable twice Other Contributors: - Load addressbook conditionally * debian/control: - build-depends on libgnome-keyring-dev * debian/patches/80_fix_double_free_in_contacts_backend.patch: - dropped, fixed in the new version * debian/patches/90_from_svn_fix_inbox_caching_issue.patch: - dropped, fixed in the new version * debian/rules: - build using the keyring since the password are migrated automatically now -- Sebastien Bacher [EMAIL PROTECTED] Mon, 05 May 2008 12:30:29 +0200 and: evolution (2.22.1.1-0ubuntu1) hardy-proposed; urgency=low * New upstream version (lp: #226925): Bug Fixes: - #33: Add the attachments and draw the bar - #338330: (Novell Bugzilla) Internet Based Calendar Events Are Declined By Evolution/GroupWise - #358644: (Novell Bugzilla) Retracted groupwise appointments should disappear as soon as they are retracted. - #363908: Fix a crash at exit - #368277: Allow copy paste of email addresses from an appointment to a mail message - #378203: Return sanely if the path value is corrupted - #382687: (Novell Bugzilla) Fixed a deadlock when downloading data on a rather loaded system - #451976: Try to find text/html part in multipart/alternative when in normal mode - #467892: Do not inherit search filters when opening messages in new window (lp: #181387) - #502913: Make Always carbon-copy (cc) option work again (lp: #198167) - #511337: Fixed a crash when simultaneously pressing the show (lp: #192195) preview/arrow button on several very large image attachments in an e-mail. - #518103: Check online status from NetworkManager at startup instead of using the last-used-state. - #523402: Fixed a crash on paste event in calendar (lp: #220608) - #524121: Fixed a typo - #528817: Fix a typo in the logic that caused Exchange Operations disabled on startup - #529375: Look up in local address book for addresses to exclude mail sent by known contacts from junk filtering if said so - #529893: Properly set type hint on tooltip window. - #530245: Let searches work with labels again. - #530672: Fix Evolution crash when viewing pgp-signed message Updated Translations * debian/patches/62_fix_nm_offline.patch: - dropped, fixed in the new upstream version * debian/patches/90_from_svn_gfree_correct_variable.patch: - dropped, fixed in the
Re: [Evolution-hackers] Evolution Exchange invites not working
On Fri, 2008-05-09 at 15:54 +0200, Andre Klapper wrote: vague guess: edit - plugins - itip formatter is enabled? Good idea, Andre: that plugin was indeed enabled. But unfortunately disabling it doesn't seem to have done anything. I used my makefile to build the very latest content from the SVN 2.22 branch of Evolution, and this problem still exists there. So, it's not related to Ubuntu-specific builds or patches (as far as I can tell). Unless, there's some package other than gtkhtml, evolution-data-server, evolution, or evolution-exchange involved in this? I've filed a bug about it in the Gnome tracker since it's not just an Ubuntu issue: http://bugzilla.gnome.org/show_bug.cgi?id=532384 I have a full debug build with all logging, etc. enabled so if anyone wants any help working on this bug, please let me know. As long as this is not working I'm having a very hard time using Evo for my mail!! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Building Evo SVN on Ubuntu Hardy
On Wed, 2008-04-09 at 07:50 +0200, HggdH wrote: If you are interested, I have attached the patch here. This pushed me to upload my latest version, which has support for Hardy. Find it in the usual place: http://mad-scientist.us/evolution.html I tested this on an almost vanilla install of Ubuntu Hardy Beta + updates, so I think the packages are correct even for those who've not built anything on their Ubuntu boxes before. Let me know if you have problems; cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Building Evo SVN on Ubuntu Hardy
On Wed, 2008-04-09 at 16:45 +1000, Greg Vickers wrote: Will this work on Ubuntu 7.10 (Gutsy)? Yes, definitely. Up until last week I was using it on Gutsy regularly. Create a local.mk file in the same directory and put: DISTRO := gutsy there and you should be all set. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Evolution does not support message's priority?
On Wed, 2008-04-09 at 17:25 +0800, liushuai wrote: I reviewed the code of evolution and also checked all columns in evolution message list window. However, I could not find where to display the priority of new email? I could not see whether the mail was urgent or normal or non-urgent. Don't know what non-urgent is, but in every version of Evolution I've used there's a column right next to the new/read/replied icon column that marks urgent mail. On my Ubuntu system it's an orange circle with a white exclamation mark in it; I think different distros use different icon sets. To mark a mail that you received as urgent, you click in that column next to the mail. To mark a mail you want to send as urgent, you select Insert - Prioritize Message (this is, admittedly, pretty difficult to figure out). ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Evolution does not support message's priority?
On Wed, 2008-04-09 at 11:53 -0700, Lonnie Borntreger wrote: Um, wrong answer. He wanted to know if evolution supports message priority, not marking as important. Message priority allows the sender to assign a message priority from low = 5, to critical = 1 to the message in the hopes that it helps the receiver determine what emails to read first. This uses the non-standard mail header X-Priority. I don't know how it's represented underneath in the SMTP headers, but the feature I referred to DOES allow the sender to mark the message as important (using Insert-Prioritize Message). You don't get to give it a discrete level from 1 to 5; it's either important or normal. But, if the SENDER marks it this way, when the recipient gets it it's marked with the extra exclamation point icon and the summary line is in red. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy
On Tue, 2008-04-08 at 08:08 -0700, George Farris wrote: I completely agree. I know of myself and at least two others running Hardy with Evolution Exchange backend and it is unusable because the exchange backend keeps dying. Are you on 32bit or 64bit systems? Do you have multiple CPUs? It really confuses me, because as I said I've been using my makefile ( http://mad-scientist.us/evolution.html ) to build from SVN on my Gutsy system, and it runs _great_. I can't figure out what's different about Hardy that's causing this problem. -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy
On Tue, 2008-04-08 at 13:15 -0400, Paul Smith wrote: I can't figure out what's different about Hardy that's causing this problem. There was a major update to Hardy today that included all parts of Evolution, including e-d-s and evolution-exchange. The bugs listed there looked very serious: freeing null pointers and other really unpleasant things. There haven't been any changes to the gnome-2-22 branch in SVN for anything like this in quite a while, so I'm not sure where these fixes came from (or maybe more accurately, where the previous, unfixed versions came from). After the upgrade my Evo in Hardy was stable and responsive for an hour or two before I had to come home (but, now my system doesn't recognize the proper screen size for my LCD monitor... but that's another story). I'm not ready to call it fixed quite yet, but if you haven't updated lately you should do so, then see if things are any better for you. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy
On Wed, 2008-04-09 at 04:03 +0200, HggdH wrote: The fixes came from upstream indeed. They are fixes that were committed from about March 10th to April 7th (i.e., from the 2.22.00 release to 2.22.1). OK, gotcha. I incorrectly assumed that 2.22.1 was already in Hardy. I'll give it a good workout tomorrow and make sure it's stable. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution Exchange in Ubuntu Hardy
Well, I've been very excited to see Ubuntu 8.04 (Hardy Heron) about to be released, because I've been so pleased with the current version of Evo and in particular, Evo Exchange and all the improvements in stability etc. that have been made over the last year or so. As you know I've been building Evo from SVN fairly regularly and these versions really run well on my systems (32bit Intel, one hyperthreaded one not). They are fast, stable, and reliable (with the one glaring exception of to atrocious timezone handling bug). I'm eager for people to be able to enjoy this new version. So, last week I took one of the systems I've been temporarily using (Intel 64bit dual core), resized the partition, and installed Ubuntu Hardy beta, 64bit. I regret to say that Evolution (in particular Exchange, because I didn't try any other servers) is a complete disaster as it currently stands on this system. I can't keep it running and connected to my Exchange server for more than a few hours at best, and often it won't stay up for more than a few minutes. The Exchange backend is dying (but no cores that I can see and no messages in the logs), and then I get the dreaded lost connection with backend server. E-D-S goes into infinite loops and sucks up 100% of one of the CPUs. I don't know if it's 64bit machines (are others with 64bit systems having issues with Evolution?), the particular build that Ubuntu is doing of Evolution, or what in the heck is going on but this is far and away the least stable, most unusable version of Evolution I've used since 2.4 or even earlier. Unless something radical happens in the next few weeks to resolve all these problems, I regret to say that this Ubuntu Long-Term Support release will not be anywhere close to ready to deploy in an enterprise environment. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: did the slightly inflammatory subject catch your attention? Good, please keep reading... ;-) I will read your email as soon as I get a chance, but I have to add my voice to those saying please, please, PLEASE someone fix this complete and utter disaster! I was going to post a much more inflammatory rant about this than yours (although without any of your useful suggestions) today. Yesterday I had the excruciatingly embarrassing experience of walking into a conference room for an important meeting with important people at my company... about 3 minutes before everyone packed up their stuff to leave. I was an hour late!!! My Evo calendar said the meeting started at 3pm EDT, but everyone else's calendar said it started at 2pm. I went back and logged into Exchange OWA, and sure enough THAT calendar said 2pm as well. So, it's hard to understand how OWA knows the right date/time and Evolution, which uses data retrieved from OWA, doesn't. But, I've not really sat down to puzzle out how timezones are handled. It's really a brown-paper-bag situation that this should still be happening in Evolution well over a year after the timezone changes that caused the problems (in the US anyway) were approved. We run into this twice a year and it's still broken. I have many examples of Exchange meeting requests that do the wrong thing in Evo, if anyone needs them. -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution doesn't honor LC_TIME (and other LC_ variables)
On Wed, 2008-03-05 at 20:16 +0100, Raúl Núñez de Arenas Coronado wrote: Since I'm not familiar with the po files (I don't know if I can modify them directly or not) and so the work may take some time, agains which version should I make my patches? Latest stable? Latest devel? Latest SVN? Any preference? You don't need to change the po files. Change the source code. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] New version of Evo build Makefile available
Hi all; I've released version 2.00 of my makefile; you can find it here as always: http://mad-scientist.us/evolution.html I bumped the version to 2.00 because this version does non-local builds using GNU autotools' remote build capability. This means the source directories checked out from SVN should be kept pristine and cleaning the built objects is safer and more reliable. However, you need to be sure you clean out your existing builds, including the source directories (run make shinyclean if not make superclean). Have fun! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
On Thu, 2008-02-07 at 09:08 +0530, Srinivasa Ragavan wrote: IIRC Julien mentioned that to use Exchange 2007 against Outlook 2003, the Public Folder store got to be created. Evolution with libmapi would be like a Outlook 2003, connecting to Exchange 2007. What! Are we behind again already before we even caught up the first time?!?! What protocol does Outlook 2007 use, if not MAPI? Good grief. Those Microsoft folks are a pain. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
On Thu, 2008-02-07 at 00:47 +0530, Suman Manjunath wrote: to be able to use the MAPI plugin, your Exchange mailbox should be enabled for MAPI. this is a setting on the server. it is a common issue to not have it enabled. Curious. Does that mean that Outlook can talk to an Exchange mailbox WITHOUT having it enabled for MAPI? I would like to know more about this. One putative advantage of using MAPI, to me, would be that the corporate IT department wouldn't even know you're using Evolution. They wouldn't have to make ANY changes specifically for Evo users, not even to enable OWA (if they didn't have it enabled already). So, if there are still Exchange mods that have to be made beyond what's needed for Outlook users we should get in front of that I think. Cheers! -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!
On Fri, 2008-01-18 at 16:34 -0500, Jeffrey Stedfast wrote:
On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote:
I'm getting a build failure in Evo and gtkhtml with the latest
glib:
editor-control-factory.c: In function 'editor_get_prop':
editor-control-factory.c:463: error: expected expression before 'do'
Apparently, the latest glib broke the libbonobo from Gnome 2.20, so
if
you install the latest glib you also need the latest libbonobo.
you might want to warn the glib guys about this then... seems they
have broken API or ABI which is a strict no-no.
I'm happy to do this, but the change is not so straightforward.
The deal is this: in the old glib, g_assert() macros were surrounded by
G_STMT_START and G_STMT_END macros to make them look like single
statements even though they contain multiple statements. The statement
start/end macros back then had a little ifdef dance taken from Perl,
which used GCC special features if you built with GCC, or the old do {}
while(0) trick if that was checked for in the configure file, or if none
of that were true, the relatively obscure if (1) ... else (void)0
syntax.
For all Gnome builds, obviously, the GCC special capability was used.
Now, libbonobo used the g_assert() macros inside macros of their own,
that looked like this: (g_assert(...), some_other_statement()). This
is a statement that returns a value, rather than the traditional
do{}while(0) etc. methods that can only be used in a void context.
When you compiled all of this together with GCC it worked, because the
GCC macro extension used by g_assert() provides for the macro to be used
as an rvalue. If you would compile this with any compiler OTHER than
GCC, it would not work because you can't use a while loop inside a comma
expression like libbonobo is trying to do.
It's arguably a bug in libbonobo that it REQUIRES the use of GCC.
Anyway, for some reason in the newer versions of glibc the g_assert()
macro (and all its brethren) were (a) moved to a new header file
gtestutils.h, and (b) all the special Perl magic macro stuff was removed
and it uses plain do{}while(0) now. That will work the same way for all
compilers, but it breaks libbonobo's use.
The newer versions of libbonobo have changed their macros to use the GCC
syntax directly, inside their own ifdef checking for GCC. If GCC is not
set, they don't call g_assert() at all. This will now compile correctly
even on non-GCC compilers.
Soo... the old way was definitely broken: probably the real bug was
in libbonobo though. The new glib does change the API for g_assert()
_BUT_ only in such a way that shouldn't matter to any correct usage of
the macro (since any noticeable difference would have depended on using
a specific compiler).
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Warning: careful rebuilding with my makefile!!
On Fri, 2008-01-18 at 01:05 +0100, Andre Klapper wrote: just ran into the same issue, a clean checkout of libsoup fixed this. That's not good enough if you're trying to install glib somewhere other than the system default location. If you do this you have to convince autoconf to look for the glib m4 macros in that location as well or you get this error. See: http://mail.gnome.org/archives/libsoup-list/2008-January/msg5.html My makefile handles this now, though. Cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Badness in latest SVN
On Wed, 2007-12-19 at 10:37 -0500, Matthew Barnes wrote: On Wed, 2007-12-19 at 10:24 -0500, Paul Smith wrote: First, my GAL lookups have stopped working again. They were broken in the 2.12 release, but then they got fixed. Now they don't work again for me. I have a GAL server set up, and I restrict to 500 responses. When I first select that server on the contacts screen I don't see any names (this is correct I think). When I enter a name to search for, it searches forever and never returns any values. The team is working feverishly on this. Others may be able to provide status better than I can. Excellent, thanks. I'm pretty sure that my Exchange meeting notifications are also not working now with this latest version. I built a version from SVN on Dec 4, and that worked fine for both meeting notifications and for GAL. Is it useful to file bugs for these, or are they known issues and no bug necessary? -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] New version of the Evo SVN Makefile
Hi all; I've posted the latest version of my Makefile to build Evolution from SVN: http://mad-scientist.us/evolution.html This version contains some fixes I've been making locally plus some enhancements from Patrick Ohly. Changes from the previous version: * Support for Ubuntu 7.10 and Debian Etch (in addition to Ubuntu 7.04) * Easy to disable Exchange and Webcal if you don't need those * New script evolution-env that lets you run any command with the environment of the custom Evolution * All extra scripts are now contained in the Makefile; no need to download them separately * New make help that gives some details about targets and variables. Let me know if you have problems or suggestions! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] GAL password broken in SVN Evo?
On Mon, 2007-11-12 at 14:42 +0100, Milan Crha wrote: Hello, can you try to check what Authentication Type your Exchange account uses? Hm; this might have been a red herring... when I went to check the authentication type I noticed that somehow the GAL server field had been reset to empty (very odd because none of the other fields for my Evo account had been reset!) I did both change to use secure authentication and add back the GAL server and now it works again. I guess the annoying thing is that there is no error dialog that says that the GAL server name is missing; it just comes back with another password request dialog. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Bug 442098: anyone looking at it or reproducing it?
Has anyone tried to repro this or looked at it at all? It's pretty annoying. I'd be interested to know if anyone else has run into it, or if anyone has any ideas on why it might be happening? I've seen it in every version of Evo since at least 2.10, right up to yesterday's latest SVN head code... http://bugzilla.gnome.org/show_bug.cgi?id=442098 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Very serious problems with current SVN: cores to left, cores to the right...
I rebuilt from SVN this morning and there are one or more very serious bugs in this code, which make it essentially unusable. Last time I built from SVN was 5 Nov and I didn't have these problems. See GNOME bug http://bugzilla.gnome.org/show_bug.cgi?id=497378 Any ideas or help? I can reproduce this bug at will if anyone wants to work with me on tracking it down. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GAL password broken in SVN Evo?
I just rebuilt my Evo from SVN a few days ago, and somehow the Global Address List login for evolution-exchange is broken. I can access my email, and I can access my personal Contacts list. Works fine. But, if I try to do ANYTHING that requires access to GAL, I get a password popup asking me to enter my GAL password. I enter it (with the remember this password box checked) and the dialog disappears, then immediately reappears again. This will happen forever until I Cancel the dialog, and of course I can't look up anything in the GAL. And, the next time I open a new email, etc. I get the password dialog again. Did something break or change in password handling for evo-exchange and GAL recently that might account for this? I never had any problems accessing the GAL before (aside from the various crashes and things everyone was seeing back in 2.10 and 2.12.0, that have been fixed since). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How does evo find its components? (switching installs of evo)
On Mon, 2007-10-29 at 16:58 -0400, Matthew Barnes wrote: Yeah, Jeff's right; I forgot to mention that part. You need to kill your bonobo-activation-server process so that it picks up the new environment variable setting the next time it's started. You're right; that worked. Well, actually, one I realized it was bonobo that controls this I checked the man page and ended up modifying /etc/bonobo-activation/bonobo-activation-config.xml instead. It works now! And, I'm getting calendar notifications again. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How does evo find its components? (switching installs of evo)
On Fri, 12 Oct 2007 16:37:06 -0700, Matthew Barnes wrote: On Fri, 2007-10-12 at 13:17 -0400, Paul Smith wrote: How does Evolution decide where to get e-d-s, plugins, etc.? How can I reset it to run the ones in /usr/bin and ignore the stuff in /opt/evo? I don't remember doing anything special to switch it over to /opt/evo in the first place. You can control it with environment variables: LD_LIBRARY_PATH=/opt/evo/lib Overrides the search path for dynamically loaded libraries. BONOBO_ACTIVATION_PATH=/opt/evo/lib/bonobo/servers Overrides the search path for Bonobo servers. Hm, this doesn't seem to help for me. I now have the opposite problem. On my work system I reinstalled from Ubuntu 7.10 scratch (because I wanted to repartition my disk to have a separate /home partition). I started Evolution from /usr/bin and it worked OK. Then I decided I wanted to run with a version I had built myself from SVN, and compiled/installed it into /opt/evo. I have a shell script I'm running to start Evo, and it sets up my environment then logs all kinds of details, so I know my environment is correct; here's an excerpt from the log (obtained by running env | sort so I know these are properly exported as well): BONOBO_ACTIVATION_PATH=/opt/evo/lib/bonobo/servers LD_LIBRARY_PATH=/opt/evo/lib/evolution/2.12:/opt/evo/lib PATH=/opt/evo/libexec/evolution/2.12:/opt/evo/libexec:/opt/evo/bin:/home/psmith/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/games Evolution start on Mon Oct 29 15:35:55 EDT 2007: '/opt/evo/bin/evolution' But when I use ps to see what's running, I get: $ ps -aef | grep evo psmith1512 7673 6 15:40 pts/500:00:01 /opt/evo/bin/evolution psmith1526 1 0 15:40 ?00:00:00 /usr/lib/evolution/evolution-data-server-1.12 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=25 psmith1546 1 3 15:40 ?00:00:00 /usr/lib/evolution/2.12/evolution-exchange-storage --oaf-activate-iid=OAFIID:GNOME_Evolution_Exchange_Component_Factory:2.12 --oaf-ior-fd=27 psmith1561 1 0 15:40 ?00:00:00 /usr/lib/evolution/2.12/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.12 --oaf-ior-fd=29 (Before I started /opt/evo/bin/evolution there were no processes running containing the string evo). Can anyone tell me why it always invoking the stuff in /usr/lib, instead of the stuff in /opt/evo/lib, even though I've set LD_LIBRARY_PATH, BONOBO_ACTIVATION_PATH, etc. etc.? And, how to change this? Thanks! -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] How does evo find its components? (switching installs of evo)
Hi all; I've been using my makefile to build Evolution from SVN for my Ubuntu Feisty systems; the makefile installs everything in /opt/evo so that I don't interfere with the packages managed by the system. When I run /opt/evo/bin/evolution, it starts up e-d-s and evo-exchange, etc. from /opt/evo as well (which is what I want). However, I recently upgraded one of my systems to Ubuntu Gutsy RC1, which has its own version of Evo 2.12.0. I know there have already been some bug fixes since that was released but I wanted to try out the distro version to see how it's working. But, when I run /usr/bin/evolution, it's STILL trying to run e-d-s etc. out of /opt/evo instead of the ones in /usr/bin: this fails because the ones in /opt/evo were compiled against Feisty libraries, some of which have been upgraded in Gutsy. How does Evolution decide where to get e-d-s, plugins, etc.? How can I reset it to run the ones in /usr/bin and ignore the stuff in /opt/evo? I don't remember doing anything special to switch it over to /opt/evo in the first place. Note that deleting my ~/.evolution directory or similar is out of the question; I have too much stuff there. -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Synching Evolution/GNOME version
On Wed, 2007-10-03 at 14:17 +0200, Andre Klapper wrote: it does. it's annoying that i have to remember which version corresponds to which gnome release for gtk+, glib, evofriends and other modules (i'm happy that atk, at-spi gail already switched to the gnome versioning a few months back), both from a bugsquad and a release-team point of view. For what little it's worth, I agree the versions should be synced. In addition to the above, it's much simpler to deal with SVN branch naming etc. when you only have one version number to worry about and it's the same across all the components. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] New version of the Evo SVN Makefile
Hi all; I just uploaded a new version of my Makefile to build Evo from SVN. This version allows for building the current SVN trunk HEAD (up until today I was building on the 2.20 branch). Thanks to Reid Thompson for pointing out that gnome-icon-theme is now necessary for the build. I also added a package prerequisite on the icon-naming-utils package, which is needed to build gnome-icon-theme. One potentially odd thing: gnome-icon-theme adds its pkgconfig info into $prefix/share/pkgconfig instead of $prefix/lib/pkgconfig like all the other packages; is this correct? Maybe because the icon-theme package contains no architecture-specific content? Anyway, if you want a simple way to build Evo from SVN without rebuilding all of Gnome (as with GARNOME), give it a whirl! http://mad-scientist.us/evolution.html -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Bugzilla versions for Evo-exchange need to be updated
Hi all; I was just going to try to file a bug against the evolution-exchange component in bugzilla, but I notice there's no 2.12.x version listed in the Please select which version of the application you are using. dropdown. There IS a 2.12.x for Evolution itself. Please fix, and check the other Evo components like evolution-webcal, e-d-s, etc. (I didn't try them). Thanks! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Current issues with Evolution 2.12 / Exchange
Hi all; This seemed useful to some people last time, so I'm doing it again now. I've been using Evolution from SVN for a few months now tracking the latest changes and overall I've been REALLY happy: so many things are much better, especially with Exchange integration, than in 2.10 or any previous release. Applause and cheers for everyone's hard work over the last 6 months!! However, there are still some issues. I hope now is a good time to point them out so maybe we can concentrate on these for 2.12.1 or 2.12.2. Others might have a different list of issues, but these are mine (links to bugzilla entries). I've updated the bugzilla entries with the latest info I have. As I said, I'm building Evo and all components (libsoup, gtkhtml, e-d-s, evo, evo-exchange, evo-webcal) locally with debugging enabled and running them with full logging, each instance in its own directory. I stand ready and willing to help anyone who wants to, to work on these issues! I've tried to order them in order of precedence (how much I want them fixed), most pain to lesser pain. 478404: Composer stops completing addresses if you come back to the To: line This one just seemed to pop up within the last month or so but it's REALLY annoying. Hopefully it's a simple fix, because it really impacts me a lot. 478151: I lose the ability to see older messages in my Exchange inbox This still happens sometimes. The only way to solve it, once it happens, is to delete the ~/.evolution/exchange and ~/.evolution/mail/exchange folders (actually deleting one might be sufficient; I've never tried to see). As described in the bug, I was given a patch back in August or so and I've been using that patch ever since. The incidence of this seems to have gone down a bit, BUT it definitely still happens. 442098: Folder list shows I have new Exchange mail, but it doesn't appear in the summary This one is really annoying, as it happens all the time. In order to fix it, I have to restart Evolution. It used to happen regularly if I visited my local inbox, then went back to the Exchange inbox. Now it seems to be harder to trigger but still relatively common. I think now that it happens when I visit my local Junk folder. 478090: Tried to create a meeting on the Exchange server, and Evo crashed when adding an address This is a big one for me, because I need to schedule meetings through this mailing list. Because of this problem I have to create my meetings through Exchange webmail rather than Evolution! Luckily (in all senses of the word) I don't have to create meetings very often. 436615: Attendees are deleted from Exchange meetings If I create a meeting and save it, then go back to edit it and click on the Attendees button to get the dialog for adding new attendees, then save that, all my previously existing attendees disappear. This happens every time. This is a really bad bug in that you lose data; however you can avoid it by not using the Attendees dialog but instead entering new attendees directly into the meeting list (with the Add button). 478439: Contact lookups for GAL never return I think this has been around for a while but I never bothered to report it until now. I don't run into this that much but it's a pain when I need to look up someone. 478090: Meeting acceptances for attendees who weren't listed are lost This isn't a huge deal, but it's pretty annoying. -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] SVN issues
Hi all; I'm not an evolution developer but I'm trying to understand the way the project uses subversion. I have some questions, especially now that there's been a release of 2.12: * Shouldn't there be a gnome-2-20 branch on evolution-webcal? there may be other Evo modules that don't have the right branch. * I notice that the versions of the code that I'm building still say 2.11.92, rather than 2.12, but I thought that 2.12 was officially released? I don't see anything on the gnome-2-20 branch that changes the version number, which is where you'd expect it to be. * Are we adding tags to the code to denote the release? I don't see any tags that seem to be related to this release. Thanks. -- - Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us Please remain calm--I may be mad, but I am a professional.--Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Current issues with Evolution 2.12 / Exchange [SEC=UNCLASSIFIED]
On Fri, 2007-09-21 at 10:41 +1000, Shane McEwan wrote: 478151: I lose the ability to see older messages in my Exchange inbox This happened to me yesterday with 2.11.90! Restarting Evolution still wouldn't let me see any messages at all in my Exchange INBOX and would sometimes crash evolution-exchange-storage. Deleting ~/.evolution/mail/exchange/[MYEXCHANGEADDRESS]/personal/subfolders/Inbox fixed the problem. Here's a question: did you notice what was the earliest visible email? It sounds almost impossible to believe but EVERY time this happens to me it happens the same way: all the mail in my Inbox before July 01, 2007 becomes invisible. It doesn't seem to matter how many emails I have in my inbox after that, it's always that day. I've even deleted some of the mail in early July and late June but it still happened the same way. So bizarre. 442098: Folder list shows I have new Exchange mail, but it doesn't appear in the summary This one has been happening to me since 2.8 but has mostly been fixed since I downloaded the 2.10 and 2.11 source and compiled my own rather than use the Fedora Core 6 package. However I can still make it happen every single time if I visit my Unread Mail search folder. Unread Mail searches two IMAP inboxes and one Exchange inbox for any messages received within 1 week or is not Read. This used to happen very repeatably: I just had to visit my local Inbox or my local Junk folder and *bang*, no new mail would show up in the Exchange inbox. Now, it's not so easy; I think it might only be happening with the Junk folder now. Paul, thanks for the Subversion Makefile thingy. I've had a go running it on my Fedora Core 6 box and after a little bit of fiddling I've nearly got it to work. I just need to install a newer version of intltool (the FC6 supplied version is too old) and hopefully I'll get it to build. Cool! The only change I had to make to the Makefile to get it to work was on line 271. I had to change: $V pkg='$*'; $(SVN) checkout '$(SVNPKGURL)' $$pkg to: $V pkg='$*'; $(SVN) checkout $(SVNPKGURL) $$pkg Doh! Stupid. OK, I put a fixed version up on the web. Cheers! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
