Missed cruft (based on 2023-12-11 checkout):

• lang/emilua/Makefile (only IGNORE_FreeBSD_12)
• lang/go-devel/Makefile (only ${OSREL:R} < 13)
• lang/mlton/Makefile (keep ${OSREL:R} >= 13 but make unconditional)
• mail/fetchmail/Makefile (only ${OSREL:R} < 13)
• net/widentd/Makefile (only ${OSREL:R} < 13)
• shells/v7sh/files/Makefile (only ${OSREL:R} < 13)
• sysutils/plasma5-powerdevil/files/patch-daemon_backends_upower_freebsdbacklighthelper.cpp
• www/tor-browser/files/patch-third_\_party_libwebrtc_rtc_\_base_ip_\_address.cc

Rebase and add some changes as per @jbeich

Thanks @jbeich . I will look into it and refresh the patch.

Missed cruft (based on 2023-10-14 checkout):

• audio/opus/Makefile (only arm conditional)
• cad/nvc/Makefile (only !exists(/usr/include/unwind.h) conditional)
• comms/ebusd/files/patch-src_lib_ebus_datatype.cpp
• devel/android-tools/files/patch-vendor_adb_compression_\_utils.h
• devel/llvm1[2-3]/Makefile (only unwind.h-related _BUILD_DEPENDS, _USES, inline comments)
• emulators/rpcs3/files/patch-libc++13
• graphics/darktable/Makefile (only ${OPSYS}_${OSREL:R} == FreeBSD_12 conditional)
• graphics/krita/files/patch-cmake_modules_xsimd_xsimdMacros.cmake
• graphics/qt5-wayland/files/patch-src_client_qwaylandshmbackingstore.cpp (only && __FreeBSD_version >= 1300048 part)
• java/openjdk*/Makefile (only ${OSREL:C/\.[0-9]//} == 12 conditional and the related patch)
• mail/thunderbird/files/patch-third_\_party_libwebrtc_rtc_\_base_ip_\_address.cc
• multimedia/dav1d/files/patch-freebsd12
• multimedia/pipewire/files/patch-src_modules_module-netjack2_peer.c
• net-im/libquotient/files/patch-Quotient_qt_\_connection_\_util.h
• net/samba413/Makefile (only ${OSVERSION} < 1300000 conditional)
• sysutils/arcconf/Makefile (only ${OSREL:R} == 12 part)
• www/chromium/files/patch-third_\_party_wayland_include_config.h (only memfd part)
• www/chromium/files/patch-ui_ozone_platform_wayland_host_zwp_\_text_\_input_\_wrapper_\_v1.cc
• Ditto (as www/chromium) in devel/electron*, www/iridium, www/ungoogled-chromium
• www/librewolf/files/patch-third_\_party_libwebrtc_rtc_\_base_ip_\_address.cc
• x11/xdg-desktop-portal-luminous/Makefile (only BROKEN_FreeBSD_12)

BROKEN_FreeBSD12 in www/ladybird can be removed too

https://cgit.FreeBSD.org/ports/commit/?id=0815295e0b7988daf05dc1665b4ff523c7083763 can be reverted too as part of this change

Update some of the files based on the review from @rene

www/firefox/files/patch-third__party_libwebrtc_rtc__base_ip__address.cc

and

www/firefox-esr/files/patch-third__party_libwebrtc_rtc__base_ip__address.cc

are also obsolete after 12-EOL

Changes are fine as such for devel/llvm* although devel/llvm17 is missing the Sparc backend removal. I think it's OK to not bump port revision here as the FreeBSD backends are a non-default configuration.

In D42068#960015, @salvadore wrote:

In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273397 I have requested an exp-run that found errors that seem to apply to FreeBSD 12 only. Do you suggest that I request a new exp-run on FreeBSD 13 and ignore all FreeBSD 12 specific issues? And maybe also wait for FreeBSD 12 official EOL to commit the final patch?

Do you have a plan to merge this into quarterly? If not then I would say forget 12 related patches in your fixes. Additionally I saw your patch and some of the fallouts. I forgot the bug which you assigned to me but so far I found that the fallout reasons are due to an issue with GCC13 which was fixed in the most recent version of GCC13.

I approve as far as the ports that I maintain (GCC ports from 10 to 14) are concerned.

Patch committed. Thanks for your contribution!

Thank you @tagattie !

Thanks for the head up and sorry for getting back this late.

@tagattie any plan to review this?

Committed, thanks for the patience!

Thank you! :)

In D30045#727389, @a.wolk_fudosecurity.com wrote:

@meta Unfortunately I don't have a commit bit. Who can I ask to commit the change?

@meta Unfortunately I don't have a commit bit. Who can I ask to commit the change?

I have already approved this. Feel free to commit with commit message Approved by: meta (maintainer).

Looks OK from ports/ POV and this port doesn't have a maintainer. I remember deciding against using _SC_HOST_NAME_MAX due to being too error-prone in one of my ports.

This port has a maintainer. Assigning as reviewer.

This is the commit message that phrabricator silently removed:

I guess you miss the point.. For nsupdate to be any usable as a intermediator between Samba and bind9 it has to be compiled against (some) Kerberos library.

To avoid collisions with DHCP and other applications,
it might be better to just depend on the binaries created by bind-tools?

after reading D24586 :

update path in diff, add PORTREVISION

Still looks ok to me. I had a couple of comments.

This version cleans up more ports to fix failures reported by exp-run.

Thanks for being so thorough Jung-uk and doing this in a way that will make similar changes much easier in the future.

Closing this due to timeout

In D18477#401611, @pfg wrote:

ping?

FWIW, this is currently my favorite IDE on FreeBSD: netbeans has problems refreshing.
VSCode is not yet ported :(.

FWIW, this is currently my favorite IDE on FreeBSD: netbeans has problems refreshing.
VSCode is not yet ported :(.

Abandoning this change (probably not applicable to enough ports).

Fix issues pointed out by mat@

• Update to 2018.3.2
• Move to devel as we don't really depend on the intellij infrastructure.
• Use native file watching support as in the latest intellij port.

Use WRKSRC instead of WRKDIST.
Still passes portlint and check-plist

In D15350#356103, @bjk wrote:

In D15350#350715, @0mp wrote:

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

As fair as I know we tend to use Dq Li instead of Nm make Cm build-like for inline commands. This is the style we follow in make.conf.5, src.conf.5, mqueufs.5. The Nm-based formatting is used in rc.conf.5 and find.1 on the other hand.

AFAICT, Dq Li is a more popular way to format commands.

The argument which is in favor of Dq Li is that we tend to make commands in Examples sections literal. We very rarely add Nm-like formatting to examples. Hence for the sake of consistency I'm proposing this change from Nm ... to Dq Li. 😄

What do you think about it, @bjk?

I see this is basically overcome by events, but thank you for the explanation/research -- your proposal seems reasonable to me.

In D15350#350715, @0mp wrote:

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

As fair as I know we tend to use Dq Li instead of Nm make Cm build-like for inline commands. This is the style we follow in make.conf.5, src.conf.5, mqueufs.5. The Nm-based formatting is used in rc.conf.5 and find.1 on the other hand.

AFAICT, Dq Li is a more popular way to format commands.

The argument which is in favor of Dq Li is that we tend to make commands in Examples sections literal. We very rarely add Nm-like formatting to examples. Hence for the sake of consistency I'm proposing this change from Nm ... to Dq Li. 😄

What do you think about it, @bjk?

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

Can you remind me why the .Dq Li is supposed to be better for inline commands?