bogofilter 1.3.0.rc2 now available, release candidate (fixes LMDB 1.0.0 database support)

[Matthias Andree]

Am 10.07.26 um 16:37 schrieb Steffen Nurpmeso:
> Matthias Andree via bogofilter-announce wrote in
>   <alDUSFaaK7v7PK48 at ryzen.an3e.de>:
>   |bogofilter 1.3.0.rc2 is now available from
>   ...
>   |This fixes LMDB 1.0.0 compatibility (1.3.0.rc1 and older won't
>   |read or write anything with LMDB 1.0.0 because they believe the maximum
>   |key size were 0 - arguably an LMDB 1.0.0 documentation bug and breaking
>   |API change, but easily fixed for us),
>   ...
>
> Sorry for this again, i have opened
>
>    https://bugs.openldap.org/show_bug.cgi?id=10534


Thanks for reporting the documentation defect upstream and sharing the link.


>    ...
>   |WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
>   |------------------------------------------------------------------------
>   |POTENTIAL FOR DATA CORRUPTION DURING UPDATES
>    ...
>
> But to note that you possibly want to wait, i saw Howard Chu
> speaking on postfix-devel, even though on something different, he
> release[sd] 1.0.1
>
>    https://marc.info/?t=178363071700003&r=1&w=2


Thanks, but that's fixing a different regression, one which did not 
affect bogofilter:
We're not programmatically dropping databases to repopulate them 
atomically inside the transaction.

Apparently the LMDB database has a limited test set outside OpenLDAP...


For bogofilter: It was important to get the fix out, hence we have 
1.3.0.rc2.


>    ...
>   | 2026-07-02
>   | * Add support for breaking changes in LMDB 1.0.0.  bogofilter's
>   |   LMDB driver in 1.3.0.rc1 and older would reject all database
>   |   transactions because it believed database lookup keys were too
>   |   large.  Cause is an undocumented API change where we can only
>   |   query the maximum key size after OPENING a database environment,
>   |   not, as documented in 1.0.0 and 0.9.X before, after already
>   |   creating it.
>    ...
>
> And i think it was always like that, but falsely documented.
> It just never sprang into existence bevcause of how LMDB was used
> i would think.  Sorry for this again.


To me it seems the bug is new, else we'd have known, and it was clearly 
the keysize query that returned 0.

We've had reports of self-tests breaking with LMDB 1.0.0 on FreeBSD 
ports' package builders and Xin Li who oversees the FreeBSD port of LMDB 
moved all ports back to LMDB 0.9 for now so they can upgrade to LMDB 1.0 
on their own schedule.  FreeBSD has bogofilter (based on LMDB 0.9) and 
bogofilter-lmdb1 (1.0) ports.

The KyotoCabinet database 1.2.80 (1.2.80_1 on FreeBSD) triggers three 
compiler complaints that suggest that the header file is ill-formed and 
can only be compiled with language standards before and excluding C23.  
  It's rather simple to fix though, int foo() needs to be int foo(void) 
in C23 if you mean "no arguments" rather than "give me as many as you 
like". TokyoCabinet headers compile inconspicuously...


> Great we get a bogofilter update!!

:-)