Re: [Evolution-hackers] Removing local junk folder?

2007-11-27 Thread Øystein Gisnås
The default local account in Evolution stores mail in the mbox format
located in ~/.evolution/mail/local. Each folder is stored in a separate file
named the same as the folder. Metadata, summary and indices are stored in
files starting with the folder name and .. The junk folder is not a proper
folder, it is not a separate file. It is only a flag in the X-Evolution
message header. This is described at http://www.go-evolution.org/Camel.Local

In other words, open your inbox (or whatever folder the email originally was
stored in) with for example mutt: mutt -f ~/.evolution/mail/local/Inbox
I'd advise you to stop evolution with evolution --force-shutdown first.
From mutt you can save the problematic email (shortcut s), and also delete
it.

Hope this helps!

Cheers,
Øystein

2007/11/27, Jules Colding [EMAIL PROTECTED]:

 Hi,

 I have a rather annoying problem:

 http://bugzilla.gnome.org/show_bug.cgi?id=499769

 So, how do I go about deleting this mail from outside evo?


 Thanks,
   jules

 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] GMail IMAP support in Evolution

2007-10-24 Thread Øystein Gisnås
Google seem to be in the process of introducing IMAP support to GMail
[1]. Personally I think GMail offers an extremely attractive email
solution by now. Evolution does already support integration with GMail
via SMTP and POP, and now also via IMAP. In addition to following the
IMAP standards as closely as possible, I think we should do explicit
QA on Evolution-GMail IMAP integration, to make sure our users'
experience is as good as possible. One of the slashdot comments has
already commented that Outlook works better with GMail IMAP than
Evolution. That should change!

I've only used tested Evolution-GMail IMAP for a few minutes so far,
but already found a minor issue: I'm not able to prevent sent mail
from being stored. SMTP through GMail saves sent mails automatically.

First of all, I'll recommend everyone to try out GMail IMAP, and then
I hope some initiative will be taken to QA this integration.

Cheers,
Øystein

[1] http://slashdot.org/article.pl?sid=07/10/24/0249257
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Øystein Gisnås
2007/5/31, Matthew Barnes [EMAIL PROTECTED]:
 On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
  What version to start with?  I'm on Debian GNU/Linux, which currently has 
  evo
  2.6.  I notice that's a bit dated (although I did see that a few months ago
  some of the Debian packagers were interested in making a more recent
  version).  I've been working from the Debian version.  Does that version, 
  the
  last stable release (from evo, not Debian), or svn head make the most sense
  to work from?  (BTW, the one bug I fixed was one that was already fixed
  post-2.6).

 FYI, Debian Unstable has Evolution 2.10.  Might be easier to grab at
 least the 2.10 dependencies from there.  You'll need to upgrade gtkhtml
 and likely also your GTK+ library stack to get 2.10 to build.

In case you're on a Debian-based distribution and not pulling from
svn, I would recommend using pre-built packages, or even building the
packages yourself. 2.10.2 is in the archive, and I will do 2.11.2 this
weekend.

For my own development setup I use the 2.10.x packages plus custom
build from svn for the module I'm hacking on. e-d-s for example, I
install to /opt/evolution-data-server. Then I can start development
e-d-s with 'LD_LIBRARY_PATH=/opt/evolution-data-server/lib
/opt/evolution-data-server/libexec/evolution-data-server-1.12' and can
also start the stable e-d-s with
'/usr/lib/evolution/evolution-data-server-1.10'

Cheers,
Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Introduction and Questions

2007-05-31 Thread Øystein Gisnås
2007/5/31, Ross Boylan [EMAIL PROTECTED]:
 On Thu, 2007-05-31 at 23:20 +0200, Øystein Gisnås wrote:
  2007/5/31, Matthew Barnes [EMAIL PROTECTED]:
   On Thu, 2007-05-31 at 07:58 -0700, Ross Boylan wrote:
