[Evolution-hackers] Simple Question to ChangeLog

2007-06-16 Thread Tobias Mueller
Hi Evolution Hackers :)

Please let me introduce myself. I am Tobias Mueller, from Hamburg,
Germany and I want to hack on Evolution. I am a SoC student and I want
to improve Evolutions behaviour in displaying threaded emails.

I am digging through the code and try to understand, how things work. I
tried to build evolution from SVN as well, but I ran into some problems.
The critical ones are already fixed :) So now I can compile Evolution
even with automake 1.6 ;-)

But the test-component doesn't seem to work as described in #444289 [1].
I am about to commit this patch which is accepted-commit_now.

But I am not quite sure about this ChangeLog thing. I am supposed to
update the ChangeLog, but I don't know exactly how. HACKING[2] states:
It must include ChangeLog entries in the appropriate ChangeLog for the
file modified.  Use emacs, C-4-a will start a properly formatted
ChangeLog entry in the correct ChangeLog file automatically.
But I am not used to Emacs and my Emacs doesn't do that anyway :(
So I just can guess that a correct ChangeLog entry looks like:

2007-06-17  Tobias Mueller [EMAIL PROTECTED]
Fixes #444289
* shell/evolution-test-component.c:
Removed createdControls stuff

But since this is a rather trivial change, a ChangeLog might not even be
necessesary. There are revision even without a ChangeLog update. See [3]
for example.

So should I alter ChangeLog, and if, in the proposed way?
And does a strict ChangeLog policy exists?


http://www.gnome.org/projects/evolution/arch.shtml helped me a bit to
understand evos source code, but I am far away from understanding it
though. I am completly new to glib, Corba and stuff, thus I have to read
a lot.

Anyway I found a typo there: it says:  ,,The corba piece is
asyncrhonous'' which I propose should be ,,asynchronous''.
And on b.g.o [4] I found that the link under Product Info labeled with
GNOME SVN points to http://svn.gnome.org/viewcvs/Evolution/trunk which
does not exists (note the capital e in Evolution). But guenter already
told me, that this might not be easy to fix.

I appreciate any further documentation on Evos internals and the way
things work :)

Cheers,
  Tobi

[1] http://bugzilla.gnome.org/show_bug.cgi?id=444289
[2] http://svn.gnome.org/viewcvs/evolution/trunk/HACKING?view=markup
[3] http://svn.gnome.org/viewcvs/evolution?view=revisionrevision=30057
[4] http://bugzilla.gnome.org/browse.cgi?product=Evolution


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Error dialogs in evolution data server plugin

2007-06-29 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi :)

On 20.06.2007 06:53, Srinivasa Ragavan wrote:
 I don't think you can do a error display from EDS. Just see how the
 e-cal errors/failures work. They return a code to the clients
 (Evolution) and Evolution displays a error using e-error.


This is, how things actually /should/ work, I guess.

But look at libedataserverui/e-passwords.c, there the e-d-s displays
password entry dialogs.

That raises a question in my mind: Is that (e-d-s is the user interface)
desired behaviour, or should we care to move this kind of functionality
off the e-d-s into the clients, say, Evo?

Regards,
  Tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGg/RIPuBX/6ogjZ4RAtxHAKCSSKdCeRbMp3ZNCYD6cinKRxaRRQCeKLFB
Prs4IsYv2HeX/9iVtdMx4yE=
=UVmg
-END PGP SIGNATURE-

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


Re: [Evolution-hackers] Evolution 2.11.6(.1), Evolution-Data-Server 1.11.6(.1), GtkHTML 3.15.6 and Evolution-Exchange 2.11.6(.1) released

2007-08-08 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 08.08.2007 19:15, William John Murray wrote:
 Thanks Matthew - except that on F7 there seems to be a packaging
 problem. If I yum update evolution --enablerepo=development (and add
 evolution-exchange via rpm) I get:
 undefined symbol:  g_once_init_enter_impl
 errors on starting evolution.

I ran into a similar issue as well. This is due to a new glib [1], which
you probably don't have installed. So try to install a very recent glib.

Cheers,
  Tobi

[1]
http://svn.gnome.org/viewcvs/glib/trunk/glib/gthread.h?view=diffr1=5615r2=5616
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGul0+PuBX/6ogjZ4RAgvxAJ9YNyFq8beFlLq4HOGhEw4nM5DNXACeMft1
lVCllDup2jLj/c5yYGjZTpY=
=ars0
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] can't configure evolution as of rev 34033 due to ?

2007-08-18 Thread Tobias Mueller
Hi folks,

I desperately try to build evolution but even the configure fails.
Please see the following transcript:


 *** Checking out evolution *** [1/1]
 
 svn update .
 Uhelp/es/es.po
 Updated to revision 34033.
 *** Configuring evolution *** [1/1]
 
 ./autogen.sh --prefix /opt/gnome2 --libdir '${exec_prefix}/lib64'  
 --disable-static --disable-scrollkeeper --disable-gtk-doc --with-openldap=yes 
 --enable-nntp=yes --enable-ipv6=yes --enable-test-component=yes 
 --enable-nss=yes --enable-smime=yes --enable-plugins=all
 /opt/gnome2/bin/gnome-autogen.sh
 checking for autoconf = 2.53...
   testing autoconf2.50... not found.
   testing autoconf... found 2.60
 checking for automake = 1.6...
   testing automake-1.10... found 1.10
 checking for libtool = 1.4.3...
   testing libtoolize... found 1.5.22
 checking for glib-gettext = 2.2.0...
   testing glib-gettextize... /opt/gnome2/bin/glib-gettextize: line 74: echo: 
 write error: Broken pipe
 /opt/gnome2/bin/glib-gettextize: line 75: echo: write error: Broken pipe
 found 2.14.1
 checking for intltool = 0.25...
   testing intltoolize... found 0.36.1
 checking for pkg-config = 0.14.0...
   testing pkg-config... found 0.21
 checking for gnome-doc-utils = 0.4.2...
   testing gnome-doc-prepare... found 0.11.1
 Checking for required M4 macros...
 Checking for forbidden M4 macros...
 Processing ./configure.in
 Running libtoolize...
 Running glib-gettextize... Ignore non-fatal messages.
 Copying file mkinstalldirs
 Copying file po/Makefile.in.in
 
 Please add the files
   codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
   progtest.m4
 from the /aclocal directory to your autoconf macro directory
 or directly to your aclocal.m4 file.
 You will also need config.guess and config.sub, which you can get from
 ftp://ftp.gnu.org/pub/gnu/config/.
 
 Running intltoolize...
 Running gnome-doc-prepare...
 You should update your 'aclocal.m4' by running aclocal.
 Running aclocal-1.10...
 /opt/gnome2/share/aclocal/audiofile.m4:12: warning: underquoted definition of 
 AM_PATH_AUDIOFILE
 /opt/gnome2/share/aclocal/audiofile.m4:12:   run info '(automake)Extending 
 aclocal'
 /opt/gnome2/share/aclocal/audiofile.m4:12:   or see 
 http://sources.redhat.com/automake/automake.html#Extending-aclocal
 configure.in:102: warning: AC_ARG_PROGRAM invoked multiple times
 Running autoconf...
 configure.in:102: warning: AC_ARG_PROGRAM invoked multiple times
 Running autoheader...
 configure.in:102: warning: AC_ARG_PROGRAM invoked multiple times
 Running automake-1.10...
 configure.in:102: warning: AC_ARG_PROGRAM invoked multiple times
 data/Makefile.am:4: `%'-style pattern rules are a GNU make extension
 data/Makefile.am:12: `%'-style pattern rules are a GNU make extension
 gnome-doc-utils.make:63: HAVE_GNOME_DOC_UTILS does not appear in 
 AM_CONDITIONAL
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:133: ENABLE_SK does not appear in AM_CONDITIONAL
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:182: ENABLE_SK does not appear in AM_CONDITIONAL
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:74: if $(DOC_H_FILE: non-POSIX variable name
 gnome-doc-utils.make:74: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:77: if $(DOC_H_FILE: non-POSIX variable name
 gnome-doc-utils.make:77: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:110: if $(DOC_USER_FORMATS: non-POSIX variable name
 gnome-doc-utils.make:110: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:115: if $(filter environment,$(origin LINGUAS: non-POSIX 
 variable name
 gnome-doc-utils.make:115: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:115: filter $(LINGUAS: non-POSIX variable name
 gnome-doc-utils.make:115: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:144: shell xmllint --format $(2: non-POSIX variable name
 gnome-doc-utils.make:144: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:144: notdir $(patsubst %/$(notdir $(2: non-POSIX 
 variable name
 gnome-doc-utils.make:144: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:144: if $(_ENABLE_SK: non-POSIX variable name
 gnome-doc-utils.make:144: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:160: if $(DOC_MODULE: non-POSIX variable name
 gnome-doc-utils.make:160: (probably a GNU make extension)
 help/Makefile.am:3:   `gnome-doc-utils.make' included from here
 gnome-doc-utils.make:160: wildcard 

Re: [Evolution-hackers] Can't build Evolution-Data-Server due to undefined reference to `e_proxy_require_proxy_for_uri'

2008-06-12 Thread Tobias Mueller

Bonjour :)

On 09.06.2008 20:10 Muelli wrote:

I have troubles building e-d-s:

gcc -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare 
-Wno-pointer-sign -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common 
-Wl,--as-needed -o .libs/soap-test soap-test.o -pthread 
-Wl,-R/usr/lib/nspr  ../../libedataserver/.libs/libedataserver-1.2.so 
-L/opt/gnome2/lib -L/usr/lib/nspr ./.libs/libegroupwise-1.2.so 
/opt/gnome2/lib/libbonobo-2.so /opt/gnome2/lib/libbonobo-activation.so 
/opt/gnome2/lib/libORBitCosNaming-2.so /opt/gnome2/lib/libsoup-2.4.so 
/opt/gnome2/lib/libxml2.so -lm /opt/gnome2/lib/libgnutls.so 
/opt/gnome2/lib/libtasn1.so -lz /opt/gnome2/lib/libgcrypt.so 
/opt/gnome2/lib/libgpg-error.so /opt/gnome2/lib/libgio-2.0.so 
/opt/gnome2/lib/libgconf-2.so /opt/gnome2/lib/libORBit-2.so 
/opt/gnome2/lib/libgmodule-2.0.so /opt/gnome2/lib/libgthread-2.0.so -lrt 
/opt/gnome2/lib/libdbus-glib-1.so -lnsl /opt/gnome2/lib/libdbus-1.so 
/opt/gnome2/lib/libgobject-2.0.so /opt/gnome2/lib/libglib-2.0.so -lplds4 
-lplc4 -lnspr4 -ldl -lpthread -Wl,--rpath -Wl,/opt/gnome2/lib
./.libs/libegroupwise-1.2.so: undefined reference to 
`e_proxy_require_proxy_for_uri'

./.libs/libegroupwise-1.2.so: undefined reference to `e_proxy_setup_proxy'
./.libs/libegroupwise-1.2.so: undefined reference to `e_proxy_new'
./.libs/libegroupwise-1.2.so: undefined reference to `e_proxy_peek_uri'
collect2: ld returned 1 exit status
make[4]: *** [soap-test] Error 1
make[4]: Leaving directory 
`/home/muelli/svn/gnome2/evolution-data-server/servers/groupwise'

make[3]: *** [all] Error 2
make[3]: Leaving directory 
`/home/muelli/svn/gnome2/evolution-data-server/servers/groupwise'

make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/home/muelli/svn/gnome2/evolution-data-server/servers'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/muelli/svn/gnome2/evolution-data-server'
make: *** [all] Error 2
*** error during stage build of evolution-data-server: ## Error 
running make   *** [52/54]


You might want to have a look at the full build log at 
http://rafb.net/p/Uwlhfj78.html

Especially ./libedataserver/e-proxy.c seems to be built.


As I notice that pastebin-link has vanished, I'll attach the build log here.

I hope, somebody can enlighten me.

Cheers,
 Tobi


eds.txt.gz
Description: GNU Zip compressed data


signature.asc
Description: OpenPGP digital signature
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Cannot run evolution built using jhbuild

2009-01-07 Thread Tobias Mueller
Hi,

On 07.01.2009 22:20, Stefano Canepa wrote:
 2) what's going wrong the evolution built by jhbuild?
 
The build itself works properly, right? Running your newly build
Evolution fails, if I read your log correctly.

To run evolution, you should do a jhbuild run evolution. It is not
clear to me, what evolution-cvs is or does.

Also, you should do an export LANG=C to reset the language before you
post any logs, because reading messages in your language might be
difficult for somebody ;-)

What I can guess from the error messages is, that you run an old gconfd
on your host system and don't run the new, dbus-ified GConfD from jhbuild.

Try to run the gconf deamon from your jhbuild prefix. i.e.
jhbuild run /opt/gnome/libexec/gconfd-2  before you run your
evolution-trunk.


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


Re: [Evolution-hackers] unable to build from trunc: changes only found in git repository

2009-04-22 Thread Tobias Mueller

Hey :)

Holger Goetz wrote:
can someone confirm that latest changes only get included to the new git 
repository and no longer find their way into svn?

confirmed.
AFAIK, the SVN is read only.

No problem to use git instead of svn when compiling from trunc - but it 
seems that the git repository doesn't contain all pieces (e.g. 
autogen.sh, README, AUTHORS etc. for evolution)...

ACK. This is a known problem being worked on.

Is there any known time line when git will become the current revision 
control system?



Yes, it was a couple of days ago ;-)

Cheers,
  Tobi



signature.asc
Description: OpenPGP digital signature
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Changes from 2.26 to 2.28

2009-10-04 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Rohan :)

Thanks for your critics :)

On 04.10.2009 02:47, Rohan Agrawal wrote:
   * In the panel that lists the mails, each mail is given a much
 wider space, which seems like a waste.  GNOME already consumes a
 lot of screen space with very big controls and text, when
 compared to Windows or to KDE.
Could you make a screenshot and file a bug at https://bugzilla.gnome.org/?

   * The Date column now shows 24-hour times rather than 12 hour
 times, and there doesn't seem to be a way to change it.
Hm. It should respect your LC_TIME environment variable.

   * The Date column now uses n days ago for mails within the last
 week, rather than the day of the week.  My impression is that
 Sunday is more understandable than 6 days ago.
 
If there is no (obvious) setting for this, I'd file a bug :-)

Thanks and Cheers,
  Tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrIaUgACgkQPuBX/6ogjZ6zYgCeLp8rqwwDrAYJXD9SYiIoabAr
GlgAn3+uPk0ljU1DlKzfJ8NiYEaezoSX
=VMUj
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Core dumps from Evolution

2009-10-20 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Heya :-)

On 15.10.2009 16:57, Paul Smith wrote:
 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) {
 
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.

HTH,
  Tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkraAgIACgkQPuBX/6ogjZ4OagCePFVft1jkNGidWH8eEvioRJJF
O/AAoIQN7XqtnVUkxx+r4xg8KaL7rkoi
=w54e
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] stacktraces, debug: How to link evolution with debug version of glib, gtk on ubuntu karmic

2009-12-24 Thread Tobias Mueller
Heya :)

On 24.12.2009 20:43, Thomas Mittelstaedt wrote:
 I try to get glib debug information for the glib libraries in backtraces
 on ubuntu karmic. Even though I installed the debug packages, gdb does
 not pick up the non-stripped library:
 
Sounds like a bug to me.
How do you know it doesn't pick the debug symbols up though?

 Do I have to build glib myself and install it in the
 same prefix as evolution?
Doesn't really matter where you install it, as long as the non-stripped
binaries get pulled. Thus, you need to tell the linker to use the new
library, i.e. with LD_LIBRARY_PATH or LD_PRELOAD.

HTH,
  Tobi



signature.asc
Description: OpenPGP digital signature
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] mail address validation

2010-01-21 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey :-)

On 21.01.2010 19:17, 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?
 
Thanks for you contribution. However, it is way too strict.

It misses all the interesting characters that are allowed in the local
part, i.e.:

! $  * - = ^ ` | ~ # % ' + / ? _ { }

RFC 5322 (4.3.1) says the local part is a dot-atom, 3.2.3 says a
dot-atom is a atext which includes alphanumeric plus the characters
mentioned above.

I'd be delighted to see an implementation that parses all corner cases,
i.e. foo/bar=...@example.com or !foo%bar?baz*...@example.com, correctly.
That might be a challenging Summer of Code assignment ;-)

Happy Hacking ;-)
  Tobi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktYsaMACgkQPuBX/6ogjZ6xBQCgrkvs7pKQ6SKARF2ja20Wt0Bk
pb4AoISpqLFf27yDVaiS3aAIJt8tMQqM
=0XVy
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] mail address validation

2010-01-21 Thread Tobias Mueller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 21.01.2010 19:57, Tobias Mueller wrote:
 I'd be delighted to see an implementation that parses all corner cases,
 i.e. foo/bar=...@example.com or !foo%bar?baz*...@example.com, correctly.
 That might be a challenging Summer of Code assignment ;-)
 
Just found this obviously correct RegEx in
http://cpansearch.perl.org/src/MAURICE/Email-Valid-0.15/Valid.pm:

$RFC822PAT = 'EOF';
[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\
xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xf
f\n\015()]*)*\)[\040\t]*)*(?:(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\x
ff]+(?![^(\040)@,;:.\\\[\]\000-\037\x80-\xff])|[^\\\x80-\xff\n\015
]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015]*)*)[\040\t]*(?:\([^\\\x80-\
xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80
- -\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*
)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\
\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\
x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x8
0-\xff]+(?![^(\040)@,;:.\\\[\]\000-\037\x80-\xff])|[^\\\x80-\xff\n
\015]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015]*)*)[\040\t]*(?:\([^\\\x
80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^
\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040
\t]*)*)*...@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([
^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\
\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\
x80-\xff]+(?![^(\040)@,;:.\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-
\xff\n\015\[\]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()
]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\
x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\04
0\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\
n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\
015()]*)*\)[\040\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\xff]+(?!
[^(\040)@,;:.\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\
]]|\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\
x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\01
5()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*|(?:[^(\040)@,;:.
\\\[\]\000-\037\x80-\xff]+(?![^(\040)@,;:.\\\[\]\000-\037\x80-\xff]
)|[^\\\x80-\xff\n\015]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015]*)*)[^
()@,;:.\\\[\]\x80-\xff\000-\010\012-\037]*(?:(?:\([^\\\x80-\xff\n\0
15()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][
^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)|[^\\\x80-\xff\
n\015]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015]*)*)[^()@,;:.\\\[\]\
x80-\xff\000-\010\012-\037]*)*[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?
:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-
\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:@[\040\t]*
(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015
()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()
]*)*\)[\040\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\xff]+(?![^(\0
40)@,;:.\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\
[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\
xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*
)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80
- -\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x
80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t
]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\xff]+(?![^(\040)@,;:.\\
\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff])
*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x
80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80
- -\xff\n\015()]*)*\)[\040\t]*)*)*(?:,[\040\t]*(?:\([^\\\x80-\xff\n\015(
)]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\
\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*...@[\040\t
]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\0
15()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015
()]*)*\)[\040\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\xff]+(?![^(
\040)@,;:.\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|
\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80
- -\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^\x80-\xff][^\\\x80-\xff\n\015()
]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x
80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\[^
\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040
\t]*)*(?:[^(\040)@,;:.\\\[\]\000-\037\x80-\xff]+(?![^(\040)@,;:.
\\\[\]\000-\037\x80-\xff])|\[(?:[^\\\x80-\xff\n\015\[\]]|\\[^\x80-\xff
])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\[^\x80-\xff]|\([^\\
\x80-\xff\n

Re: [Evolution-hackers] Reconsidering our release cycle

2013-07-28 Thread Tobias Mueller
Hi.

On Wed, Jul 24, 2013 at 07:21:46AM -0400, Paul Smith wrote:
 On Wed, 2013-07-24 at 10:58 +0100, David Woodhouse wrote:
  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.
 
Hm. I'm wondering whether this is a problem for the rest of GNOME, too. Do the 
arguments brought up in this thread apply to Evolution (and friends) only?
If no: Would the rest of GNOME also benefit from a different release schedule?
If yes: Why would that be? The arguments on favour of a longer cycle seem to be 
very generic to me.

Cheers,
  Tobi
___
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] Account autoconfiguration/autodiscover

2016-02-24 Thread Tobias Mueller
Hi!

On Mi, 2016-02-24 at 10:20 +0100, Milan Crha wrote:
> the current Evolution (also the development version 3.19.90) doesn't
> support any kind of this autodiscover thing for mail accounts.
Do you think it would be something for the upcoming Summer of Code or
Outreachy rounds?

Cheers,
  Tobi
___
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] Account autoconfiguration/autodiscover

2016-03-01 Thread Tobias Mueller
Hi!

On Mi, 2016-02-24 at 11:58 +0100, Milan Crha wrote:
> it's not a large change, but not a tiny too.
Hm. GSoC is 12 weeks or so. And the intern would probably be completely
unaware of Evolution's codebase.  Do you think that's feasible, still?


> b) a better option would be to add a new Edit->Server Accounts (the
>    wording is awful, I know), where you fill only User name and E-
> Mail
>    (or server domain, if not email), and then the wizard will check
>    what that domain offers based on the SVR records, well-known HTTPs
>    entry points and so on and offers to add all sources it'll find
>    for the user, thus you gen not only Mail, but also Contacts,
>    Calendar, Memos and Tasks, if the server supports it. Furthermore,
>    users will be able to manage which sources should be visible in
>    the UI (offered to other evolution-data-server clients) here, not
>    like it is done currently, where you get all or nothing.
hm. sounds complicated indeed.

How about a separate tool that will then set up your evolution
accounts..?

Could anybody mentor such a project at all?

Cheers,
  Tobi
___
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] Support for Autocrypt?

2018-01-02 Thread Tobias Mueller
Hi.

On Tue, 2018-01-02 at 13:45 +0100, Milan Crha wrote:
>  The
> biggest problem is that the whole thing depends on the mail
> applications, as both ends should use clients which understand the
> feature, thus there's a problem with interoperability (at the moment)
> and basically no use for it in corporate environments (read: with
> Outlook users)
Well. The spec has just been released, so I'm not surprised that the
number of clients supporting autocrypt is not at its peak just yet.

How feasible is it, though, to implement this as a plugin to Evolution?
AFAIU it would need to be able to get the context in terms of what
headers the currently replied-to email has.

If it is possible indeed, then I could imagine this to be an extended
internship with the GNOME community.

Cheers,
  Tobi
___
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] [PGP] decrypt into local folder

2019-07-09 Thread Tobias Mueller
Hi,

On Tue, 2019-07-09 at 12:25 +0200, J T via evolution-hackers wrote:
> I encrypt almost all my emails with PGP. This has several significant
> drawbacks:
> 1. Since I generate new private key every year, I need to keep track
> of all of them to be able to decrypt and look at my old emails.
yeah, this is a general problem. General in the sense that MUAs are
particularly bad about maintaining OpenPGP state. But you can't blame
them, really, because GnuPG wants to maintain state and puts itself in
an awkward position.
Anyway, some MUAs (well, I know only one) store the session keys in a
database, s.t. you don't need the private keys anymore.

Evolution could do that, too, along with storing the plaintext of some
encrypted information (which, currently, is only the text of the body,
but some proposals exist to also encrypt the subject and other headers).


>  I don't like this. I want to archive old keys only for emergency
> purposes and have clean PGP keyring.
Well. Another angle is to fix your OpenPGP implementation...
Have you tried disabling your key? GnuPG supports that, but few people
know.


> I think it would be nice to have option or message-filter 'Decrypt
> into (local) folder', where emails are kept decrypted.

Why would you want to keep the encrypted version?

Cheers,
  Tobi

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers