[UPDATE] dovecot-fts-xapian to 1.2.9
Diff below updates dovecot-fts-xapian to 1.2.9.
I've tested this on amd64 by reindexing a 10,000 msg+ mailbox with
attachments, seems to behave correctly.
Upstream added a new parameter to control whether attachments are
indexed (user reported a Perl attachment caused memory exhaustion in
Xapian). This is described with the other parameters in the pkg/README
in lieu of a man page.
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile6 Feb 2020 11:30:32 - 1.1.1.1
+++ Makefile15 Feb 2020 00:55:55 -
@@ -2,7 +2,7 @@
COMMENT= full text search plugin for Dovecot using Xapian
-V= 1.2.8
+V= 1.2.9
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
Index: distinfo
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo6 Feb 2020 11:30:32 - 1.1.1.1
+++ distinfo15 Feb 2020 00:55:55 -
@@ -1,2 +1,2 @@
-SHA256 (fts-xapian-1.2.8.tar.gz) = Y/B+xscRAkop9Blfl+eX1ORcXQ8jFpej46PqD/9qgmU=
-SIZE (fts-xapian-1.2.8.tar.gz) = 25982
+SHA256 (fts-xapian-1.2.9.tar.gz) = eCEyXJh9eAjwZeadFWSFOi4JD9ZIddYP7eUeoaT/ryA=
+SIZE (fts-xapian-1.2.9.tar.gz) = 26516
Index: pkg/README
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/pkg/README,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 README
--- pkg/README 6 Feb 2020 11:30:32 - 1.1.1.1
+++ pkg/README 15 Feb 2020 00:55:55 -
@@ -18,13 +18,22 @@ Then configure the plugin's settings in
plugin {
fts = xapian
- fts_xapian = partial=2 full=20 verbose=0
+ fts_xapian = partial=2 full=20 attachments=0 verbose=0
fts_autoindex = yes
fts_enforced = yes
fts_autoindex_exclude = \Trash
}
+
+Parameters 'partial' and 'full' are required, and allow control over the length
+of n-grams generated for searching header fields.
+
+Parameter 'attachments' defaults to off. Setting it to 1 will enable indexing
of
+text attachments.
+
+Parameter 'verbose' can be set between 0 (default) and 2 (debug) for more
+detailed logging.
New mail will be indexed incrementally. Use doveadm-index(1) to index
existing mail, e.g.:
Re: neomutt-20200313-gpgme-sasl error sending from command line
On Thu, Mar 19 '20 at 08.14 NZDT, myportslist20190...@nym.hush.com wrote: > Synopsis: neomutt-20200313-gpgme-sasl error sending command line email Looks like it's a known bug, see https://github.com/neomutt/neomutt/issues/2176 (caused by commit 331702b with comment "abort if run without a terminal" heh; quality control not quite as good as mainline mutt yet). Fixed a couple of days ago but not included in a release yet.
[UPDATE] dovecot-fts-xapian to 1.3
Diff below updates dovecot-fts-xapian to 1.3.
Author likes to drop the .0 on a new minor version; does the port system
care about that, or should I add the third digit back in to PKGNAME?
Changes:
- There is a new dependency on sqlite3; this is used to speed up
expunges
- Author has clarified some details around the vsz_limit parameter.
Looking at dovecot docs, increasing default_vsz_limit doesn't seem
necessary, so README changed to reflect this.
- A small patch added in to fix up a couple of compiler warnings with
printf formats. One minor (using %d for a long), one more serious
(trying to treat a C++ class as a plain-text c-string). These have
been fed back to author today so hopefully can be removed next
release.
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile
--- Makefile15 Feb 2020 15:38:26 - 1.3
+++ Makefile12 Apr 2020 05:22:12 -
@@ -2,15 +2,13 @@
COMMENT= full text search plugin for Dovecot using Xapian
-V= 1.2.9
+V= 1.3
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
GH_TAGNAME=${V}
PKGNAME= dovecot-fts-xapian-${V}
-# remove DISTNAME at next update; upstream rerolled the distfile
-DISTNAME= fts-xapian-${V}-1
REVISION= 0
CATEGORIES=mail
@@ -22,8 +20,8 @@ MAINTAINER= Tom Wong-Cornall 0) i_info("FTS Xapian: Deleting terms for expunged
UID=%d (Docid=%d)",u,d);
++ if(verbose>0) i_info("FTS Xapian: Deleting terms for expunged
UID=%ld (Docid=%d)",u,d);
+ try
+ {
+ backend->dbw->delete_document(d);
+@@ -898,7 +898,9 @@ bool fts_backend_xapian_index_hdr(Xapian::WritableData
+ }
+ catch(Xapian::Error e)
+ {
+- i_error("FTS Xapian: fts_backend_xapian_index_hdr (%s) ->
%s",field,data);
++ std::string s;
++ data->toUTF8String(s);
++ i_error("FTS Xapian: fts_backend_xapian_index_hdr (%s) ->
%s",field,s.c_str());
+ i_error("FTS Xapian: %s",e.get_msg().c_str());
+ }
+ return false;
Index: pkg/README
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/pkg/README,v
retrieving revision 1.2
diff -u -p -u -r1.2 README
--- pkg/README 15 Feb 2020 08:51:23 - 1.2
+++ pkg/README 12 Apr 2020 05:22:12 -
@@ -10,9 +10,11 @@ most users:
mail_plugins = (...) fts fts_xapian (...)
-The default_vsz_limit will usually need to be increased in 10-master.conf:
+The service's vsz_limit may need to be increased (or disabled) in
10-master.conf:
-default_vsz_limit = 2GB
+service indexer-worker {
+ vsz_limit = 0 # or 1GB etc.
+}
Then configure the plugin's settings in 90-plugin.conf:
Anyone working on fts-xapian (Dovecot)?
Hello, I have been running fts-xapian (full-text search indexing for Dovecot) for a little while and have a feeling others might find some use for a port. It's nice to have decent FTS for IMAP without having to install a monster like Apache Solr. If somebody's already started, please let me know, otherwise I'll begin work on it. Cheers, Tom
[NEW] dovecot-fts-xapian
Please see attached port for fts_xapian (Dovecot FTS plugin) [1]. --- fts-xapian is a full-text search plugin for Dovecot. It utilises the Xapian search engine library to index email automatically, and allow rapid body and header server-side search over IMAP. The authors intend this plugin to provide the functionality provided by the now-deprecated fts_squat plugin, and provide a simpler way to configure FTS for Dovecot without needing heavy external dependencies such as Solr. --- This is my first time porting, please point out where I've gone wrong. I'm a little unsure the semantics of putting mail/dovecot in BUILD_DEPENDS; my reasoning: - fts-xapian doesn't link to dovecot itself, so it shouldn't be in LIB_DEPENDS (dovecot dlopen's fts-xapian at runtime) - dovecot-config is required at build, so it can't just be in RUN_DEPENDS - Putting mail/dovecot into both BUILD_DEPENDS and RUN_DEPENDS seemed to cause breakage during build [1] https://github.com/grosjo/fts-xapian dovecot-fts-xapian.tar.gz Description: application/gzip
Re: [NEW] dovecot-fts-xapian
On Sun, Feb 2 '20 at 23.56 NZDT, Stuart Henderson wrote: > Updated tar.gz attached, comments inline: Thank-you for fixing and annotating my silly mistakes, it's much appreciated. Some further time reading bsd.port.mk(5) is required. > (I guess you're running on 6.6 and will need to remove the @so marker to get > the port to package on your system, but it should be there for the commit). Guilty as charged. While I tested the package on -current, I'm not quite brave enough to run my live mailserver on a rolling release. As such this has had limited testing on -current. If anyone has a good methodology for properly smoke-testing a full mail stack (smtpd, Dovecot, rspamd etc.) on -current, let me know off-list; I'd be all ears. Maybe regular dsync to a sandbox server? Thanks, Tom
Re: [UPDATE] dovecot-fts-xapian to 1.3
On Sun, Apr 12 '20 at 17.33 NZST, Tom Wong-Cornall wrote:
> Diff below updates dovecot-fts-xapian to 1.3.
>
> Author likes to drop the .0 on a new minor version; does the port system
> care about that, or should I add the third digit back in to PKGNAME?
>
> Changes:
> - There is a new dependency on sqlite3; this is used to speed up
>expunges
>
> - Author has clarified some details around the vsz_limit parameter.
>Looking at dovecot docs, increasing default_vsz_limit doesn't seem
>necessary, so README changed to reflect this.
>
> - A small patch added in to fix up a couple of compiler warnings with
>printf formats. One minor (using %d for a long), one more serious
>(trying to treat a C++ class as a plain-text c-string). These have
>been fed back to author today so hopefully can be removed next
>release.
ping -- although with the work going into 6.7 not sure if people have
had any time to try it out. Faster expunges are not mission-critical :)
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 Makefile
> --- Makefile 15 Feb 2020 15:38:26 - 1.3
> +++ Makefile 12 Apr 2020 05:22:12 -
> @@ -2,15 +2,13 @@
>
> COMMENT= full text search plugin for Dovecot using Xapian
>
> -V= 1.2.9
> +V= 1.3
>
> GH_ACCOUNT= grosjo
> GH_PROJECT= fts-xapian
> GH_TAGNAME= ${V}
> PKGNAME= dovecot-fts-xapian-${V}
>
> -# remove DISTNAME at next update; upstream rerolled the distfile
> -DISTNAME= fts-xapian-${V}-1
> REVISION=0
>
> CATEGORIES= mail
> @@ -22,8 +20,8 @@ MAINTAINER= Tom Wong-Cornall # LGPLv2.1
> PERMIT_PACKAGE= Yes
>
> -WANTLIB += ${COMPILER_LIBCXX} icudata icui18n icuio icuuc m uuid
> -WANTLIB += xapian z
> +WANTLIB += ${COMPILER_LIBCXX} icudata icui18n icuio icuuc m sqlite3
> +WANTLIB += uuid xapian z
>
> COMPILER=base-clang ports-gcc
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/dovecot-fts-xapian/distinfo,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 distinfo
> --- distinfo 15 Feb 2020 15:38:26 - 1.3
> +++ distinfo 12 Apr 2020 05:22:12 -
> @@ -1,2 +1,2 @@
> -SHA256 (fts-xapian-1.2.9-1.tar.gz) =
> aiOyGs0V31JMA9mlN2BqHkIuZ0gXVl7fD6gL0govYog=
> -SIZE (fts-xapian-1.2.9-1.tar.gz) = 26510
> +SHA256 (fts-xapian-1.3.tar.gz) = u3S3ri1mFsRmdA6XytiDdtf/jUsMTGTi4N4suocbPE0=
> +SIZE (fts-xapian-1.3.tar.gz) = 27628
> Index: patches/patch-src_fts-backend-xapian-functions_cpp
> ===
> RCS file: patches/patch-src_fts-backend-xapian-functions_cpp
> diff -N patches/patch-src_fts-backend-xapian-functions_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_fts-backend-xapian-functions_cpp12 Apr 2020
> 05:22:12 -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +
> +Index: src/fts-backend-xapian-functions.cpp
> +--- src/fts-backend-xapian-functions.cpp.orig
> src/fts-backend-xapian-functions.cpp
> +@@ -583,7 +583,7 @@ static void fts_backend_xapian_expunge(struct xapian_f
> + d = xfe.did[i];
> + u = xfe.uid[i];
> +
> +-if(verbose>0) i_info("FTS Xapian: Deleting terms for expunged
> UID=%d (Docid=%d)",u,d);
> ++if(verbose>0) i_info("FTS Xapian: Deleting terms for expunged
> UID=%ld (Docid=%d)",u,d);
> + try
> + {
> + backend->dbw->delete_document(d);
> +@@ -898,7 +898,9 @@ bool fts_backend_xapian_index_hdr(Xapian::WritableData
> + }
> + catch(Xapian::Error e)
> + {
> +-i_error("FTS Xapian: fts_backend_xapian_index_hdr (%s) ->
> %s",field,data);
> ++std::string s;
> ++data->toUTF8String(s);
> ++i_error("FTS Xapian: fts_backend_xapian_index_hdr (%s) ->
> %s",field,s.c_str());
> + i_error("FTS Xapian: %s",e.get_msg().c_str());
> + }
> + return false;
> Index: pkg/README
> ===
> RCS file: /cvs/ports/mail/dovecot-fts-xapian/pkg/README,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 README
> --- pkg/README15 Feb 2020 08:51:23 - 1.2
> +++ pkg/README12 Apr 2020 05:22:12 -
> @@ -10,9 +10,11 @@ most users:
>
> mail_plugins = (...) fts fts_xapian (...)
>
> -The default_vsz_limit will usually need to be increased in 10-master.conf:
> +The service's vsz_limit may need to be increased (or disabled) in
> 10-master.conf:
>
> -default_vsz_limit = 2GB
> +service indexer-worker {
> + vsz_limit = 0 # or 1GB etc.
> +}
>
> Then configure the plugin's settings in 90-plugin.conf:
>
>
[UPDATE] dovecot-fts-xapian to 1.3.1, and RUN_DEPENDS query
Hi ports,
Diff below updates dovecot-fts-xapian from 1.2.9 to 1.3.1. I posted
previous update to 1.3 close to freeze, so repeating the changes from
then (less the patches I included which are now rolled into 1.3.1):
Changes:
- There is a new dependency on sqlite3; this is used to speed up
expunges
- Author has clarified some details around the vsz_limit parameter.
Looking at dovecot docs, increasing default_vsz_limit doesn't seem
necessary, so README changed to reflect this.
- Timeouts on indexing, so if using lots of memory and taking forever
on some big messages it will commit at least something before
resuming
- New index optimization function
Question re. BUILD_ and RUN_DEPENDS; user has reported (running -stable)
that `pkg_add dovecot dovecot-fts-xapian` fails because
dovecot-fts-xapian-1.2.9p0 depends on dovecot-2.3.10p0v0;
dovecot-2.3.10.1v0 is in -stable. Is there something else I should be
doing to cause a rebuild to happen when dovecot is bumped, or should I
have manually bumped dovecot-fts-xapian?
---
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile
--- Makefile15 Feb 2020 15:38:26 - 1.3
+++ Makefile27 May 2020 08:00:58 -
@@ -2,15 +2,13 @@
COMMENT= full text search plugin for Dovecot using Xapian
-V= 1.2.9
+V= 1.3.1
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
GH_TAGNAME=${V}
PKGNAME= dovecot-fts-xapian-${V}
-# remove DISTNAME at next update; upstream rerolled the distfile
-DISTNAME= fts-xapian-${V}-1
REVISION= 0
CATEGORIES=mail
@@ -22,8 +20,8 @@ MAINTAINER= Tom Wong-Cornall
Re: to Pandoc or not
On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze wrote: > I never found pandoc useful for anything - so much so that i never > even felt a need to evalute its quality for real. I dimly remember > that on rare occasions, i saw man(7) output generated by pandoc, > and if i remeber correctly, that was of poor quality - but i'm not > sure and it isn't terribly relevant because pandoc is used very > rarely in practice in the first place. > > What do you want to do with it? As a mutt user, I find pandoc useful to generate HTML mail from a normal plaintext email starting point. Markdown (a valid "from" format for pandoc) is after all essentially just plaintext email "markup", so it's fairly transparent. Obviously this might be a rather inflammatory statement in itself, as HTML email is its own special hell for many people, but it's hard to get away from having to send the occasional piece when interacting with the wider world that don't spend their lives like me in an rxvt window. There's some nice examples (not mine) here: https://nosubstance.me/post/mutt-secret-sauce/
synapse filepaths + rc script query
Hi Renaud,
Many thanks for your work on synapse. I'm upgrading one of my machines
to 6.7 and am pleased I no longer have to maintain my own
virtualenv-based synapse.
As I am preparing a port for mautrix-hangouts, I would like to check a
couple of decisions in the synapse port that differed from what I had
chosen in my local version. They are really very minor nitpicks, but I'd
like to ask your reasoning so I may be consistent:
- config files stored in /var/synapse; I had these all in /etc/synapse
- pid file stored in /var/synapse/homeserver.pid; I had this in
/var/run/synapse/homeserver.pid
Lastly, instead of relying on a custom python init system (synctl), I
found the builtin rc.subr setup worked well:
> #!/bin/ksh
>
> daemon="/usr/local/bin/python3"
> daemon_flags="-m synapse.app.homeserver -c /etc/synapse/homeserver.yaml
> --daemonize"
> daemon_user="_synapse"
>
> . /etc/rc.d/rc.subr
>
> rc_pre() {
> install -d -o _synapse -g _synapse /var/run/synapse/
> }
>
> rc_cmd $1
Cheers,
Tom
Re: synapse filepaths + rc script query
On Tue, Aug 11 '20 at 19.06 NZST, Renaud Allard
wrote:
> Indeed, config files could be stored in the more standard /etc, but that
> will be a breaking change if I do that now.
Fair enough. Could it be symlinked during a transition period? I'm sure
it's my own hangups but editing config files in /var feels weird :)
> I agree, byt synctl is the documented way to start synapse, that's why I
> choose it.
Also fair enough, I found synctl had issues tracking synapse' state in
earlier versions so I didn't trust it. Could have been user error, it
seems to work fine in your port.
BTW: on the most recent version, all of the scripts get dumped into
/usr/local/share/synapse -- apart from export_signing_key and
generate_log_config. These are just left in /usr/local/bin, which is
probably not intended.
The below diff makes sure all scripts (no matter what new ones they add)
get placed in /usr/local/share/synapse, and gets rid of the for loop:
--
Index: Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
retrieving revision 1.11
diff -u -p -u -r1.11 Makefile
--- Makefile31 Jul 2020 00:21:16 - 1.11
+++ Makefile14 Aug 2020 11:03:55 -
@@ -21,6 +21,8 @@ MODULES = lang/python
MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
MODPY_SETUPTOOLS = Yes
+MODPY_DISTUTILS_INSTALLARGS = --install-scripts ${LOCALBASE}/share/synapse
+
RUN_DEPENDS = textproc/py-lxml${MODPY_FLAVOR} \
textproc/py-yaml${MODPY_FLAVOR} \
textproc/py-unpaddedbase64${MODPY_FLAVOR} \
@@ -62,14 +64,5 @@ TEST_DEPENDS = ${RUN_DEPENDS}
do-test:
cd ${WRKSRC} && ${SETENV} PYTHONPATH=. ${LOCALBASE}/bin/trial-3 tests
-
-post-install:
- @mkdir ${PREFIX}/share/synapse
-.for script in generate_config generate_signing_key.py \
- move_remote_media_to_new_store.py \
- sync_room_to_group.pl hash_password \
- register_new_matrix_user synapse_port_db synctl
- @mv ${PREFIX}/bin/${script} ${PREFIX}/share/synapse
-.endfor
.include
Re: [update] net/synapse -> 1.19.0 textproc/py-canonicaljson -> 1.3.0
On Tue, Aug 18 '20 at 01.48 NZST, Renaud Allard wrote: > Here is an update for net/synapse to 1.19.0. This version needs > textproc/py-canonicaljson > 1.2.0. Therefore, there is a patch for > py-canonicaljson as well. Thanks, your update is running nicely here on amd64 with postgres.
[UPDATE] dovecot-fts-xapian to 1.3.3
Hello,
Diff below updates dovecot-fts-xapian from 1.3.1 to 1.3.3. Upstream has
fixed a couple of bugs, and optimised expunges (have seen a good
performance improvement over the past month).
Note since last update portcheck now shows "the following libraries in
WANTLIB look like masked by RUN_DEPENDS: sqlite3". It's a nice error
message but I'm too thick to understand it. No combination of shuffling
things around between WANTLIB and BUILD_DEPENDS/RUN_DEPENDS made it go
away (without breaking other things). Searching the archives didn't shed
much light for this dim bulb either.
---
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile27 May 2020 11:27:49 - 1.4
+++ Makefile24 Sep 2020 04:02:42 -
@@ -4,7 +4,7 @@ COMMENT=full text search plugin for Do
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
-GH_TAGNAME=1.3.1
+GH_TAGNAME=1.3.3
PKGNAME= dovecot-${DISTNAME}
CATEGORIES=mail
Index: distinfo
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo27 May 2020 11:27:49 - 1.4
+++ distinfo24 Sep 2020 04:02:42 -
@@ -1,2 +1,2 @@
-SHA256 (fts-xapian-1.3.1.tar.gz) = FiAse8KK2P8v956858Lwv4eJTyppRBkge7SxhoMUiws=
-SIZE (fts-xapian-1.3.1.tar.gz) = 28026
+SHA256 (fts-xapian-1.3.3.tar.gz) = 3xGYEAaewOOPQDnX67kLIbJVj0Ia19tdS0wHg6kieYA=
+SIZE (fts-xapian-1.3.3.tar.gz) = 28237
[UPDATE] dovecot-fts-xapian to 1.4.8
Hello,
Diff below updates dovecot-fts-xapian from 1.3.3 to 1.4.8. Upstream has
fixed several searching bugs (emails were missed from search), and
dropped the sqlite expunge database, so some deps are no longer
required.
---
Index: Makefile
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile11 Jan 2021 22:17:55 - 1.8
+++ Makefile25 Mar 2021 22:24:20 -
@@ -4,8 +4,7 @@ COMMENT=full text search plugin for Do
GH_ACCOUNT=grosjo
GH_PROJECT=fts-xapian
-GH_TAGNAME=1.3.3
-REVISION= 2
+GH_TAGNAME=1.4.8
PKGNAME= dovecot-${DISTNAME}
CATEGORIES=mail
@@ -15,16 +14,14 @@ MAINTAINER= Tom Wong-Cornall =1.4.0 \
+LIB_DEPENDS= databases/xapian-core>=1.4.0 \
textproc/icu4c>=63.0
SEPARATE_BUILD=Yes
Index: distinfo
===
RCS file: /cvs/ports/mail/dovecot-fts-xapian/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo19 Oct 2020 15:23:30 - 1.5
+++ distinfo25 Mar 2021 22:24:20 -
@@ -1,2 +1,2 @@
-SHA256 (fts-xapian-1.3.3.tar.gz) = 3xGYEAaewOOPQDnX67kLIbJVj0Ia19tdS0wHg6kieYA=
-SIZE (fts-xapian-1.3.3.tar.gz) = 28237
+SHA256 (fts-xapian-1.4.8.tar.gz) = VHzIdCXFnV+7O3+BEg8L0B3Wx4rSNNPXUMAvQhgE43Q=
+SIZE (fts-xapian-1.4.8.tar.gz) = 29381
Re: Dependency problem with stable update of dovecot-2.3.13
On Sun, Jan 10 '21 at 00.24 NZDT, Stuart Henderson wrote: > This should have been rebuilt as well, this was working in 6.7-stable.. > could you take a look please Solene? > > > On 2021/01/09 11:17, Renaud Allard wrote: > > Hello, > > > > There seems to be a dependency problem if you use dovecot-fts-xapian > > > > Dependency of dovecot-fts-xapian-1.3.1 on dovecot-=2.3.11.3v0 doesn't match. > > > > And a pkg_add -u will try to upgrade dovecot-pigeonhole > > Which will create an ABI issue given that main dovecot is not upgraded: > > Error: Couldn't load plugin > > /usr/local/lib/dovecot/doveadm/lib10_doveadm_sieve_plugin.so: Module is for > > different ABI version 2.3.ABIv13(2.3.13) (we have 2.3.ABIv11(2.3.11.3)) It looks like this is still out-of-date, judging from some user feedback. Anything different I can do in the port, or is this all down to voodoo on the build server(s)?
Re: [UPDATE] dovecot-fts-xapian to 1.3.3
Hello,
Post-6.8 ping :)
---
On Thu, Sep 24 '20 at 16.12 NZST, Tom Wong-Cornall wrote:
> Hello,
>
> Diff below updates dovecot-fts-xapian from 1.3.1 to 1.3.3. Upstream has
> fixed a couple of bugs, and optimised expunges (have seen a good
> performance improvement over the past month).
>
> Note since last update portcheck now shows "the following libraries in
> WANTLIB look like masked by RUN_DEPENDS: sqlite3". It's a nice error
> message but I'm too thick to understand it. No combination of shuffling
> things around between WANTLIB and BUILD_DEPENDS/RUN_DEPENDS made it go
> away (without breaking other things). Searching the archives didn't shed
> much light for this dim bulb either.
>
> ---
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/dovecot-fts-xapian/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- Makefile 27 May 2020 11:27:49 - 1.4
> +++ Makefile 24 Sep 2020 04:02:42 -
> @@ -4,7 +4,7 @@ COMMENT= full text search plugin for Do
>
> GH_ACCOUNT= grosjo
> GH_PROJECT= fts-xapian
> -GH_TAGNAME= 1.3.1
> +GH_TAGNAME= 1.3.3
> PKGNAME= dovecot-${DISTNAME}
>
> CATEGORIES= mail
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/dovecot-fts-xapian/distinfo,v
> retrieving revision 1.4
> diff -u -p -r1.4 distinfo
> --- distinfo 27 May 2020 11:27:49 - 1.4
> +++ distinfo 24 Sep 2020 04:02:42 -
> @@ -1,2 +1,2 @@
> -SHA256 (fts-xapian-1.3.1.tar.gz) =
> FiAse8KK2P8v956858Lwv4eJTyppRBkge7SxhoMUiws=
> -SIZE (fts-xapian-1.3.1.tar.gz) = 28026
> +SHA256 (fts-xapian-1.3.3.tar.gz) =
> 3xGYEAaewOOPQDnX67kLIbJVj0Ia19tdS0wHg6kieYA=
> +SIZE (fts-xapian-1.3.3.tar.gz) = 28237
>
Re: Update mail/dovecot-fts-xapian to 1.5.5 to fix segfault in 7.1
On Wed, Apr 27 '22 at 08.16 NZST, Stuart Henderson wrote: > Any comments Tom? > > Since it is currently broken it's probably best if we commit it asap > and also commit something (whether that's 1.5.5 or 1.4.14) to 7.1-stable. > > > On 2022/04/24 15:08, Brad Smith wrote: > > On 4/24/2022 7:39 AM, William Orr wrote: > > > Hey, > > > > > > The plugin API of dovecot apparently changed in 2.3.17. Because of this, > > > the version of dovecot-fts-xapian in 7.1 is broken and will crash > > > whenever invoked. > > > > > > Diff to update the plugin to the latest version follows. I'm running > > > this on my backup MX that I upgraded to 7.1 to test, and I no longer get > > > crashes when receiving mail or replicating mail to it. > > > > > > (please CC me, I'm not subscribed to ports@) > > > > > > Thanks > > > > > > It looks like the issue would have been resolved by updating to 1.4.14 as > > well. > > > > It is too bad this was not noticed before the release. Thank you for working > > on this. > > > > Do you intend to push those patches upstream or should I? Hi folks, Sorry for late reply and missing this. I have since moved on to fts-flatcurve for a little while now on my -current server and didn't pick this up. Probably best if I'm removed as maintainer as I don't intend to run fts-xapian in future. I can't test the included C++ patches at present but they don't look particularly frightening in terms of content. Shouldn't be hitting those memory limits anyway if it's appropriately configured - it doesn't need much RAM. Cheers, Tom