What version to start with?  I'm on Debian GNU/Linux, which currently 
has evo
2.6.  I notice that's a bit dated (although I did see that a few months 
ago
some of the Debian packagers were interested in making a more recent
version).  I've been working from the Debian version.  Does that 
version, the
last stable release (from evo, not Debian), or svn head make the most 
sense
to work from?  (BTW, the one bug I fixed was one that was already fixed
post-2.6).
  
   FYI, Debian Unstable has Evolution 2.10.  Might be easier to grab at
   least the 2.10 dependencies from there.  You'll need to upgrade gtkhtml
   and likely also your GTK+ library stack to get 2.10 to build.
 
  In case you're on a Debian-based distribution
 Yes; straight Debian.
  and not pulling from
  svn, I would recommend using pre-built packages, or even building the
  packages yourself. 2.10.2 is in the archive, and I will do 2.11.2 this
  weekend.
 Terrific.  Is unstable the place to look, or experimental, or somewhere
 else?

2.11.2 will end up in pkg-evolution's svn for sure. If we upload
binary packages, they will go to experimental.

  For my own development setup I use the 2.10.x packages plus custom
  build from svn for the module I'm hacking on. e-d-s for example, I
  install to /opt/evolution-data-server. Then I can start development
  e-d-s with 'LD_LIBRARY_PATH=/opt/evolution-data-server/lib
  /opt/evolution-data-server/libexec/evolution-data-server-1.12' and can
  also start the stable e-d-s with
  '/usr/lib/evolution/evolution-data-server-1.10'
 That's a great tip.  I built evo from Debian source (with one fix) and
 it took 45 minutes.  I clearly need a shorter route to trying out
 changes.

I don't think you get around the initial build; you can feature strip
it to reduce the time. Once you've built it. make will figure out what
has to be rebuilt. A make  make install when I edit files in only
one directory takes about 5 seconds on my system..

 Thanks for packing evo, and for making the -dbg files available.

You're welcome. Don't hesitate with questions on how you can use
packages or package scripts in your development setup..

Cheers,
Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Improved vCard parser

2007-05-30 Thread Øystein Gisnås
2007/5/30, Ross Burton [EMAIL PROTECTED]:
 On Wed, 2007-05-30 at 07:59 +0200, Øystein Gisnås wrote:
  I posted some lines about improvements to the vCard parser, but it
  seems like getting multi-megabyte attachments take some time to get
  through to the mailing list. So I posted to my blog instead:
  http://n800evolution.blogspot.com/2007/05/improved-vcard-parser.html

 Could you post the message itself, without any attachments?  There are
 some point I'd like to make, but without the context of the original
 post it would be tricky to read.

Sure:

I'd like to focus on the vCard parser and export in libebook. Some
things I've noticed:
- v3.0 import is quite well supported, with the major exception of
charsets http://bugzilla.gnome.org/240756 tracks all the v3.0 bugs
- v2.1 import was well supported, but is gradually getting worse since
there is a common codebase for 2.1 and 3.0, and most people care about
3.0
- v3.0 export is good, with minor exceptions (CRLF at end of card for example)
- v2.1 export is non-existant
- performance is important, as vCards are used in the file-backend.
From a performance perspective, that's horrible, but it has its
advantages too. For large vCards, the poor performance easily kneeled
the system, for example with a medium sized photo. With
http://bugzilla.gnome.org/433782 it got much better, but there's still
a lot of potential for improvement

I've created a patch (against svn trunk) that improves the performance
of the parsing itself (only v3.0) and adds some other fixes like CRLF
at the end of the card. The patch is supposed to be non-intrusive, and
will not break public APIs, but mainly create new internal methods
that will only kick in for vCards with VERSION:3.0 in the second line.
Other vCards will be parsed as before.

