Never mind... attempting to use this in 2022 leads to all sorts of safety violations. Not worth updating without major surgery on the codebase itself.

Very happy to see this port getting updated for Qt5! And yes, entirely happy to relinquish maintainership... I only know enough about the ports tree to be dangerous. :)

In D8397#337061, @greg_unrelenting.technology wrote:

Is this one not supported by wmt(4)? The elan touchscreen on my Thinkpad X240 (0x04f3 : 0x0140) works great with wmt(4), but webcamd used to lose touch-end events...

Just for good measure, I also updated the upstream code to incorporate the __FreeBSD_version_ patch; I'm now looking to update the port to v0.1.7.

• Update to v0.1.7 (w/upstream patch adoption).

Thanks for the feedback: I've added the missing file and done a little extra tidy-up that portlint -A suggested while I'm at it.

• Add new library to plist
• Fix library version.
• Fix a portlint warning.
• Update patch file (new line numbers, etc.).

Closing revision: this functionality was implemented in D17547.

Just to be clear: this change only affects the use of O_BENEATH when not in capability mode, right? We wouldn't want to allow absolute path information (e.g., "is FD X somewhere under the path /foo/bar/baz/wibble?") to leak when a process is in capability mode...

I've made a few minor suggestions about man page wording (which might reasonably apply to all of the man pages in the review). I've also made a minor suggestion about deriving LCF_STRICTRELATIVE from BENEATH rather than including lots of if (... STRICTRELATIVE || ... BENEATH).

Thanks very much!

So... should this revision be abandoned in favour of an approach that uses the new enable_sandbox_{basic,full}() functions?

Ping?

Figuring out the 10.x compatibility isn't worth it for me any more, as the project I was thinking of using Cap'n Proto for has moved on.

So, @cperciva , do you mind if I pull your firstboot-pkgs work into the base system? This would help tidy up a VM-building workflow that I'm using in which I can't run pkg(8) on the VM-building host.

I wasn't aware of that port, no... thanks for pointing it out! I'll definitely take a look at that and see if it might make more sense to pull that into base than to duplicate the work.

Thanks!

• Clean up as per review comments.

Ping?

In D12733#264442, @dbaio wrote:

Builded fine in 11-[amd64|i386] and CURRENT-[amd64|i386].
Problem here in 10-[amd64|i386].

Logs are here:
10-amd64
10-i386

In D12733#264231, @tobik wrote:

[...] Have you done a test build in Poudriere?

• Break out version prefix.

In D12733#264231, @tobik wrote:

Where's the pkg-plist?

• Commit missing pkg-plist
• Remove MASTER_SITES.
• Replace USES+= with USES=.

• De-uglify version number using DISTVERSIONPREFIX.

I think this may now be redundant in light of https://reviews.freebsd.org/D12701?

• Add missing LLVM_IR_TYPE

In D12701#263694, @sjg wrote:

Ok so apart from moving the definitions, the key improvement is suppressing .bco etc. for .asm ?

• Prefer += to = when computing {BC,LL}OBJS.

In D12339#255993, @cem wrote:

Er, why is rename / renameat with AT_FDCWD not allowed in capability mode?

Ok, I think that addresses the last of the reviewer comments?

Ok, I think that's everything now?

• Move USES above USE_GITHUB.
• Merge 'origin/master' into llbuild

• New port: devel/llbuild
• Change post-stage to post-install for docs.
• Fix typo: "swift-llbuild", not "switch-llbuild"!
• Add the llbuild binary to the build and plist.
• Fix licensing: use ports' multi-license support.
• Fix license: ports tree calls "LLVM" "NCSA".
• Update to use lit from llvm-devel

In this case, LICENSE_FILE describes the Apache license but it also describes which bits of the sources fall under different licenses. Under those conditions, does it make sense to keep?

No, sometimes the device use 0xff for some ID fields which means propritary driver. It might be better to match that than vendor/product.

• Change an unnecessary '?=' to '='.
• Uncomment PKGNAMEPREFIX as requested by sunpoet.
• Update py-cdg to HEAD

Add reviewers who have touched these makefiles recently

Thanks very much: I've committed the patch as approved/accepted, but would certainly be happy to discuss the relative merits of moving things around (perhaps as a separate action?). I think there will be a tension between the "FreeBSD way" and the "Neo4j way", but... well, perhaps that's a conversation for another day/diff/review. :)

• New port: devel/py-cdg
• Address comments in Phab review

Thanks very much for the feedback: I learned a lot about Python packaging!

• Align neo4j.conf patch with previous patch.
• Put databases in /var/db instead of $PREFIX/share.

• Update to use ${PREFIX}/etc as requested.