• This won't help CIs and out of ports builds
• Opt out mechanisms probably need more work first
• I've lost interest after becoming more aware of downstream consumers of FreeBSD

In D47091#1078103, @sunpoet wrote:

I don't think it is workable given that there is no USES=proccontrol in the ports tree.

In D47086#1076935, @brooks wrote:

This feels like a big hammer.

In D47086#1074807, @bapt wrote:

This approach is very intrusive and I don't think the is the right approach, the right one is do mark the binary which are not protmax or wx=0 friendly.
Log ago I have written this: https://reviews.freebsd.org/D43168 for aslr, I think the same approach should be taken for the other security features and it should not be done as wildly as this propose.

oops, s/disabled/disable in www/node20

PROCCONTROL_CMD -> PROCCONTROL and put in bsd.commands.mk like elfctl

The goal here is to have a builder with vm.imply_prot_max=1 and kern.elf64.allow_wx=0 set and have opt out for ports which need WX pages for configure/build/stage/tests. This chain isn't exhaustive, after this chain is landed I plan to request exp-run to expose ports that can't build in restricted environment.

In D46874#1071415, @bapt wrote:

I don't understand why BRANCH_EXT is empty in your case, are you just invoking make update-packages or do you have more in your command line and env?

Hi. This doesn't seem to work on main. I did make update-packages thrice with already built world and still each time all the packages are "new":

==> Checking for new packages (comparing 15.snap20241003021833 to 15.snap20241003021430)
==> New package FreeBSD-acct-15.snap20241003021833.pkg
[...]

Abandoning as I lack mental energy to respond to possible comments, and I'm probably no longer interested in FreeBSD.
This has nothing to do with this review, this is just accumulated. Feel free to pickup the revision if you are interested.

Enthusiasm to upstream lost.

As LLVM moved to bi-weekly bugfixes (point) releases [1] maybe consider other change in Mk/bsd.gecko.mk, or devel/llvm*, or start cooperating with LLVM maintainer(s) to also bump WASI_LLVM_VERSION on a LLVM point release?
14.0.6 seems to be the last point release in 14 series, so there is enough time to figure out design improvement.

llvm=14 works here without reverts as of ports 8367c2b68a92 + latest revisions in the stack + devel/wasi-libcxx license path fix.

I realized that I want to create a separate revision with my suggestions instead (planned sometime this month).

After pointing to a license file, fails to build in clean 13.1/amd64 jail and clean ports 949904de1fdf + all the last revisions in stack:

/usr/local/bin/clang++14 -std=gnu++17 --target=wasm32-wasi --sysroot=/usr/local/share/wasi-sysroot -o rlbox.wasm -Wl,--export-all -Wl,--stack-first -Wl,-z,stack-size=262144 -Wl,--no-entry -Wl,--growable-table ogg_alloc.wasm ogg_bitwise.wasm ogg_framing.wasm xmlparse.wasm xmlrole.wasm xmltok.wasm wasm2c_sandbox_wrapper.wasm mozHunspellRLBoxSandbox.wasm affentry.wasm affixmgr.wasm csutil.wasm hashmgr.wasm hunspell.wasm phonet.wasm replist.wasm suggestmgr.wasm GraphiteExtra.wasm CmapCache.wasm Code.wasm Collider.wasm Decompressor.wasm Face.wasm FeatureMap.wasm FileFace.wasm Font.wasm GlyphCache.wasm GlyphFace.wasm Intervals.wasm Justifier.wasm NameTable.wasm Pass.wasm Position.wasm Segment.wasm Silf.wasm Slot.wasm Sparse.wasm TtfUtil.wasm UtfCodec.wasm call_machine.wasm gr_char_info.wasm gr_face.wasm gr_features.wasm gr_font.wasm gr_logging.wasm gr_segment.wasm gr_slot.wasm json.wasm RLBoxWOFF2Sandbox.wasm table_tags.wasm variable_length.wasm woff2_common.wasm woff2_dec.wasm woff2_out.wasm -lwasi-emulated-process-clocks
../../dist/host/bin/wasm2c -o rlbox.wasm.c rlbox.wasm
0105557: error: unexpected opcode: 0xfc 0xa
gmake[4]: *** [/wrkdirs/usr/ports/www/firefox/work/firefox-102.0.1/config/rules.mk:501: rlbox.wasm.c] Error 1

`Missing license file for LLVM2 in /wrkdirs/usr/ports/devel/wasi-libcxx/work/llvm-project-14.0.6.src/LICENSE.TXT`

I moved on to D35099.

Thank you for continuing your valuable effort to document Wayland ecosystem on FreeBSD.

