Here is further progress on this port, following versions by Enric Morales and Stuart Henderson. I hope that this does not duplicate your efforts.
There were three zlib-related bugs in notmuch: 1) second argument (&enum) of gzerror() cannot be NULL, as gzerror() will write to this address. This was causing SIGSEGV. 2) gzerror() cannot be called after gzclose() (use after free). This was causing SIGBUS. Patching these two got rid of all the SIGSEGV and SIGBUS in tests. 3) these two errors were not spotted before because no one was reaching them with a recent zlib (they are bugs both for the latest zlib and OpenBSD's zlib though). It seems that gzerror() in OpenBSD's older zlib will return (or rather set errnum to) Z_STREAM_END when reaching EOF, and this was handled as an error in notmuch's gz_getline(), when in fact it seems to be equivalent to Z_OK plus the indication that we reached EOF. Unfortunately the manual of zlib does not say much about the meaning of Z_* error codes, but that's the most obvious meaning (to me at least). I reported these bugs on the notmuch mailing list, but at least one issue remains. OpenBSD's zlib does not have a relatively recent feature of zlib: the ability to write uncompressed files, or "T" (for "transparent") mode. The result is equivalent to "--gzip" being the default (and the only choice!) for notmuch dump. To run the tests I patched them by adding "| zcat" after each notmuch dump which is not followed by --gzip, and a gunzip [...] line after each notmuch dump --output. I also replaced gpg by gpg2 in the tests, and imposed the python3 FLAVOR because it is necessary for a few tests (I may have done this the wrong way). There are still 9 tests that fail, but I am not sure that all of them are real failures. That's not counting the tests that Stuart Henderson forced to skip (I haven't looked at them yet) and the tests requiring large files (databases to be downloaded from notmuch's website). I see 3 ways to solve this outstanding problem: 1) add the "T" mode to OpenBSD's zlib, for example by merging with a more recent zlib from upstream. Unfortunately this seems to be a lot of work: see https://marc.info/?l=openbsd-tech&m=141936824422127&w=2 One could also just add the "T" mode. 2) just accept that notmuch dump will only output gzipped data, i.e. only patch the man page to indicate that --gzip is the one and only choice. Not very nice... 3) patch notmuch to remove the compression feature (--gzip), essentially replacing zlib by stdio. I like that because the gzip feature is not really useful anyway (a pipe to any compression program is simpler and more flexible), but that will mean merging work for each port update. Perhaps this could be suggested upstream? On Sun, Dec 22, 2019 at 12:35:34AM +0000, Stuart Henderson wrote: > Enric Morales has sent a newer version to ports@, but there are still > some problems - some segfaults and hangs connected with the notmuch > code using zlib (which has been patched to work with OpenBSD's rather > old version of zlib - I don't trust these patches, in particular the > one relating to gzclose_w). There are some other problems which might > also be connected with zlib but might be something else. > > It builds and packages and some things work, but I don't think it's > ready for import until these problems are figured out. (I'm not > expecting a fully clear "make test" run, but the tests which currently > fail point at some problems that really want fixing first). > > Here's a version I've worked on a bit. Compared to the last one that > was sent to ports@, it's a newer version, simplifies some patching, > and gets more of the tests running correctly. >
notmuch.tgz
Description: Binary data