After the patch, I created a test suite (attached archive) to test my
own patch and the current implementation. I used a different approach
than Ross in eds-dbus
(http://svn.o-hand.com/view/eds-dbus/trunk/addressbook/testsuite/).
Instead of creating classic hand-coded unit tests, I compare a parsed
file with a file that has the expected format. That way, new tests can
be added with much less effort, without writing any code. The downside
is that not all aspects of parsing can be tested. For example, if a
list separated with comma was read as one chunk, it probably wouldn't
detect that it should have been separated at the commas. Anyway, I
think the test suite makes sense and can be supplemented by classic
unit tests. Try it out and add more tests!

To run the v3.0 tests, for example, add the .vcf's in vcard/valid-3.0
as parameters to src/test-vcard-suite. -e outputs detailed error
messages and -r 100 will repeat the parsing 100 times for
benchmarking. A typical command I use is:
LD_LIBRARY_PATH=/opt/evolution-data-server/lib -e src/test-vcard-suite
vcard/**/*.vcf

A major weakness in the vCard 3.0 specification is its inability to
tag vCards in files with charset. The only ideal solution, as I see it
is to ask the user which charset he wants to use and maybe also
display a preview. For vCards in emails (anything MIME), the charset
can already be specified. What the parser needs is support for
converting from the specified charset. I added an extension of the
patch that does this too. It breaks the API and will need extensions
to the UI to be of any practical value.

For now, focus on the patch without charset support. Ross' patch at
http://bugzilla.gnome.org/312581 is related, and efforts should
ideally be joined. What we need is a strategy (Ross and Srini) of
where to end up. I see three possible roads:
- An optimised v3.0 parser with fallback to a quirk-mode parser for
v2.1 and buggy v3.0 (my patch goes down this road)
- One v2.1 and one v3.0
- One parser to rule them all, but has to be very, very clever to
maintain high performance and at the same time support
quoted-printable (basically what we have now, minus some performance)

Independent of the choice of strategy, there are a couple of obvious
spots to improve.
* Export is quite streamlined, but the method doing escaping can be improved
* Whenever e-d-s requires glib 2.12 anyway, maybe glib's base64 can be
used for improved performance(?) and reduced code
complexity/maintainability?

That was a lot, but the gist is everyone, give some attention to the
vCard parser - improve it, test it or add test cases for whatever
doesn't work for you!
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Upgrade path from 2.6 to 2.10

2007-04-14 Thread Øystein Gisnås
Are there any changes in the data format between 2.6 and 2.10.1? Or
anything else that may cause trouble without installing 2.8 in
between?

We're considering to package 2.10.1 as a replacement for 2.6.3 in the
Debian distributions. If there are any possible upgrade problems, we'd
like to investigate that before the upload

Cheers,
Øystein
___
Evolution-hackers mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] gtkhtml API version

2007-04-14 Thread Øystein Gisnås
2007/4/14, Matthew Barnes [EMAIL PROTECTED]:
 On Sat, 2007-04-14 at 16:51 +0200, Øystein Gisnås wrote:
  What happened to the gtkhtml API versioning before the GNOME 2.18
  release? Seems like it was a mistake to do the bump in
  http://svn.gnome.org/viewcvs/gtkhtml/trunk/configure.in?r1=8408r2=8425
 
  It is not the new strategy to bump API_VERSION for every release I
  hope..? As Tor Lillquist mentioned, it's to late to revert now.
 
  What will happen before the next release (given that API/ABI is not
  broken)? It's NOT desirable to let the API_VERSION follow the general
  version number!

 Bumping the API was not a mistake.  It marked the migration from
 GnomePrint to GtkPrint, which broke GtkHtml's API.  GtkHtml no longer
 depends on nor supports GnomePrint.

 The API_VERSION should only change when the API actually changes.
 Incrementing it to match the version number rather than by one was a
 policy decision, as I recall.

Ok. That is perfectly fine then. As long as the policy is followed in
prior releases...

Øystein
___
Evolution-hackers mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] libebook scalability

2007-04-02 Thread Øystein Gisnås
2007/4/2, Srinivasa Ragavan [EMAIL PROTECTED]:
 On Mon, 2007-04-02 at 01:12 +0200, Øystein Gisnås wrote:
  I discovered a bottleneck for addressbook performance with large
  addressbooks. Details at
  http://n800evolution.blogspot.com/2007/04/libebook-scalability.html
 Looks fine to commit.

 
  A proposed fix is attached. I'm not sure if order matters when
  returned from the backend? Does anyone know? If not, g_list_reverse
  can be omitted.
 Atleast here the order wont matter.

 Im sure that there are more such bottle necks. It will be nice task to
 take these up. Øystein?