Rust bundles vendored LLVM for rarely essential changes,
or features guarded behind LLVM_RUSTLLVM, that may not
be required for a user.
---

does these statements come from the rust project or is it your personal opinion?

In D35289#799860, @cmt wrote:

The whole LLVM_DEFAULT logic in bsd.gecko.mk should just go away, and LTO as well perhaps. Less options, less problems.

Commit message was lost and I have yet to learn to use Phabricator beyond Web frontend:

• Change LIB_DEPENDS to BUILD_DEPENDS (and RUN_DEPENDS if also WASM=on)

External LLVM is static by default in Rust's LLVM wrapper, e.g.:

In D32654#742309, @evgeniy_khramtsov.org wrote:

Is there a committer who is going to own/support this?

I am interested to use this as long as I use FreeBSD, and plan to fix possible
breakage as I can. And I'm not the only one that can do this, FreeBSD is likely a community project.

1. Base isn't ready yet (overriding in make.conf causes i.e. include bootstrap issue(s) https://lists.freebsd.org/archives/freebsd-current/2021-December/001116.html) + might need to do something about DTrace first. Base should be ready first before touching ports, the reason I'm abandoning this for now.

To avoid regressing D32654 maybe also apply files/patch-vendor_cc_src_lib.rs to the versioned vendor/cc-1.0.69/src/lib.rs.

Combined with D32654, it is possible to have only one (devel/llvm13) LLVM copy on a desktop.

Approximate (WIP) reproducer of my environment (/var/tmp nullfs mounted to pkg repo with devel/llvm13):

Is there a committer who is going to own/support this?

Maybe "update diff" instead of attaching? I'm somewhat confused whether what I see in Phabricator is the same as in the newest attached diff.

In D32654#737489, @diizzy wrote:

Last time I asked about this people mentioned this:
https://github.com/rust-lang/rust/issues/49653

• Replace extra-patch with REINPLACE_CMD.

llvm-config in config.toml resulted in rustc_codegen_ssa being passed LinkOutputKind::DynamicPicExe, which results in amended "-pie" for LD, failing to link with R_X86_64_32(S) relocations and the rest of non-PIE libraries:

12.2/amd64 needs -fPIC or -z notext for stage2, update planned.

I almost forgot, this was not added in the newest revision: just starting seatd is not enough, a user is required to be a member of "video" group.

Thanks for improving this diff. I'm not good at reviews, so please wait
for someone else to approve, but I added some nitpicks:

Thanks for documenting Wayland on FreeBSD. I added some notes to places that may need change. Not sure about Plasma or nvidia parts, I neither use Plasma nor own and nvidia GPU.

I confirm, this fixes the issue (rust=rust-nightly).

In D30930#696472, @imp wrote:

In D30930#696470, @evgeniy_khramtsov.org wrote:

There is a lack of transparency here.

You're welcome to attend future meetings. I run them and have for a while now. Would you like me to send you an invite? We took notes in the past, but I've fallen down on that duty for a while. I can start again since there's no reason not to other than laziness on my part...

Per discussion with x11@ libglvnd will be the only GL provider supported by ports.

Context missing; is there a log of the discussion?

There is no direct log, PRs and reviews were used to record decisions or needs for discussion

Seems like this was discussed somewhere else, mind providing links to these discussions?

It was my first meeting.

PRs and reviews were used to record decisions or needs for discussion and this review is one of those results

Per discussion with x11@ libglvnd will be the only GL provider supported by ports.

Update date after the last change to man page.

Reference the handbook section instead, so we always have up-to-date information. '#_external_mirrors' is used instead of '#git' to save reader's scrolling time.

Document GitLab mirror. If the handbook (D29252) or https://wiki.freebsd.org/Git will mention the mirrors, I'll update this revision to reference either of them.

In D29234#654767, @gbe wrote:

In generell no objections from manpages, but the updated text has no references to be IPv6 specific. Is that intentional?

In D26358#586779, @evgeniy_khramtsov.org wrote:

In D26358#586750, @ae wrote:

I think this patch is too complicated. Can you properly test this patch instead? https://people.freebsd.org/~ae/ipfw_frag.diff

I tested (ipfw add / ipfw show) ipfw_frag.diff and your approach works.
It also looks miles better. When you commit ipfw_frag.diff, please close this review. Thanks.

In D26358#586750, @ae wrote:

I think this patch is too complicated. Can you properly test this patch instead? https://people.freebsd.org/~ae/ipfw_frag.diff

An attempt to also handle "!" with frag options and options like !via
(I hope review comment edits do not make new notifications)

Already committed by ae@.

The same issue exists for other NAT64 instances. Update this diff to the version from E-Mail.