Created attachment 166999 [details] diff for update to 3.4.0 Update to version 3.4.0. Release notes: Primary features: JSON is now a supported format for input and output. Miller handles tabular data, and JSON supports arbitrarily deeply nested data structures, so if you want general JSON processing you should use jq. But if you have tabular data represented in JSON then Miller can now handle that for you. Please see the reference page and the FAQ. Reshape is a standard data-processing idiom, now available in Miller: http://johnkerl.org/miller/doc/reference.html#reshape Full release notes available here: https://github.com/johnkerl/miller/releases/tag/v3.4.0
Maintainer informed via mail
Was this patch completed properly? Is there anything more I need to do to get this updated?
Created attachment 167232 [details] Better diff
(In reply to sf(jungleboogie) from comment #2) > Was this patch completed properly? Is there anything more I need to do to > get this updated? Setting the "maintainer-approval+" flag on a patch helps, as it then shows up in the "Ports: Maintainer Approved" saved search that some committers (myself include) look at.
Confirmation that the change passes QA (portlint, poudriere) is also highly recommended. Having your Bugzilla account email match your port MAINTAINER lines is also quite handy for auto assignment (and auto-approval, when the new bugzilla automation feature lands) Can you try updating your bugzilla account email to include the '+mlr' and confirm that works for you. If not, we'll report a bug upstream and get it fixed.
FYI, your patch contains DOS line endings for some reason.
And the update failed to build on 9.3-i386 with Poudriere: /usr/bin/patch -d /wrkdirs/usr/ports/textproc/miller/work/miller-3.4.0 --forward --quiet -E -p0 --batch -V simple --suffix .orig < /usr/ports/textproc/miller/files/extra-patch-c_Makefile 1 out of 2 hunks failed--saving rejects to c/Makefile.rej *** [post-configure] Error code 1 Applying patches in post-configure like that is weird on its own; I don't see why you don't patch the original build-system files instead of the generated files.
The port maintainer and I have exchanged a few emails. I first had to investigate why those patches were needed at all, as there's no context in them, nor are there any comments about them in the Makefile. From what I can see, it works around some linking issue with clang (or HEAD) and the mlrp executable. It's not clear to me what part is at fault exactly, so I started a thread in the freebsd-toolchain mailing list: https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-February/001994.html
(In reply to Raphael Kubo da Costa from comment #8) > The port maintainer and I have exchanged a few emails. > > I first had to investigate why those patches were needed at all, as there's > no context in them, nor are there any comments about them in the Makefile. > From what I can see, it works around some linking issue with clang (or HEAD) > and the mlrp executable. It's not clear to me what part is at fault exactly, > so I started a thread in the freebsd-toolchain mailing list: > > https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-February/001994. > html Unfortunately this doesn't seem to be going anywhere. sf(jungleboogie): how about patching c/Makefile.am and removing the mlrp target? It's not installed anyway.