Bump port revision

@ale, you want to take a look at?

Stupid question: Should I bump the port revision here?

Lev approached me via e-mail whether I'd like to take ownership of it. I have agreed. He shall approve this review.

Improved version which also supports OpenSSL 1.1.1 by reverting a few changes
from Tomcat Native. Ran full Tomcat test suites, all tests pass.

In D44824#1021968, @jrm wrote:

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

One important thing to note: I could bring back OpenSSL 1.1.1 support with a simple patch because

• https://bz.apache.org/bugzilla/show_bug.cgi?id=66667 has not been solved
• It is almost only:

In D44822#1021925, @otis wrote:

I'd also suggest to bump PORTREVISION to also reflect the future binary packages (this might not be necessary if you plan to do a quick update).

Bump port revision

Ale's response: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276736#c12

So which route should I go @mandree? set or exit?

In D42719#1021272, @jrm wrote:

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.

Use exit explicitly

Tried || exit $? locally, same result:

If the || exit $? version is preferred I will try it, no issue.

Rebased and tested again with poudriere-built packages:

In D44694#1019044, @jrm wrote:

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

Remove trailing period

Any other opinions?

In D44356#1011926, @jrm wrote:

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

@vvd, do you want to update this review?

Removed inline patch in favor of remote one.

fetch patch from remote

In D44338#1011233, @ale wrote:

I think you should change the WWW entry to point to 1.3

apply comments from ale@

This is now a minimal change, please have a look guys.

In D44229#1009025, @jrm wrote:

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

http://pkg.ftfl.ca/data/15amd64-default/2024-03-05_13h23m40s/logs/errors/eclipse-4.24_2.log

It doesn't seem like this change should have any effect, but can you verify this?

Include java/eclipse

In D44229#1008960, @vvd wrote:

I think you can add java/eclipse here too.
Probably https://reviews.freebsd.org/D44153 isn't actual anymore.

FTR: https://reviews.freebsd.org/D44229

Address improvement proposal from @emaste.

I will take care of these:

In D43700#1006987, @emaste wrote:

What do you think about something like Run 'freebsd-update [options] install' to proceed? It offers a reminder to include the user's necessary options but retains the example style.

In D43700#1006063, @otis wrote:

Although this change looks good to me, we also should consider making -d default to $(-b)/var/db/freebsd-update. *THAT* left me with broken boot environment :-/ (I've used -b /path/to/be without -d /path/to/be/var/db/freebsd-update).

@lev, one day left, do you want to take a peek?

Address comment.

Address typo

I will give @lev two weeks to review as demanded by the maintainer timeout. So I can merge around 2024-02-27.

In D43703#1000910, @jrm wrote:

I don't have strong options either way. On the one hand, I can appreciate how this would confuse some users when they log in to a jail. On the other hand, I expect some users would miss seeing this information (by default) when they log in. While it may also be confusing, it's reporting accurate information that many would expect, i.e., version information about the running kernel.

Brainstorming ideas, what about appending something like this to /var/run/motd?

echo "$(hostname) $(uname -smi) running kernel/userland: $(uname -r)/$(freebsd-version -u)"

In a 14 jail running on a 15-CURRENT host, the output looks like this.

myhostname FreeBSD amd64 GENERIC-NODEBUG running kernel/userland: 15.0-CURRENT/14.0-RC4

Ran three sets in poudiere:

In D42720#996866, @glewis wrote:

This version looks good to me. Thanks!

This one comes from: https://github.com/BastilleBSD/bastille/issues/393

@emaste, as discussed, here it is.