This is now OK sthen@ to import. As there has been a fair bit of
interest in this over time, I think it might be worth considering this
for commit before 6.7 if another committer agrees, but I would not like
to add the dependency to neomutt until after release (because then
notmuch build failures for any arches would knock out building neomutt
on those arches).
On 2020/04/19 23:14, Olivier Taïbi wrote:
> Oops, just realised that the addition of MODPY_VERSION as Stuart
> Henderson suggested means that sphinx-build-3 is installed as a
> dependency, instead of sphinx-build previously. The attached port
> reflects this (sphinx-build -> sphinx-build-3 in two files).
>
> On Thu, Apr 16, 2020 at 08:47:50PM +0200, Olivier Taïbi wrote:
> > On Fri, Apr 10, 2020 at 09:47:35PM +0100, Stuart Henderson wrote:
> > > for a standalone port, use "MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}",
> > > the FLAVOR setup is for python modules (py-* ports).
> >
> > Thanks, I did that.
> >
> > > The update of the main copy in src/lib/libz has been done at least twice
> > > (though I don't think it happened for the other copies in sys/lib/libz and
> > > src/gnu/usr.bin/cvs - amusingly the fourth copy, in perl, is already at
> > > 1.2.11) - but not made it into the tree. The thing I remember putting
> > > some people off was the "new" z_off64_t (10 years old today in the
> > > public api).
> > >
> > > But updating it is the only option that fixes the various pain / patching
> > > / workarounds / using bundled copies in various things in ports that
> > > has been a problem at least going back to 2012.
> >
> > Would incremental changes converging towards API compatibility with
> > newer zlib stand a better chance of being committed?
> >
> > In any case, I patched notmuch-dump.c (mostly) to replace zlib by stdio
> > and added crude error checking. Thanks to the notmuch tests I believe I
> > came across a bug in src/lib/libz/gzio.c, see
> > https://marc.info/?l=openbsd-bugs&m=158697346006702
> > With this patch to base, almost all tests now pass, except:
> > - in T350-crypto, the first decryption test fails with "Failed to
> > decrypt part: Decryption failed: No secret key". Oddly, the next ones
> > succeed, and if I permute them, then only the first one fails. I was
> > not able to reproduce this bug (even running the test on another
> > machine made it disappear, go figure...), and I would guess that it
> > comes from gmime30 (which is responsible for looking for said secret
> > key) rather than notmuch. Probably related to an environment variable
> > or something else particular to the chroot in which I build.
> > - In T455-emacs-charsets, two tests related to the Yen character fail,
> > but I think they shouldn't: the output is the "Yen sign" U+00A5, i.e.
> > 0xC2 0xA5, when the test expected the "Fullwidth Yen sign" U+FFE5,
> > i.e. 0xEF 0xBF 0xA5. What we get seems to be more correct.
> > - in T610-message-property, the "prefix" test fails, but this seems to
> > be because the test is incorrect (it expects a certain order that is
> > not guaranteed by the implementation: there is a key-multiple values
> > map in which the keys are sorted, but not the values). The test
> > itself should be fixed.
> > I also ran the tests in T530-upgrade, which require a file to be
> > downloaded separately (I did not see a way to achieve this automatically
> > using bsd.port.mk, so I just downloaded the file on the side and ran the
> > test manually), and the tests pass (after a small patch in
> > notmuch-new.c). It probably does not matter much anyway because these
> > tests concern upgrading from an old database.
> >
> > So I am now happy with the result of the tests.
> >
> > I did not touch the python bindings part of the port. In fact I did not
> > even look at it, but the test pass so hopefully they're ok. Grepping
> > for dump does not yield any match, so I guess that the removal of the
> > --gzip option makes no difference for them.
> >
> > Note that there are also ruby bindings, which are currently not built by
> > the port, and that are presumably required for the vim plugin. I do not
> > intend to look at them in the near future.
> >
> > I hope that this port can now be commited. I have been using notmuch on
> > OpenBSD for more than a year without issues now, but I have not tagged
> > anything (too lazy) and only used searching, and so I have never had any
> > use for the dump/restore feature. I hope that Enric, Andrea and others
> > can test tagging more extensively now.
> >
> > Next, there is a trivial patch for neomutt (notmuch is a configure
> > option), which I also have been happily using. Would that be better as
> > a flavor or is notmuch small enough to be a dependency of neomutt?
> >
> > PS: The three zlib-related bugs in notmuch mentioned in a previous email
> > are now fixed upstream, so they should vanish in the next version.
>
>
