Also bump PORTREVISION

The build now looks good to me. I asked a few minor questions below.

The message in periodic.conf is clear.

	# Compatibility with old daily variable names.
	# They can be removed in stable/11.
	security_daily_compat_var() {
		local var=$1 dailyvar value

Committed in b30a7e5418be5c5d27ac967f5ce99461ab79c37c and referenced the original review at https://reviews.freebsd.org/D43940.

Remove check for wayland flavor; it's no longer necessary with PGTK as a slave option.

Remove leftover comment

• Incorporate jbeich's suggestion to use OPTIONS_SLAVE

Chris, rather than overwrite your review, I rebased your work on top of the latest of the main branch and created new review in https://reviews.freebsd.org/D44977. The commit message is based on your summary in D43940. If everything looks good to you there, I'll commit.

Chris, rather than overwrite your review, I rebased your work on top of the latest of the main branch. The commit message is based on your summary in D43940. If everything looks good to you, I'll commit.

Adding some IRC discussion here.

Restore changes after last arc diff --update

Add a few more tweaks mostly related to the change in D44929, which this revision depends on.

There is still a problem to be resolved. Even though we have OPTION_EXCLUDE=CAIRO... for the Wayland flavor, CAIRO_CONFIGURE_WITH=cairo is still adding --without-cairo to CONFIGURE_ARGS.

Ensure the correct LIB_DEPENDS and USES are specified

Don't change OPTIONS_DEFAULT here. Do it in a subsequent commit.

Oh, yes. When people do, e.g., pkg info serf, they should see the new maintainer.

Looks good to me.

LGTM. I flagged a few other optional nits.

Thanks. Looks good. Could you also run it through something like portlint -AC and portclippy/portfmt?

To elaborate, I felt that specifically checking for the issue at hand is unlikely to introduce any new problems, but adding set -e, which, of course, affects the whole script is more likely. That said, since @michael is prepared to take on any new problems, I'm fine either way.

In D42719#1021238, @mandree wrote:

In D42719#1020644, @jrm wrote:

@michaelo, thanks for sticking with this review. My preference is still to go with the || exit \$? with or without the set -e.

@jrm I have not understood the motivation to avoid set -e. My standard is to "set -eu" to trap maintainer oversights, which happen quickly. And possibly even "set -o pipefail" if I know the shell supports it (if bash has been ensured some way).
My clear preference is set -e and stop polluting the code with || exit and what not. You want robust scripts? Then you want error checking EVERYWHERE. I abhor scripts that run past errors and pretend they had completed and possibly even leave exit code 0...

@michaelo, thanks for sticking with this review. My preference is still to go with the || exit \$? with or without the set -e.

LGTM However, someone from portmgr should approve. I'll try to get someone to look today.

Also, chase editors/emacs update.

I'll commit now and incorporate @pauamma_gundo.com's suggestion.

In D44291#1012493, @jfree wrote:

Hey @jrm, efnet seems to be down so I can't ask you this over IRC. I keep getting freefall build failures for i386-quarterly. Would it be ok to push my changes to the relevant quarterly branches?

I committed these in two separate commits.

Hi Chris,

@cperciva, it would be good to get your approval here as well.

portfmt has two suggestions:

Looks good to me unless @vvd has something actionable regarding runtime issues.

It looks good on 14.0 amd64. http://pkg.ftfl.ca/data/14amd64-default/2024-03-05_19h14m11s/logs/eclipse-4.24_2.log

FYI, devel/eclipse failed in my 15.0-CURRENT 1500008 amd64 jail.