From: Matt Klein Subject: Re: [NEW] mkz - archivers/mkz 0.1.0- a reversible columnar pre-pass + zstd archiver To: Matt Klein , ports@openbsd.org Date: Thu, 9 Jul 2026 12:41:35 -0500 Hello Stuart, Thanks for the feedback! And for the package help. Thought would be clean if I addressed and bumped to 0.1.2 so the source and the port line up, too. - Also cleared up some license noise and trimmed to "# MIT OR Apache-2.0.. " and dropped the WANTLIB on a handful of files. - Am using the standard infrastructure now (MAKE_FLAGS / FAKE_FLAGS / TEST_TARGET = check). - PLIST regenerated with make update-plist (@bin bin/mkz + man/man1/mkz.1). - WRKDIST gone and the 0.1.2 distfile roots at ${DISTNAME}/ (standard layout) - Added ${CPPFLAGS} on the container test so is found and is upstream in the Makefile now. - Cool -- .012 Distfile: mkz-0.1.2.tar.gz at the SITES URL, distinfo regenerated. Did a build and port-lib-depends-check clean on 7.9/arm64 before I pushed the tgz, after clearing out as many em dashes as I could -- Updated tgz's attached. :) Please let me know if I this looks more in line or anything else I should catch? Thank you! Matt On Wed, Jul 8, 2026 at 6:02 AM Stuart Henderson wrote: > > On 2026/07/06 12:39, Matt Klein wrote: > > Hello, > > Please find Attached, a new port archivers/mkz that I published at: > > https://github.com/gitspoked/mz called `mkz` and also in rust/crates.rio. > > I am looking to push to ports. > > > > TLDR: `mkz` is a tar-style archiver whose backend is a reversible, schema-free > > auto-columnar transform (autocol) followed by zstd. It is not a new > > compressor: the transform reshapes line-oriented data (logs, CSV, JSONL) > > so zstd sees per-column-homogeneous streams. Its product is measurably > > smaller on that kind of data, and behind a per-block never-worse gate. > > Provably never larger than zstd alone. Archives carry an end-to-end SHA-256, > > verified on extract. > > > > This is a pure-C upstream build: six C files, depends on libzstd only; > > we have vendored SHA-256 and base-95. It is byte-compatible in both > > directions with the Rust reference implementation, and the wire format > > is specified: https://github.com/gitspoked/mkz/blob/main/FORMAT.md > > > > Tested on 7.9/arm64: distinfo reproduces from the hosted release > > tarball via the the framework fetch; make / make fake / make package / > > make test upstream's three test programs -- > > port-lib-depends-check all clean; portcheck clean. > > - attached: mkz-obsd-port.tgz. digest 9a7fe784… > > - exact tarball was revalidated > > > > The C port was made from the Rust implementation with an OpenBSD first-target > > I know how vigorously accountable you hold security standards to > > within this circle. > > I figured, before I submitted to any other ports trees, why not see if > > we can break it > > apart here first, to be sure. > > > > I am upstream and listed on MAINTAINER; I am happy to take feedback and > > keep the port current. Please let me know if you have any questions. Thx > > > > Thank you, > > Matt Klein > > mk@ntele.net > > mklein@nmedia.net > > : # mkz is dual-licensed MIT OR Apache-2.0. > : PERMIT_PACKAGE = Yes > > ports Makefiles aren't meant to be chatty; just use > > # MIT OR Apache-2.0 > PERMIT_PACKAGE = Yes > > : # Links libc and libzstd only (SHA-256 and base-95 are vendored). > > I'd drop that too > > : WANTLIB = c zstd > : > : SITES = https://github.com/gitspoked/mkz/releases/download/v${V}/ > : > : # The release tarball extracts to mkz-c/ (the pure-C tree), not ${DISTNAME}/. > : WRKSRC = ${WRKDIR}/mkz-c > > should be WRKDIST not WRKSRC > > also needs FIX_EXTRACT_PERMISSIONS = Yes due to restrictive file modes > in the tar > > : LIB_DEPENDS = archivers/zstd > : > : # Plain handful of C files - no configure, and no GNU make needed > : # for the port build. > > it's simpler for upgrades if you use the standard project's build/test/ > install infrastructure, which isn't hard to do, and needs no additional > deps. > > PLIST should be generated with "make plist" (which adds annotations to > binaries, amongst other things). > > not a big fan of the asciified em-dashes in DESCR. > > suggested alternative tgz attached.