my point was:
why waiting 2.0 ? why not doing it in 1.2 ?
Charles Marcus wrote:
On 7/2/2009, Joan (j...@grosjo.net) wrote:
managesieve works fine for me on 1.2.0
However
-> it would be however a nice idea to include the patch of ManageSieve directly
into the branch 1.2 of dovecot.
T
thanks ! :-)
Michael Orlitzky wrote:
Joan wrote:
yes, Mercurial repository has a working status.
Anybody to help on teh following ? :
-> how managesieve works between the "sieve script per virtual user"
and the main script in the storage directory.
ManageSieve shouldn't be used to modify gl
Ok, but in the event of *virtual* users , how to setup the setting
sieve_dir = ~/
?
Michael Orlitzky wrote:
Joan wrote:
yes, Mercurial repository has a working status.
Anybody to help on teh following ? :
-> how managesieve works between the "sieve script per virtual user"
and the main scr
Hi,
I have a global script (run by "run_before" in dovecot.conf) and a user
script.
All scripts get compiled correctly and running.
however , times to times, the filters are not applied, whereas they
should, especially the one run all the time, against Spam:
--
Hi Stefan,
The mercurial repository replied "404 not found". Did you change the URL ?
thanks
JM
Stephan Bosch wrote:
Hello Dovecot users,
Relatively many bugs and problems were reported recently in a short
period of time. Apparently, now that Dovecot v1.2 is finally stable,
the new Sieve
--- Begin Message ---
Hi
How to solve this ?
So many similar segfaults
Thank you
On 2018-11-30 06:11, Joan Moreau wrote:
ANother (very very long) example :
# gdb /usr/libexec/dovecot/indexer-worker
core.indexer-worker.0.3a33f56105e043de802a7dfcee265a07.21017.154353342400
GNU gdb
Hi
How to solve this ?
So many similar segfaults
Thank you
On 2018-11-30 06:11, Joan Moreau wrote:
ANother (very very long) example :
# gdb /usr/libexec/dovecot/indexer-worker
core.indexer-worker.0.3a33f56105e043de802a7dfcee265a07.21017.154353342400
GNU gdb (GDB) 8.2
Copyright (C
" and
"search in fields" does not even work.
Solr with Dovecot seems very early beta isnt'it ?
On 2018-12-04 15:57, Aki Tuomi wrote:
On 04 December 2018 at 16:46 Joan Moreau via dovecot
wrote:
Hi
How to solve this ?
So many similar segfaults
Thank you
On 2018-11-30
Hi
USing git, I reach the following error (below).
Here is my configure parameters :
CPPFLAGS="-I/include -I/usr/include/tirpc/" LDFLAGS="-L/lib -ltirpc"
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--libexec=/usr/libexec --with-sql=yes --without-sqlite --with-mysql
--wit
So far, not getting any results with Solr. Squat however exactly meet
the need.
On 2018-12-04 16:18, Aki Tuomi wrote:
We don't consider it as "very early beta". We consider it production ready. It
is bit more work to set up though.
Aki
On 04 December 2018 at 17:16 Joa
Ooops, thanks
Sorry for the noise
On 2018-12-04 16:23, Aki Tuomi wrote:
Did you run ./autogen.sh first?
Aki
On 04 December 2018 at 17:20 Joan Moreau via dovecot
wrote:
Hi
USing git, I reach the following error (below).
Here is my configure parameters :
CPPFLAGS="-I/inclu
work to set up though.
FWIW, Squat has been deprecated since 2.0, so none of this should come as a
surprise.
https://wiki.dovecot.org/Plugins/FTS
Aki
On 04 December 2018 at 17:16 Joan Moreau wrote:
Thanks for mySql
For Squat vs Solr, Solr does not reach Squat by very far in terms of
results :
Hi
I am giving Solr another try.
Using Solr 7.5 (from Archlinux AUR), I do not see anymore
the"solr/conf/schema.xml" neither the "managed-schema" folder. (as per
https://wiki.dovecot.org/Plugins/FTS/Solr)
Maybe some things have moved ?
Thank you so much
/dovecot/conf for archlinux
users
Additionaly, the url is http://(solr_ [1]server):8983/solr/dovecot/
(error in wiki)
On 2018-12-04 19:01, Joan Moreau via dovecot wrote:
Hi
I am giving Solr another try.
Using Solr 7.5 (from Archlinux AUR), I do not see anymore the"solr/conf/schem
also, the value "break-imap-search" is not supported in fts_solr
parameter, contrary to the wiki
and not sure then how to enable full text search in BODY
On 2018-12-04 19:40, Joan Moreau via dovecot wrote:
In the Wiki, ( https://wiki.dovecot.org/Plugins/FTS/Solr ), it would nice to
ure it's used for all kinds of things automatically. break-imap-search is supported, but does nothing.
Updated the wiki a bit.
Aki
On 4.12.2018 20.50, Joan Moreau via dovecot wrote:
also, the value "break-imap-search" is not supported in fts_solr parameter, contrary to the wiki
Solr does not support prefix/substring search unless you configure solr to support it.
Aki
On 5.12.2018 11.50, Joan Moreau wrote:
Well, "break-imap-search" option prevent dovecot from starting.
I used solr on one server since yesterday.
First feedback is that
* BODY search is
Additionally, I get "Invalid search response" on my Android , using
dovecot-solr, whereas squat works fine
Why making squat obsolete ? It is simple and straightforward
On December 5, 2018 12:57:22 PM Joan Moreau via dovecot
wrote:
THen the Squat shall be maintained until the SOlr
After some testsing, I managed to get proper functionning
- The schema.xml is attached below (quite different from the one
provided on teh wiki) (in bold the core differences) (NGramFilterFactory
is the class that replace the fts_squat "partial=3 full=15", everything
else is just a big hammer to
After some testsing, I managed to get proper functionning
- The schema.xml is attached below (quite different from the one
provided on teh wiki) (in bold the core differences) (NGramFilterFactory
is the class that replace the fts_squat "partial=3 full=15", everything
else is just a big hammer to
turns are totaly funny (keywords not presentin teh results)
I am back to fs_squat
On 2018-12-08 18:28, Joan Moreau via dovecot wrote:
After some testsing, I managed to get proper functionning
- The schema.xml is attached below (quite different from the one provided on teh wik
.)
id
On 2018-12-10 21:17, Daniel Miller via dovecot wrote:
On 12/4/2018 10:40 AM, Joan Moreau via dovecot wrote:
In the Wiki, ( https://wiki.dovecot.org/Plugins/FTS/Solr ), it would nice to stipulate to the reader to type the command :
su
.FreqProxTermsWriterPerField.writeProx(FreqProxTermsWriterPerField.java:80)
Dec 11 06:00:14 gjserver solr[16761]: at
org.apache.lucene.index.FreqProxTermsWriterPerField.addTerm(FreqProxTermsWriterPerField.java:184)
Dec 11 06:00:14 gjserver solr[16761]: at
org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:1
uot;. Again, the filename saved in the /conf folder needs to be "managed-schema" - no ".xml" suffix.
If that doesn't work for you - please share the errors.
Daniel
On 12/10/2018 11:40 AM, Joan Moreau wrote:
Hi Daniel,
THere is no need of all this, just the command (on
dovecot
wrote:
On 12/11/2018 4:46 AM, Joan Moreau via dovecot wrote:
I shared the errors already so many times (check this mailinling for "solr"
in teh title)
Contrary to what you say, with SOlr 7.5 and Dovecot git, I had to remove
the "managed-schema" to make solr re
here my latest schema.xml (remove the "long" type hich seems to be very
deprecated in 7.x)
id
On 2018-12-15 20:54, Joan Moreau wrote:
Daniel,
I have done that so any times (deleteing the data folders, recreating the instance, rest
ecoder" and
"fts_enforced" so you're closer to my setup. Try running again and then post back - I'll
do what I can. Based on the fact that Dovecot+Solr 7.5+my schema is working for me leads me to
believe we can get it working for you as well.
Daniel
On 12/15/2018
now what happens. I agree this can be a mortal pain to
setup - but it's worth it.
Daniel
On 12/21/2018 4:33 AM, Joan Moreau wrote:
Dear Daniel.
Thank you for your kind reply.
Regarding NFS, no, there is nothing like this in my setup.
Deleteing SOLR and recreating it, I did it so ma
Also :
- Java is 10.0.2
- If i delete schema.xml but create only managed-schema, the solr
refuses to start with a java error "schema.xml missing"
On 2018-12-30 08:46, Joan Moreau wrote:
Hi Daniel,
I am on Archlinux. Anyway, I adapted the scripts.
2 questions:
1 - It loo
l, schema.xml, etc..
I made a symlink of the data folder to a second drive (ext4) much bigger
On 2018-12-31 14:09, Daniel Miller wrote:
On 12/29/2018 4:49 PM, Joan Moreau wrote:
Also :
- Java is 10.0.2
Same as me.
- If i delete schema.xml but create only managed-schema, the solr refuses to
and the first line of the diff is :
< this file, see http://wiki.apache.org/solr/SolrConfigXml.
---
this file, see http://wiki.apache.org/solr/SolrConfigXml.
38c38
< 6.4.1
---
7.5.0
So, are you running 6.4.1 or 7.5.0
On 2019-01-02 08:12, Joan Moreau wrote:
The real main diff
e problems
On January 2, 2019 08:16:33 Joan Moreau via dovecot
wrote:
and the first line of the diff is :
< this file, see http://wiki.apache.org/solr/SolrConfigXml.
---
this file, see http://wiki.apache.org/solr/SolrConfigXml.
38c38
< 6.4.1
---
7.5.0
So, are you running 6.4.1 or 7
ome from Solr
or Dovecot
Below my adjusted (corrections from the one of Daniel who is definitely
not working) schema.xml
id
On 2019-01-02 10:04, Joan Moreau wrote:
The first result show "no results" in dovecot for any search by header (I typ
Refinement of the schema.xml (below)
THis however does not solve the "no results" and "Out of range" errors
in Dovecot and Solr
id
cot, Dovecot
returns errors (invalid SID, etc...) and Solr return "out of range
indexes" errors
On 2019-01-02 07:49, Joan Moreau wrote:
Hi
Solr is a standard package in ArchLinux. ("pacman -S solr") . the systemd installation script is included (and it is launching /opt/solr/b
Another bug appearing today:
Jan 02 09:59:08
indexer-worker(j...@grosjo.net)<6777>:
Warning: FTS-SOLR(j...@grosjo.net): Mailbox XX UID=121635 HEADER SIZE
IS HUGE, TRUNCATING
header of the said email has nothing of "huge"
On 2019-01-02 15:22, Joan Moreau via dovecot wrote
of the errors of fts_solr, but maybe
this will help
On 2019-01-02 18:00, Joan Moreau via dovecot wrote:
Another bug appearing today:
Jan 02 09:59:08 indexer-worker(j...@grosjo.net)<6777>: Warning: FTS-SOLR(j...@grosjo.net): Mailbox XX UID=121635 HEADER SIZE IS HUGE, TRUNCATING
h
Hi,
This is the best I can do for having a SCHEMA.XML matching the needs of
an email user. Use case on Solr 7.5.0
(note : this does not solve any of the bugs previously mentionned, but
at least, the logic of Solr is back on track)
---
id
Hi
This is the summary of my work with SOLR-Dovecot, in my QUEST TO
REPRODUCE THE PREVIOULSY EXCELLENT WORK OF FTS_SQUAT
@Aki : Based on the time I have spent on this, I would love to see you
updating the Wiki with those improvements, and adding my name somewhere
@All : Hope it helps
- IN
Hi
This is the summary of my work with SOLR-Dovecot, in my QUEST TO
REPRODUCE THE PREVIOULSY EXCELLENT WORK OF FTS_SQUAT
@Aki : Based on the time I have spent on this, I would love to see you
updating the Wiki with those improvements, and adding my name somewhere
@All : Hope it helps
- IN
What about consedering linking Dovecot with Xapian librairies instead of
going to nightmare Solr ?
https://xapian.org/features
On 2019-01-02 17:10, John Tulp wrote:
On Wed, 2019-01-02 at 00:59 -0800, M. Balridge wrote: The main problem is :
After some time of indexing from Dovecot, Dovecot
feels like writing fts_xapian, go for it.
Aki
On 04 January 2019 at 08:20 Joan Moreau via dovecot wrote:
What about consedering linking Dovecot with Xapian librairies instead of
going to nightmare Solr ?
https://xapian.org/features
On 2019-01-02 17:10, John Tulp wrote:
On Wed, 2019-01-02 at 0
19-01-04 18:49, admin wrote:
A starting point would be to have a look at the current FTS plugins:
https://github.com/dovecot/core/tree/master/src/plugins/fts-solr
and
https://github.com/dovecot/core/tree/master/src/plugins/fts-squat
-M
Am Freitag, den 04.01.2019, 18:17 +0800 schrieb Joan More
_backend_xapian_refresh,
fts_backend_xapian_rescan,
fts_backend_xapian_optimize,
fts_backend_default_can_lookup,
fts_backend_xapian_lookup,
fts_backend_xapian_lookup_multi,
fts_backend_xapian_lookup_done
}
};
On 2019-01-04 20:33, Joan Moreau via dovecot wrote:
Yes but:
1 - is there a documenta
Op 04/01/2019 om 11:17 schreef Joan Moreau via dovecot:
Why not, but please guide me about the core structure (mandatory funcitons,
etc..) of a typical Dovecot FTS plugin
The Dovecot API documentation is not exhaustive everywhere, but the basics are
documented. The remaining questions can b
Anyone willing to explain those functions ?
On January 5, 2019 14:23:10 Joan Moreau via dovecot
wrote:
Thank Stephan
I basically need to know the role/description of each of the functions of
the fts_backend:
struct fts_backend fts_backend_xapian = {
.name = "xapian&quo
Anyone willing to explain those functions ?
Most notably " get_last_uid" "set_build_key" "build_more" , what is refresh
versus rescan ?
On January 5, 2019 14:23:10 Joan Moreau via dovecot
wrote:
Thank Stephan
I basically need to know the role/descripti
the index. */
int fts_backend_rescan(struct fts_backend *backend);
Regards,
Stepham
On January 5, 2019 14:23:10 Joan Moreau via dovecot wrote:
Thank Stephan
I basically need to know the role/description of each of the functions of the
fts_backend:
struct fts_backend fts_backend_xapian = {
.name
for the "last uid"-> this is not the last added, but the maximum of the
UID in the indexed emails, right ?
On 2019-01-06 11:53, Joan Moreau via dovecot wrote:
Thank you
I still don't get the "build_key" function. The email (body, hearders, .. and the uid) is
also, for fts_backend_solr_update_set_build_key -> where is the data (of
the hdr_name or the body) ?
On 2019-01-06 14:10, Joan Moreau wrote:
for the "last uid"-> this is not the last added, but the maximum of the UID in the indexed emails, right ?
On 2019-01-06 11:53,
kend_xxx_update_expunge", so I beleive the
management of the expunged messages is *NOT* in the backend, right ?
On 2019-01-06 15:41, Joan Moreau wrote:
also, for fts_backend_solr_update_set_build_key -> where is the data (of the hdr_name or the body) ?
On 2019-01-06 14:10, Joan Moreau wrote:
for fts_backend_xxx_lookup, where is specidifed in which field (to, cc,
subject, body, from, all) to lookup ?
On 2019-01-06 16:03, Joan Moreau wrote:
For "rescan " and "optimize", wouldn't it be the dovecot core who indicate which are to be dismissed (expunged),
(fts_backend_xapian_lookup(backend,box[i],args,flags,result->box_results[i])<0)
return -1;
i++;
}
return 0;
}
On 2019-01-06 16:31, Joan Moreau via dovecot wrote:
for fts_backend_xxx_lookup, where is specidifed in which field (to, cc,
subject, body, from, all) to lookup ?
On 2019-01-06 16:03, Joan Moreau wrote:
all plugnins (see
below) ?
THank you
On 2019-01-06 16:50, Joan Moreau via dovecot wrote:
and finally , for fts_backend__lookup_multi, why is that backend dependent ?
Would- nt the below function below be the same for any backend ?
Waiting fro your feedback on all those qu
maybe rebuilding a previous email, so *last* uid
is something different than max. And how indexer does know whther there
is a gap wihtout callong the fts backend (whch it does not as there are
no function for that) ?
On 2019-01-08 04:24, Timo Sirainen wrote:
On 7 Jan 2019, at 16.05, Joan More
;namespace';
did you mean 'i_isspace'?
namespace Xapian {
Someone can bring me some light ?
Thanks
On 2019-01-09 09:58, Joan Moreau via dovecot wrote:
Ok.
Additional question :
- for rescan : who is responsible for passing again the new email ? Is the Dovecot core sending again all
there
is a gap wihtout callong the fts backend (whch it does not as there are
no function for that) ?
4 - How to update configure.ac & additional files to add the
"--with-xapian" wichi will test for libxapian presence and add it to the
build ?
Thank you
On 2019-01-08 04:24, Timo S
Joan Moreau via dovecot < dovecot@dovecot.org> wrote:
I managed to deal with the namespace issue (updated makefile.am)
However, I reach :
../../../src/lib/compat.h:207:19: error: conflicting declaration of
'ssize_t i_my_pread(int, void*, size_t, __off_t)' with 'C
" -> this mean at a
certain point, indexer maybe rebuilding a previous email, so *last* uid
is something different than max. And how indexer does know whther there
is a gap wihtout callong the fts backend (whch it does not as there are
no function for that) ?
Thank you
On 2019-01-11 18:27
STATUS
- Alpha code is written and compiling now. (attached)
- I would like to start testing. However, there is an error when
starting dovecot (git) :
Error: Couldn't load required plugin
/usr/lib/dovecot/lib21_fts_xapian_plugin.so: dlopen() failed:
/usr/lib/dovecot/lib21_fts_xapian_plugin.
course no uid.
How come ?
On 2019-01-12 10:50, Aki Tuomi wrote:
Did you remember to load fts first?
mail_plugins =$mail_plugins fts fts_xapian
Aki
On 12 January 2019 at 10:37 Joan Moreau via dovecot < dovecot@dovecot.org> wrote:
STATUS
- Alpha code is written and compilin
Sorted this out. sorry for noise
On 2019-01-12 11:39, Joan Moreau wrote:
The change of "Extern C" suggested by Timo actually solved the situation
Now, further question :
I put a "i_warning" at each of my functions, and I see in the log :
Jan 12 10:33:27
indexer-wo
to
result->definite_uids[1]=my_uid ?
On 2019-01-12 10:25, Timo Sirainen wrote:
On 11 Jan 2019, at 21.23, Joan Moreau via dovecot wrote:
The below patch resolves the compilation error
$ diff -p compat.h compat.h.joan
*** compat.h 2019-01-11 20:21:00.726625427 +0100
--- compat.h.joan 2019-01-11 20:14
ils
For other folder, somehow, the process can not access that (root)
folder.
Am I missing something ?
On 2019-01-12 17:37, Joan Moreau wrote:
THank you
Now, for the results
I see the member of fts_result is :
ARRAY_TYPE(seq_range) definite_uids;
I have the UID as a aray of uint32_t
in hte log that UID are properly found on Xapian database, but
no results are transmitted to dovecot and to the imap client (roundcube
in my case)
Help please :)
On 2019-01-12 18:15, Joan Moreau wrote:
additionally, my logic is that the backend stores one databalse per mailox in /xapian-indexes
I found the solution o this using
SEQ_RANGE_ARRAY_ADD(&RESULT->DEFINITE_UIDS, UID);
Now, I can see in the logs that several times, the dovecot calls the
fts_backend_xapian_update_set_mailbox with box == NULL. WHy so ?
THank you
On 2019-01-12 21:40, Joan Moreau via dovecot wr
Hi
Please find attached the beta release of FTS Xapian, with the objective
to replace fts_squat that is being deprecated.
Configuration is exactly the same as for fts_squat:
plugin {
plugin = fts fts_xapian (...)
fts = xapian
fts_autoindex = yes
fts_enforced = yes
fts_xapian = partial=2 f
Hi
Observing the processes of FTS, I observe the following:
1 - For one user, indexer-wroker does not start several threads for each
request. On teh contrary, it waits for the first request to finish
before starting the second. How to make sure all requests (or a limited
number of it, for inst
remaining point is to push it in hte git (yes, everything is
already done)
On 2019-01-13 18:45, Aki Tuomi wrote:
On 13 January 2019 at 17:05 Joan Moreau via dovecot wrote:
Hi
Please find attached the beta release of FTS Xapian, with the objective
to replace fts_squat that is being deprecated
a link to your plugin on our
FTS page so people can also find it.
There are other plugins like this, e.g.
https://github.com/st3fan/dovecot-xaps-plugin
Aki
On 13 January 2019 at 19:52 Joan Moreau wrote:
The only point here of this fts-xapian is to get rid of solr (because it
is just a
experience problems with the skeleton, let us know.
Aki
On 13 January 2019 at 20:23 Joan Moreau wrote:
Ok for having a link on the FTS page.
PLease clarify what files are necessary to package it as a separate
package
On 2019-01-13 19:03, Aki Tuomi wrote:
Yes, from compiling point of view it
e you writing a new FTS driver? If squat allegedly does everything you need it to do, why don't you just take that plugin and fix it up to do what you need? That seems way easier than trying to create a FTS driver from scratch.
michael
On January 7, 2019 at 7:05 AM Joan Moreau via dovecot w
reconf -vi
./configure --with-dovecot=/path/to/dovecot
make
Aki
On 13 January 2019 at 21:03 Joan Moreau wrote:
THis is already what I send earlier (see : dovecot-xapian-1.0b2.tar.gz
[1 [1]] )
What I would need is the files so one can download (git) it, and type
some command (make ?) to compile it
/MAKEFILE.AM: ERROR: C++ SOURCE SEEN BUT 'CXX' IS UNDEFINED
SRC/MAKEFILE.AM: THE USUAL WAY TO DEFINE 'CXX' IS TO ADD 'AC_PROG_CXX'
SRC/MAKEFILE.AM: TO 'CONFIGURE.AC' AND RUN 'AUTOCONF' AGAIN.
SRC/MAKEFILE.AM:11: WARNING: VARIABLE 'NOPLUGIN_LDFLAGS
te:
You copied your Makefile.am there. Stephan made you a working version, can you try that?
(sorry for dup)
Aki
Original message ----
From: Joan Moreau
Date: 13/01/2019 21:39 (GMT+02:00)
To: Stephan Bosch
Cc: Aki Tuomi
Subject: Re: [FTS Xapian] Beta release
I used the skele
(or wherever dovecot installed its libraries)
On 2019-01-13 21:25, Joan Moreau via dovecot wrote:
I tried to combined it, the "autoreconf" errors are solved
Now, when I type "make install", the lib is not pushed into dovecot folder, but somewhere in /usr/local/...
H
Thank you Stephan.
The version here shall be up and running :
https://github.com/grosjo/fts-xapian
On 2019-01-14 00:07, Stephan Bosch wrote:
Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:
I tried to combined it, the "autoreconf" errors are solved
Now, when I type &qu
Hi Stephan,
What's up with that ?
Thank you so much
On 2019-01-05 02:04, Stephan Bosch wrote:
Hi,
Op 04/01/2019 om 05:36 schreef Joan Moreau via dovecot:
Hi
This is the summary of my work with SOLR-Dovecot, in my *quest to reproduce the
previoulsy excellent work of fts_squat*
?
Also in the part after cloning from git:
./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This /path/to/dovecot is not obvious. Is it the dovecot binary or what??]
On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot wrote:
Thank you Stephan.
The version here shall be up a
edump.conf to no avail). Custom
Dovecot 2.3.4 on Debian Stretch.
Thanks,
Paul
On 14. Jan 2019, at 07:42, Joan Moreau via dovecot wrote:
Thank you Stephan.
The version here shall be up and running : https://github.com/grosjo/fts-xapian
On 2019-01-14 00:07, Stephan Bosch wrote:
Op 13/01/2019 om 21:
il/iwascoding/paul/mdbox/xapian-indexes/db_9ddfe10d8a8a8a568c12654d370e
Jan 14 09:26:08 mail dovecot:
indexer-worker(p...@iwascoding.com)<16777>: Debug:
Mailbox sent: UID 2: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot:
indexer-worker(p...@iwascoding.com)<16777>:
to do that
(usually some separate package).
Regards,
Stephan.
On 14. Jan 2019, at 10:33, Joan Moreau via dovecot mailto:dovecot@dovecot.org>> wrote:
Difficult to figure out without a coredump + gdb
I have also battled quite a lot to make sure dovecot can core dump on my
Archlinux se
It is indeed better is you use the issue tracker of github:
https://github.com/grosjo/fts-xapian/issues
I updated the Readme accordingly
On 2019-01-14 14:24, Stephan Bosch wrote:
Op 14-1-2019 om 13:40 schreef Aki Tuomi:
Just to remind that now that there is a github repo for fts-xapian, y
ot;,
1 warning generated.
Is that something you can look into as well?
On Mon, 14 Jan 2019 at 11:43, Joan Moreau mailto:j...@grosjo.net>> wrote:
THank you Odhiambo. I updated accordingly
On 2019-01-14 08:07, Odhiambo Washington wrote:
In your README.md, perhaps "This project intends t
Hi,
Monitoring the Xapian plugin, I notice that dovecot is re-indexing
multiple times the same Inbox for no apparent reason (not the last email
received but the whole mailbox, LAST UID being properly returned (with
the confusion already discussed) ) : Why so ?
Also, I get a LOCK on the "dovec
Yes, the " -property update.autoCreateFields -value false " seems
interesting
However, we smash the created schema just after
On 2019-01-14 23:25, Stephan Bosch wrote:
Op 14/01/2019 om 07:44 schreef Joan Moreau via dovecot:
Hi Stephan,
What's up with that ?
Thank you so
gjserver dovecot[20984]:
indexer-worker(j...@grosjo.net)<20998>:
DATA2(date)=TUE, 22 JAN 2019 09:25:49 +0100DATE
Jan 22 08:25:50 gjserver dovecot[20984]:
indexer-worker(j...@grosjo.net)<20998>:
DATA(from)="JOAN MOREAU"
Jan 22 08:25:50 gjserver dovecot[20984]:
indexer
Hi
Are data inputs of fts_backend_update_build_more(struct
fts_backend_update_context *_ctx, const unsigned char *data, size_t
size) already converted to UTF8 ?
Thanks
Hi,
FTS Xapian matches my targets for the plugins (replacing deprecated
fts-squat in a production environment)
https://github.com/grosjo/fts-xapian
Please do not hesitate to add "issues" on github, if the case happen
Hope it helps
JM
*- Installation:*
-> Create a clean install using the default, (at least in the Archlinux package), and do
a "sudo -u solr solr create -c dovecot ". The config files are then in
/opt/solr/server/solr/dovecot/conf and datafiles in /opt/solr/server/solr/dovecot/data
On my system (Debian) these
On 2019-01-30 07:33, Stephan Bosch wrote:
(forgot to CC mailing list)
Op 26/01/2019 om 20:07 schreef Joan Moreau via dovecot:
*- Bugs so far*
-> Line 620 of fts_solr dovecot plugin : the size oof header is improperly calculated
("huge header" warning for a simple email, wh
Hi,
THis is a core problem in Dovecot in my understanding.
In my opinion, the rescan in dovecot should send to the FTS plugin the
list of "supposedly" indexed emails (UID), and the plugin shall purge
the redundant UID (i..e UID present in the index but not in the list
sent by dovecot) and send
Hi
Anyone ?
On 2019-02-08 08:54, Joan Moreau via dovecot wrote:
Hi,
THis is a core problem in Dovecot in my understanding.
In my opinion, the rescan in dovecot should send to the FTS plugin the list of "supposedly" indexed emails (UID), and the plugin shall purge the redundant
dle. Anyway, we don't really have time to implement this new API soon.
I'm not sure if this is a big problem though. I don't think most people running FTS have ever run rescan.
On 8 Feb 2019, at 9.54, Joan Moreau via dovecot wrote:
Hi,
THis is a core problem in Dovecot in
t get done.
Aki
On 17 February 2019 at 10:56 Joan Moreau via dovecot
wrote:
In such case, as long as the API is not upgraded, should
doveadm index -A -q \*
be considered a replacement of
doveadm fts rescan
On 2019-02-14 16:24, Timo Sirainen via dovecot wrote:
Hi,
The rescan() fun
Hi
When I do a FTS search (using Xapian plugin) in the BODY part, the
plugins returns the matching IDs within few milliseconds (as seen in the
log).
However, roundcube (connected on dovecot) takes ages to show (headers
only vie IMAP) the few results (I tested with a matching requests of 9
ema
it is already on
On March 31, 2019 03:47:52 Aki Tuomi via dovecot wrote:
On 30 March 2019 21:37 Joan Moreau via dovecot wrote:
Hi
When I do a FTS search (using Xapian plugin) in the BODY part, the plugins
returns the matching IDs within few milliseconds (as seen in the log
the plugins returns properly the IDs)
This is based on GIT version. (previous versions were working properly)
Looking for feedback
Thank you
On 2019-03-30 21:48, Joan Moreau wrote:
it is already on
On March 31, 2019 03:47:52 Aki Tuomi via dovecot wrote:
On 30 March 2019 21:37 Joan
d82b4b0f550d3859364495331209 3038
d82b4b0f550d3859364495331209 3121
d82b4b0f550d3859364495331209 3170
1 - The query is wrong
2 - teh last line "d8...209 3170" gets repeated for ages
On 2019-04-02 16:30, Timo Sirainen wrote:
On 2 Apr 2019, at 6.38, Joan Moreau via dovecot wrote:
Furt
issue seems in the Git version :
FTS search in teh body ends up with looping
Other search call twice the FTS plugin (for no reason)
On 2019-04-03 18:58, @lbutlr via dovecot wrote:
On 3 Apr 2019, at 04:30, Joan Moreau via dovecot wrote:
doveadm search -u j...@grosjo.net mailbox inbox
101 - 200 of 283 matches
Mail list logo