I'll look into this, but I can't fit it in very soon, so it's up to
anyone to have a go..

I'd also love to create scripts, code and test data to test
performance of some of the most important functions. Then we would be
able to track performance over time in a more scientific way.

Also, whether we're gonna use GQueues, GSLists, or reversed GLists is
an interesting discussion. Does GNOME in general have any
recommendations for that?

Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] libebook scalability

2007-04-02 Thread Øystein Gisnås
2007/4/2, Ross Burton [EMAIL PROTECTED]:
 On Mon, 2007-04-02 at 09:03 +0200, Øystein Gisnås wrote:
  I'd also love to create scripts, code and test data to test
  performance of some of the most important functions. Then we would be
  able to track performance over time in a more scientific way.

 http://burtonini.com/bzr/eds-tests/

 Check that out with bzr and you get a few tools:

 1) a dummy backend for libedata-book.  Ask for a contact and you get the
 same one back.  As for a contact list and you'll always get the same 10.
 Ask for a book view and (mwhaha) you'll get 10 contacts.  This makes
 profiling the EDS infrastructure easier as the backend has almost zero
 overhead.  I should probably reduce the number of contacts returned in a
 book view as malloc tends to swamp the profiles now.

 2) eds-bookview.  A test application that will open and repeatedly
 request book views for a given number of times and URL.  For example:

 $ eds-bookview --uri dummy:/// --repetition 10 --silent

 Will visibly do nothing for a few minutes but EDS will be very busy.
 Attach a profiler and come back 10 minutes later to discover that EVCard
 parsing is still primary bottle neck in eds-dbus.

Very useful.. And a first hands-on bzr for me..

It indeed seems like the vCard is a bottleneck here. One thing is the
CPU cycles for parsing that add up a bit on small datasets. For larger
datasets, the size of the vCard itself adds up a lot. My test with
1*10^6 contacts made a 350MB on the disk, plus a 100MB summary. The
same data in MySQL resulted in a 10MB database.

Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] libebook scalability

2007-04-01 Thread Øystein Gisnås

I discovered a bottleneck for addressbook performance with large
addressbooks. Details at
http://n800evolution.blogspot.com/2007/04/libebook-scalability.html

A proposed fix is attached. I'm not sure if order matters when
returned from the backend? Does anyone know? If not, g_list_reverse
can be omitted.

Øystein
--- addressbook/backends/file/e-book-backend-file.c.orig	2007-04-02 00:42:20.871493559 +0200
+++ addressbook/backends/file/e-book-backend-file.c	2007-04-02 00:43:08.298457559 +0200
@@ -412,7 +412,7 @@
 
 			db_error = db-get (db, NULL, id_dbt, vcard_dbt, 0);
 			if (db_error == 0) {
-contact_list = g_list_append (contact_list, vcard_dbt.data);
+contact_list = g_list_prepend (contact_list, vcard_dbt.data);
 			} else {
 g_warning (G_STRLOC : db-get failed with %d, db_error);
 status = GNOME_Evolution_Addressbook_OtherError ;
@@ -451,7 +451,7 @@
 			|| strcmp (id_dbt.data, E_BOOK_BACKEND_FILE_VERSION_NAME)) {
 
 if ((!search_needed) || (card_sexp != NULL  e_book_backend_sexp_match_vcard  (card_sexp, vcard_dbt.data))) {
-	contact_list = g_list_append (contact_list, vcard_dbt.data);
+	contact_list = g_list_prepend (contact_list, vcard_dbt.data);
 }
 			}
 
@@ -473,6 +473,7 @@
 		}
 	}
 
+	contact_list = g_list_reverse (contact_list);
 	*contacts = contact_list;
 	return status;
 }
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Backport of fix to Too Many Open Files problem

2007-01-11 Thread Øystein Gisnås
2007/1/11, Matthew Barnes [EMAIL PROTECTED]:
 On Wed, 2007-01-10 at 23:26 +0100, Øystein Gisnås wrote:
  I see users on 2.6.3 struggle with the problem described at
  http://mail.gnome.org/archives/evolution-list/2006-October/msg00130.html
  http://bugzilla.gnome.org/show_bug.cgi?id=34 and
  http://bugzilla.gnome.org/show_bug.cgi?id=356913
 
  I've looked at the patch (it's said to be fixed in 2.9.1). Looks like
  someone attempted a fix and it's been reverted and rewritten again.
  What's the correct patch for the problem. Does anyone have a gut
  feeling if it's good to backport that to 2.6.3?

 I wrote the patch.

 You have good timing because we discovered a critical flaw in the patch
 for bug #34 just today.  I recommend applying the patch in bug
 #34, followed by the patch for bug #384183.  I think it should be
 safe to backport to 2.6.3; it's a rewrite of some very old code.

 Note that it does break the ABI of libedataserver.

Thanks. I did not mean 2.6.3, but 2.8.2.1. I'll test with those two
patches against our reported incidents. Do you have any idea if this
can happen in 2.6? If so, why has noone reported it yet?

A pity with the ABI break. Makes things a lot more complicated to push.

Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Backport of fix to Too Many Open Files problem

2007-01-10 Thread Øystein Gisnås
I see users on 2.6.3 struggle with the problem described at
http://mail.gnome.org/archives/evolution-list/2006-October/msg00130.html
http://bugzilla.gnome.org/show_bug.cgi?id=34 and
http://bugzilla.gnome.org/show_bug.cgi?id=356913

I've looked at the patch (it's said to be fixed in 2.9.1). Looks like
someone attempted a fix and it's been reverted and rewritten again.
What's the correct patch for the problem. Does anyone have a gut
feeling if it's good to backport that to 2.6.3?

Cheers,
Øystein Gisnås
Debian Evolution Maintainer Team
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution - vcard import problem in 2.8

2006-10-19 Thread Øystein Gisnås
2006/10/19, Patrick Ohly [EMAIL PROTECTED]:
 On So, 2006-10-15 at 22:57 +0200, Patrick Ohly wrote:
* Is someone going to take care of the reported regression or do
  you need a patch to fix it? Whoever changed the code between 2.6
  and 2.8 should be in a better position to fix it, so I am a bit
  reluctant to investigate further in code that I don't know.

 I found out what the problem is, see
 http://bugzilla.gnome.org/show_bug.cgi?id=356176

 The fix is included in that issue (add one line with a function call).
 It should be easy to verify that it causes no harm and indeed fixes the
 problem. Can someone commit it for E-D-S 2.8.2?

 Øystein, can you make sure that it gets included in Debian packages if
 Etch would otherwise be released with an E-D-S where this bug is still
 present? Should I file a bug in the Debian tracker as a reminder?

Yes and yes. I will look into it and incorporate before etch if it
looks good. An entry in BTS ensures me (and the rest of the team)
won't forget it..

Cheers,
Øystein
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution

2006-10-15 Thread Øystein Gisnås
2006/10/15, Patrick Ohly [EMAIL PROTECTED]:
   * Is someone going to take care of the reported regression or do
 you need a patch to fix it? Whoever changed the code between 2.6
 and 2.8 should be in a better position to fix it, so I am a bit
 reluctant to investigate further in code that I don't know.

It seems like this is quiet times when it comes to patch review. I am
very sure though, that a bug report with a good patch will much more
likely be applied soon. If upstream doesn't look at it, I will
consider applying it to Debian.

   * Is someone running Evolution and in particular the Evolution
 data server under valgrind as part of release testing or regular
 quality assurance?

I know there is performance work in relation with evolution for suse
installations. For general quality assurance there are not enough
routines in place. I know it's on the todo list of the developers.
When it comes to valgrind testing, evolution becomes quite slow so
patience is a must.

   * Which branches are still maintained? At the moment Debian still
 has 2.6 in testing and unstable; if there is a chance to still
 get bug fixes into that version, I'd concentrate on that first
 instead of the more recent 2.8.

There is still a chance to get bug fixes into 2.6. Right now I plan an
upload of evolution-exchange 2.6.3, but there may be uploads of evo
and e-d-s soon, depending of the severity of the problems.

