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
