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: Binary data
