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.

In D25789#574377, @ae wrote:

I sent a more generic patch in the reply to your email a week ago, can you check your spam folder and test it?

sure

I deployed this on "real" 12.1 host (KVM VDS vtnet NIC and jails with epairs) today:

recover lost check

Improve test and do the same with kernel module as pf tests do.

It works.
Workaround test panic by being slower in the test.
Still runs under 2s on my laptop.

In D25789#572104, @ae wrote:

I think it should be possible solve the problem without introducing extra configuration parameter. I'll take a look.

This test causes panic on current in somewhere in if_epair.
For some reason something odd was written to my Wi-Fi NICs ROM,
and now it does not work and MAC address is odd.

it's necessary to note this more prominently.

Added context, changed man page, switched to flags, removed comment and added a check for CSUM_DELAY_DATA.

I am new to Phabricator so please tell me if I specified anything wrong.
I did not want a WIP version review, but Phabricator for some reason asked for it.
I do not know why it specifies specific people, but I will leave it as is for now.

Be consistent with other messages.
Sorry for notification spam.

fix spacing