2.8 is in experimental, and we still hope we can push that in before
the release of etch. I would recommend developing against 2.8
actually, since your application isn't targeted for etch.

/* Øystein Gisnås */
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] libecal and libedata-cal versions

2006-07-31 Thread Øystein Gisnås
During the 2.6.x cycle, there were version bumps of libecal and
libedata-cal to make up for a previous ABI break in these two
libraries. It was unfortunate to bump the versions in a stable tree,
but now I'm more interested in the 2.8.x release.

When the version bump was commited to 2.6.x, it was not commited to
the 2.7.x tree. Why was that? Because you only bump versions just
before releases? I hope so. I noticed that libedata-cal versions were
synced with 2.6.x in
http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.184r2=1.185.
libecal was also bumped there, but AGE was not reset.

Is the plan to reset AGE just before the final 2.8.0 release, or was
it a mistake not to reset it before. The last thing we want is to
release 2.8.0 with a lower SONAME version than 2.6.x..
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] addressbook-file plugin

2006-05-07 Thread Øystein Gisnås
As far as I can see, the addressbook-file plugin (aka local addressbook)
fixes a grave bug causing data loss when address books are deleted. Is
there a reason this fix is only implemented as a plugin? Even if the
plugin is installed as default, what if users disable the plugin?

If no-one has a some good reasoning for the current solution, I'll file
a bug about it and start testing a patch.

Cheers,
Øystein Gisnås


signature.asc
Description: Dette er en digitalt signert meldingsdel
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Request for adding version information to libcamel soname

2006-04-23 Thread Øystein Gisnås
The Debian Evolution Maintainer Team is planning the upload of Evolution
2.6 to unstable to happen very soon. Before the upload, we'd like
feedback from Evolution developers on the biggest change we make to the
upstream release. In specific, Harish confirmed bug #321372, which is
what this is about, and also Parthasarathi probably have valuable
comments on this topic.

The first part of the change was described in the previous mail in this
thread. In addition to using version numbers to libcamel (contrast to
today's 0:0:0), we plan on moving the private libcamel provider
libraries to an install location that is version specific. The current
location is /usr/lib/evolution-data-server-1.2/camel-providers/, which
includes the API version, but not libcamel version. As far as I know, it
has already been discussed to name the e-d-s directory differently. Do
you have an update on if/when that will happen? What we will do on the
debian side is to move the contents of camel-providers to
camel-providers/8, or alternatively name it camel-providers-8 or
similar.

We highly value having the same names and versions in our releases as in
upstream. If you could give some indications on what changes will be
made upstream, and what names and versions will be used for this, we
could use that name/version scheme already and avoid future conflicts.

Our release will not be delayed indefinitely, but we'll put effort into
avoiding a diversion from upstream directions. Therefore a quick answer
will be greatly appreciated.

Thanks,

-- 
Øystein Gisnås
Debian Evolution Maintainer Team


signature.asc
Description: Dette er en digitalt signert meldingsdel
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Request for adding version information to libcamel soname

2006-04-22 Thread Øystein Gisnås
Previously, Loïc Minier reported a problem in how the libcamel library
is versioned, see http://bugzilla.gnome.org/show_bug.cgi?id=321372. The
problem can be seen in the filename /usr/lib/libcamel-1.2.so.0.0.0,
which stays the same between each release.

For the distribution package maintainers, having possibly incompatible
libraries with conflicting filenames is a headache.

Regarding Evolution 2.6 for Debian, changing the soname would mean
losing binary compatibility with other distributions. Although not
ideal, that is currently being considered.

What is important for us is to choose an soname that won't conflict with
a potential future soname upstream. Therefore, we'd like to have your
thoughts on if libcamel should have versioned soname or not, and what
version scheme you will use.

Our suggestion is that we use -version-info $(LIBCAMEL_CURRENT):
$(LIBCAMEL_REVISION):$(LIBCAMEL_AGE) for 2.6 and upstream does the same
for the next release with bumped versions. How does that sound?

-- 
Øystein Gisnås
Debian Evolution Maintainer Team


signature.asc
Description: Dette er en digitalt signert meldingsdel
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers