(and it was working fine before
!)
On 2024-04-21 09:21, Joan Moreau wrote:
Hi
I have
sieve = /mails/%d/%n/sieve/roundcube.sieve
sieve_after = /mails/sieve/after.sieve
sieve_before = /mails/sieve/before.sieve
sieve_dir = /mails/%d/%n/sieve/
sieve_global_dir = /mails/sieve/
But sieve scripts
Hi
I have
sieve = /mails/%d/%n/sieve/roundcube.sieve
sieve_after = /mails/sieve/after.sieve
sieve_before = /mails/sieve/before.sieve
sieve_dir = /mails/%d/%n/sieve/
sieve_global_dir = /mails/sieve/
But sieve scripts are not compiled and not executed
It
That resolve the fisrt bug
but I get now :
Error: link(/xxx/dovecot.list.index.log, /xxx/dovecot.list.index.log.2)
failed: Operation not permitted
On 2024-04-21 02:02, Aki Tuomi via dovecot wrote:
Try setting lock_method = dotlock
Aki
On 20/04/2024 15:32 EEST Joan Moreau via dovecot
:
On 20/04/2024 12:27 EEST Joan Moreau via dovecot
wrote:
Hi
Would placing my storage on a exfat partition work ? If no, why ?
Thank you
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
I can't see
Hi
When I try to "detach"
(https://en.cppreference.com/w/cpp/thread/thread/detach) a thread
running inside a plugin, it seems the core dovecot has some influence on
that , tries to close this for some unknown reason and usually ends up
crashing
What is the cause of this ?
Thank you
Hi
Would placing my storage on a exfat partition work ? If no, why ?
Thank you
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
> To do that kind of a change, mailbox migration is required.
Meaning ?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Hi
I have large number of email (~TB) and want to put the index in a separate,
rapid drive
Initially, I have
mail_location = mdbox:/files/mail/%d/%n
If I put
mail_location = mdbox:/files/mail/%d/%n:INDEX=/data/mailindexes/%d/%n
then dovecot gets totally lost and tries to reach mailboxes content
Thanks Eduardo
I am trying to avoid closing/ reopening a file pointer to the exact same file
between each call to the plugin
On 14 March 2024 20:08:37 Eduardo M KALINOWSKI via dovecot
wrote:
On 14/03/2024 02:49, Joan Moreau via dovecot wrote:
No, you don´t understand
th
a) services (internal or external), such as redis, sql, or something
else
b) storing things to disk
Aki
On 13/03/2024 18:45 EET Joan Moreau via dovecot
wrote:
No, I am not referring to that
I want to create an
for storing this
kind of stateful data. When deinit is called the calling core process
will likely die too.
Aki
On 13/03/2024 10:19 EET Joan Moreau wrote:
Keep a pointer in memory retrievable each time a plugin is
called
So the plugin keep
Keep a pointer in memory retrievable each time a plugin is called
So the plugin keep the memory, not has to restart everything at each call
On 12 March 2024 08:53:38 Aki Tuomi via dovecot wrote:
On 11/03/2024 10:42 EET Joan Moreau wrote:
Hi
Is it possible
Hi
Is it possible, from a plugin perspective, to create and recover a pointer in
the core process (i.e. memory not lost between 2 calls to the plugin, even
after the "deinit" of the plugin" ) ?
Thanks
___
dovecot mailing list -- dovecot@dovecot.org
To
other existing
plugins from all over the world
On 2021-09-12 13:54, Aki Tuomi wrote:
On 12/09/2021 15:12 Bob Marcan wrote:
On Sun, 12 Sep 2021 11:36:46 +0100
Joan Moreau wrote:
This is where I am for now :
https://koji.fedoraproject.org/koji/packageinfo?packageID=34417
Probably, I should
Thank you for notice.
What is the process to rebuild the package with recent dovecot, as
1.4.12-2 (instead of existing 1.4.12-1) ?
On 2021-09-12 07:21, Bob Marcan wrote:
Problem with the dovecot-fts-xapian package.
Fedora 34 with latest updates.
dovecot-2.3.16-1.fc34.x86_64
Just for clarity, Open-Xchange has not written any xapian plugin
whatsoever.
Yes but the doc says that Open Xchaneg "supports" one over the other.
Honestly, I am doing this over my free time, begin very reactive to user
requests, and have this confirmed by Debian, Archlinux and now Fedora in
Hi
There seems to be 2 plugins doing the same thins
- https://github.com/slusarz/dovecot-fts-flatcurve/
- https://github.com/grosjo/fts-xapian/ (mine)
Both are in the doc of dovecot
https://doc.dovecot.org/configuration_manual/fts/
I am currently working hard to push it to RPM package, and
Well, I don't really understand your note.
Bottom-line : 2.3.16 crashes every now and then.
Maybe is there a quick fix for production servers ?
On 2021-08-09 10:27, Timo Sirainen wrote:
On 9. Aug 2021, at 11.24, Timo Sirainen wrote:
On 9. Aug 2021, at 11.03, Joan Moreau wrote:
#0
__ = "io_loop_call_io"
#10 0x7f2370f72fc2 in io_loop_handler_run_internal
(ioloop=ioloop@entry=0x55b8af425ec0) at ioloop-epoll.c:222
On 2021-08-06 13:49, Aki Tuomi wrote:
On 06/08/2021 15:43 Joan Moreau wrote:
Thank you Timo
However, this leads to
kernel: imap[228122]: s
git clone -b release-2.3.16
On 2021-08-06 15:07, Timo Sirainen wrote:
On 6. Aug 2021, at 15.08, Joan Moreau wrote:
Below
(gdb) bt full
#0 fts_user_autoindex_exclude (box=,
box@entry=0x55e0bc7e0fe8) at fts-user.c:347
There is no such function in 2.3.16 release. That's only in the current
nput (cmd=) at
imap-client.c:1230
client = 0x55e0bc7d6298
command =
tag = 0x7f42e942d8fa
"]A\\A]\303\061\300\303ff.\017\037\204"
name = 0x55e0bbd26e50 "SELECT"
ret =
On 2021-08-06 13:49, Aki Tuomi wrote:
On 06/08/2021 15:43 Joan Moreau wrote:
Thank you Timo
How
Thank you Timo
However, this leads to
kernel: imap[228122]: segfault at 50 ip 7f7015ee332b sp
7fffa7178740 error 4 in lib20_fts_plugin.so[7f7015ee1000+11000]
Returning to 2.3.15 resolves the problem
On 2021-08-06 12:42, Timo Sirainen wrote:
Hi,
One interesting thing in this
It is now very out of date.
@Jello : Kindly update please
On 2021-03-21 12:58, André Rodier wrote:
Hello,
The version packaged on Bullseye is slightly out of date, I have filled
a bug report:
https://bugs.debian.org/985654
Thanks to the maintainers for their hard work!
André
On Sun,
, Joan Moreau wrote:
Ok, a third regression is that it becomes highly unstable with the
patch you sent
I had to get back to 2.3.14
On 2021-04-27 17:07, Joan Moreau wrote:
Indeed, latest git works much better :)
On 2021-04-27 05:58, Aki Tuomi wrote:
Can you try with latest git? We did some
Ok, a third regression is that it becomes highly unstable with the patch
you sent
I had to get back to 2.3.14
On 2021-04-27 17:07, Joan Moreau wrote:
Indeed, latest git works much better :)
On 2021-04-27 05:58, Aki Tuomi wrote:
Can you try with latest git? We did some improvements
Indeed, latest git works much better :)
On 2021-04-27 05:58, Aki Tuomi wrote:
Can you try with latest git? We did some improvements on the systemd
configure parts.
Aki
On 26/04/2021 23:32 Joan Moreau wrote:
Looking at config.log, there is #define HAVE_LIBSYSTEMD 1
But "Type=notify&
Looking at config.log, there is #define HAVE_LIBSYSTEMD 1
But "Type=notify" does not appear
My systemd is version 248
On 2021-04-26 12:05, Joan Moreau wrote:
I have
# sudo systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
Loaded: loaded (/usr/lib/syst
's using Type=notify.
Aki
On 26/04/2021 10:29 Joan Moreau wrote:
Yes, I do run autogen.sh after every "git pull"
On 2021-04-26 08:21, Aki Tuomi wrote: The current autoconf code is bit
buggy, but if you do indeed have libsystemd-dev installed it should do
the right thing and will work
n actually tested, so if it's not working, then something
else is wrong.
Did you remember to run ./autogen.sh after pulling from git to make
sure you get new configure script?
Aki
On 26/04/2021 10:11 Joan Moreau wrote:
Yes systemd is installed (and the "dev" files as well)
On 2021-04
22:53 Joan Moreau wrote:
Yes, it seems fixed with this patch :)
Another bug with git, is the "type=" in systemd is switched from
"simple" to "notify". The later does not work and reverting to "simple"
does work
On 2021-04-25 17:53, Aki Tuomi wrote: On 24
Yes, it seems fixed with this patch :)
Another bug with git, is the "type=" in systemd is switched from
"simple" to "notify". The later does not work and reverting to "simple"
does work
On 2021-04-25 17:53, Aki Tuomi wrote:
On 24/04/2021 21:56 Joan
_binary_run (binary=,
argc=, argv=) at main.c:562
service_flags =
set_pool = 0x55d70a144de0
login_socket = 0x7f7a3337337d "login"
c =
#17 0x7f7a32feeb25 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#18 0x55d70
Hello
On latest git of dovecot, I get
Apr 24 04:07:36 gjserver dovecot[857958]: imap-login: Panic: file
client-common.c: line 293 (client_disconnect): assertion failed:
(client->prev == NULL && client->next == NULL)
and login process crash
On 2.3.14, there is no problems
Hope it helps
JM
Hello
Anyone on this ?
Thank you
On 2021-03-28 20:55, Joan Moreau wrote:
yes, this is getting to a mess
Details can be seen here :
https://github.com/grosjo/fts-xapian/issues/72
It shows that sometimes mailbox_list_get_root_forced return the generic
INDEX value, sometimes the namespace
!
mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex
This is going to put everyone's indexes under /var/mailindex, without
separating them properly. Might cause fun issues.
Can you give an concrete example of what your issue is?
Aki
On 28/03/2021 13:35 Joan Moreau wrote
Hi
Anyone on that ?
Thank you so much
On 2021-03-22 18:16, Joan Moreau wrote:
Hi
The function mailbox_list_get_root_forced returns sometimes the first
or the second value of the INDEX param for the same mailbox.
How to make sure this returns only the correct one of the corresponding
Hi
The function mailbox_list_get_root_forced returns sometimes the first or
the second value of the INDEX param for the same mailbox.
How to make sure this returns only the correct one of the corresponding
mailbox ?
mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex
I do that each time
The problem arises on recent git only
On 2021-03-04 08:16, Aki Tuomi wrote:
Try running `autoreconf -vi`
Aki
On 04/03/2021 10:13 Joan Moreau wrote:
I already have this file (dovecot compilation was working fine until
recent git)
[root@gjserver dovecot]# ls -al /usr
which contains
/usr/share/aclocal/gettext.m4
or similar. This provides AM_ICONV.
Aki
On 04/03/2021 10:07 Joan Moreau wrote:
Hello
I already have gettext
[root@gjserver dovecot]# pacman -S gettext
warning: gettext-0.21-1 is up to date -- reinstalling
resolving dependencies...
looking
On 2021-03-04 08:03, Aki Tuomi wrote:
You need to install gettext
Aki
On 04/03/2021 10:02 Joan Moreau wrote:
Hello,
With latest git, I get the following error :
configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate
Hello,
With latest git, I get the following error :
configure.ac:761: the top level
configure.ac:22: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.ac:205: error: possibly
Created a PR
https://github.com/dovecot/core/pull/155
On 2021-02-11 13:25, Joan Moreau wrote:
Hello
Checking further, and putting logs a bit every where in the dovecot
code, the core is sending FIRST the initial document (not decoded) then
SECOND the decoded version
Thisi is really weird
this double call is made.
Anyone knows ?
On 2021-02-10 00:05, John Fawcett wrote:
On 09/02/2021 15:33, Joan Moreau wrote:
If I place the following code in the plugin
fts_backend_xxx_update_build_more function (lucene, squat and xapian,
as solr refuses to work properly on my setup)
{
char * s
Something is wrong in the data transmission
On 2021-02-09 11:58, John Fawcett wrote:
On 08/02/2021 23:05, Stuart Henderson wrote: On 2021/02/08 21:33, Joan
Moreau wrote: Yes , once again : output of the decoder is fine, I also
put log inide the dovecot core to
check whether data is properly transmitted,
of the decoder and /not/ the original
data ?
On 2021-02-08 21:11, Stuart Henderson wrote:
On 2021-02-08, Joan Moreau wrote:
Well, in the function xxx_build_more of FTS plugin, the data received
in
the original PDF, not the output of pdftotext
Can you clarify where do you put your log in the solr
-02-08 21:11, Stuart Henderson wrote:
On 2021-02-08, Joan Moreau wrote:
Well, in the function xxx_build_more of FTS plugin, the data received
in
the original PDF, not the output of pdftotext
Can you clarify where do you put your log in the solr plugin , so I
can
check the situation
15:22, Joan Moreau wrote:
Well, thank you for the answer, but the actual issue is that data sent
by the decoder (stipulated in the conf file) is properly collected by
dovecot core, but /not/ sent to the plugin : the plugin receives the
original data.
This is not linked to a particular plugin
..)
but seems to be a general issue of dovecot core
On 2021-02-08 01:03, John Fawcett wrote:
On 07/02/2021 18:51, Joan Moreau wrote:
more info : the function fts_parser_script_more in
plugins/fts/fts-parser.c properly read the output of the script
still, the data is not sent to the FTS
more info : the function fts_parser_script_more in
plugins/fts/fts-parser.c properly read the output of the script
still, the data is not sent to the FTS pligins (xapian or any other)
On 2021-02-07 17:37, Joan Moreau wrote:
more info : I am running dovecot git version
On 2021-02-07 17:15
more info : I am running dovecot git version
On 2021-02-07 17:15, Joan Moreau wrote:
a bit more on this, adding log in the decode2text.sh, I can see that
pdftotext output the right data, but that data is /not/ transmitted to
the fts plugin for indexing (only the original pdf code
a bit more on this, adding log in the decode2text.sh, I can see that
pdftotext output the right data, but that data is /not/ transmitted to
the fts plugin for indexing (only the original pdf code is)
On 2021-02-07 17:00, Joan Moreau wrote:
Hello,
I am trying to deal properly with email
Hello,
I am trying to deal properly with email attachements in fts-xapian
plugins.
I tried the default script with a PDF file.
The data I receive in the fts plugin part ("xxx_build_more") is the
original document, no the output of the pdftotext
Is there anything I am missing ?
Here my
Soirry, I always forget that dovecot does not do multi-threading (why ?)
The process was waiting for another process.
On 2021-01-11 14:57, Aki Tuomi wrote:
On 11/01/2021 16:51 Joan Moreau wrote:
Hello,
With recent git version of dovecot, I can see that the FTS does not
use the configured
Hello,
With recent git version of dovecot, I can see that the FTS does not use
the configured plugin anymore, but tries to sort the mailbox directly on
the spot (which is of course very painful).
Is there a change in the configuration file in order to recover the old
behavior ? or something
) and read the
correct line. Do you have a better way ?
thank you
On 2020-11-06 14:16, Joan Moreau wrote:
ok found it,
However, it returns me some random number. Maybe I am missing something
On 2020-11-06 13:57, Aki Tuomi wrote:
Duh... src/lib/restrict-process-size.h
Should be in the install
find
out current usage.
Aki
On 06/11/2020 13:26 Joan Moreau wrote:
yes, will do so.
It would be nice however to be able to access the actual dovecot config
from the plugin side
On 2020-11-04 06:46, Aki Tuomi wrote: You could also add it as setting
for the fts_xapian plugin parameters?
Aki
ut current usage.
Aki
On 06/11/2020 13:26 Joan Moreau wrote:
yes, will do so.
It would be nice however to be able to access the actual dovecot config
from the plugin side
On 2020-11-04 06:46, Aki Tuomi wrote: You could also add it as setting
for the fts_xapian plugin parameters?
Aki
On 04/
Hello
I have this issue for Xapian plugin:
https://github.com/grosjo/fts-xapian/issues/62
But I am not sure where can it comes from.
Is dovecot calling some specific function in the plugin after the init,
that would create such error ?
In doveadm dealing differently with plugins that
yes, will do so.
It would be nice however to be able to access the actual dovecot config
from the plugin side
On 2020-11-04 06:46, Aki Tuomi wrote:
You could also add it as setting for the fts_xapian plugin parameters?
Aki
On 04/11/2020 08:42 Joan Moreau wrote:
For machines with low
ely, and I can "if ram remaining is above X") but the is really
not clean
On 2020-11-04 06:28, Aki Tuomi wrote:
On 04/11/2020 05:19 Joan Moreau wrote:
Hello
I am looking for help around memory management
1 - How to get the current value of "vsz_limit" from inside a plug
Hello
I am looking for help around memory management
1 - How to get the current value of "vsz_limit" from inside a plugin
(namely https://github.com/grosjo/fts-xapian/ ) , especially for
indexer-worker
2 - Is there a macro or function in dovecot to get the remaining free
memory from this
Maybe try
fts_autoindex_exclude = \EXPUNGED
On 2020-08-29 14:34, Gregory Heytings wrote:
Hi list,
I have both lazy_expunge and fts_autoindex activated (with fts-xapian),
as follows:
plugin {
lazy_expunge = EXPUNGED/
}
plugin {
fts = xapian
fts_xapian = partial=2 full=20 attachments=1
Hello
Indexer does not run as root
It runs as "mail_uid = xxx" (based on your config)
dovecot-fts-xapian is easy to configure, but has a big downside compared
to solr in that the indexer runs as root.
Hello,
Moving a large number of email from one folder to another does create
timeout on roundcube, due to either a very very large number of emails
or indexing process that increases the processing time.
Would it make sense to have a background thread, to process orders
asynchronously,
I updated fts-xapian to make it compatible with dovecot 2.2
On 2020-02-04 12:37, Peter Chiochetti wrote:
Am 04.02.20 um 11:46 schrieb Francis Augusto Medeiros-Logeay:
Hi Philon,
Thanks a lot for your thoughts!
Can I ask you if using Solr improved things for you? I have a mailbox with 15
Please kindly file an issue on github, together with an example of email
causing the panic
On 2019-11-11 15:21, Yarema via dovecot wrote:
Set up fts_xapian over the weekend and re-indexed.
https://github.com/grosjo/fts-xapian
Tried to search my INBOX and got:
dovecot: indexer-worker:
Hi
The first run of indexing on a large existing mailbox is indeed slow,
and I would run "doveadm index -A -q \*" before putting the system in
production.
Besides the Ram disk, what kind of solution would you suggest ?
On 2019-12-10 19:28, Wojciech Puchar via dovecot wrote:
Where do
It seems this comes from the old version of gcc/stdlib also.
Please kindly file a "issue" on github
https://github.com/grosjo/fts-xapian/issues
On 2019-12-15 21:35, Martynas Bendorius wrote:
Core was generated by `dovecot/indexer-worker'.
Program terminated with signal 11, Segmentation
) when querying "regular" folders - but results are shown in clients.
--
Daniel
On June 6, 2019 12:16:08 AM Joan Moreau wrote:
Hi
Are you using the latest git version ?
WHich part exactly of your logs relates to "virtual folders do not work" ?
On 2019-06-05 13:0
Hi
Are you using the latest git version ?
WHich part exactly of your logs relates to "virtual folders do not work"
?
On 2019-06-05 13:08, Daniel Miller via dovecot wrote:
Logs:
Jun 5 06:02:25 bubba dovecot: imap(dmil...@amfes.com)<25877>:
Opening DB (RO)
Hi
Can you post your dovecot conf file and the subset of the log files related
to the issue ?
thanks
On June 5, 2019 9:29:13 AM Daniel Miller via dovecot
wrote:
For my primary namespace this is working fine - thanks to the developers!
It also appears to work great for shared folders
Hi,
Additionally to the long list of problem on the FTS previously
discussed, here a new:
WHen I reset the indexes, the indexer-worker seems paralelleizing the
indexing (which is good), however, the number available in "ps aux |
grep dove" shows that it does not move:
dovecot 28549 0.0
jserver dovecot[14251]:
imap(j...@grosjo.net)<15709>: Testing if wildcard
Apr 21 11:08:39 gjserver dovecot[14251]:
imap(j...@grosjo.net)<15709>: Query : ( bcc:milao ) OR
( cc:milao ) OR ( from:milao ) OR ( subject:milao ) OR ( to:milao )
Apr 21 11:08:39 gjserver dovecot[14251]:
ima
g the FTS lookup ignored.
On 21 Apr 2019, at 19.50, Joan Moreau wrote:
No, the parsing is made by dovecot core, that is nothing the backend can do about it. The backend shall *never* reveive this. (would it be buggy or no)
PLease, have a look deeper
And the loop is a very big p
of the backend functions)
On 2019-04-21 10:42, Timo Sirainen via dovecot wrote:
Inbox appears in the list of arguments, because fts_backend_xapian_lookup() is parsing the search args wrong. Not sure about the other issue.
On 21 Apr 2019, at 19.31, Joan Moreau wrote:
For this first point, the problem
h parameters
On 2019-04-21 10:31, Joan Moreau via dovecot wrote:
For this first point, the problem is that dovecot core sends TWICE the request and "Inbox" appears in the list of arguments ! (inbox shall serve to select teh right mailbox, never sent to the backend)
And even if th
ER
On 2019-04-21 09:57, Timo Sirainen via dovecot wrote:
On 3 Apr 2019, at 20.30, Joan Moreau via dovecot wrote:
doveadm search -u j...@grosjo.net mailbox inbox text milan
output
doveadm(j...@grosjo.net): Info: Query : ( bcc:inbox OR body:inbox OR cc:inbox
OR from:inbox OR mes
I have no idea how to use git-bitsec
On 2019-04-15 15:31, Josef 'Jeff' Sipek wrote:
On Sun, Apr 14, 2019 at 21:09:54 +0800, Joan Moreau wrote:
...
THe "loop" part seems the most urgent : It breaks everything (search
timeout 100% of the time)
Any luck with git-bisect?
Jeff.
g and must be totally reviewed.
I do not have the time but I can participate in testing if someone is
ready to roll up its sleeves on teh mater
THe "loop" part seems the most urgent : It breaks everything (search
timeout 100% of the time)
On 2019-04-06 09:56, Joan Moreau via dovecot wrot
returns X, then dovecot core choose to select only Y emails.
THis is a clear bug.
On 2019-04-05 20:08, Josef 'Jeff' Sipek via dovecot wrote:
On Fri, Apr 05, 2019 at 19:33:57 +0800, Joan Moreau via dovecot wrote:
Hi
If you plan to fix the FTS part of Dovecot, I will be very gratefull.
I'm trying to
9-04-05 18:37, Josef 'Jeff' Sipek wrote:
On Fri, Apr 05, 2019 at 17:45:36 +0800, Joan Moreau wrote:
I am on master (very latest)
No clue exactly when this problem appears, but
1 - the "request twice the fts plugin instead of once" issue has always
been there (since my first RC rel
On 2019-04-05 16:36, Josef 'Jeff' Sipek via dovecot wrote:
On Wed, Apr 03, 2019 at 19:02:52 +0800, Joan Moreau via dovecot wrote:
issue seems in the Git version :
Which git revision?
Before you updated to the broken revision, which revision/version were you
running?
C
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
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:
F
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
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
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
d not 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
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 my understanding.
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
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
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
*- 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
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
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
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-worker(j.
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 much
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
ated.
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 to provide a
straight
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,
1 - 100 of 219 matches
Mail list logo
