Anyone want to import this now (or give me an ok to do so)? Reattached. (Worked on by various people including me, Olivier Taïbi, and Enric Morales)
On 2020/04/19 22:32, Stuart Henderson wrote:
> 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.
> >
> >
>
>
notmuch.tgz
Description: application/tar-gz
