In D43242#1013035, @markj wrote:

Seems like this should land? We're just missing a commit log message based on the commentary in this review.

In D44162#1007618, @dim wrote:

In D44162#1007615, @jlduran_gmail.com wrote:

It is worth noting that building with clang 18 currently fails (https://api.cirrus-ci.com/v1/task/5600331233492992/logs/build_world.log), I imagine this will be ironed out as we go along.

Yeah this is https://github.com/llvm/llvm-project/pull/75748, which I pulled into the llvm-18-update branch. But I don't know if it is in the llvm18 port.

It is worth noting that building with clang 18 currently fails (https://api.cirrus-ci.com/v1/task/5600331233492992/logs/build_world.log), I imagine this will be ironed out as we go along.

In D44162#1007556, @emaste wrote:

Use 16 and 17 for now, 18 gave me pkg: No packages available to install matching 'llvm18-lite' have been found in the repositories. Will replace 16 with 18 later.

This looks good. It makes an extra effort to find sed.
I just wonder if it is possible to define SED=${SED:-$(Exists -x /usr/bin/sed /rescue/sed)} only once in rc.subr, maybe at the beginning?
ShellCheck usually recommends avoiding backticks (https://www.shellcheck.net/wiki/SC2006).

Updated in 11da791920ba285f0832f09cb504ac81e35ff8d1.

Nice!
I have slightly tested it, and it is backwards compatible... even with the old (unrelated) bug 268397 (this is probably a race somewhere else), that reproduces easily by stopping/starting the jail service 10 times (repo/branch here: https://github.com/jlduran/jng-jib-jails-test/tree/jng2)

Minor typo.

In D43242#987249, @imp wrote:

Please don't do both pull requests and phab reviews for the same thing.

I was not able to run the _.disk.iso image (maybe it gets truncated?), nowadays, a memstick makes more sense anyway.

This one landed as e9da71cd35d46ca13da4396d99e0af1703290e68 ?

Hi! It appears that bug #275743 is reporting something similar for 12.4.

This is simple, yet useful enough... being more specific may confuse users (just like me). I for one, do a pkg upgrade -y, however, pkg will recommend you a pkg bootstrap -f, but I never know if pkg-static is actually preferred.

Note to self:
It will likely land as two separate commits:

1. Vendor import of vendor/NetBSD/mtree.
2. Vendor import of vendor/NetBSD/tests.

b1c95af45488bef649e9a84890e2414ff80b3a00 landed, somehow I preferred this one from the IERS.

Or if someone from ports can MFC pkg into quarterly, even better. But this is good for now. Thank you!

In D42903#978678, @brooks wrote:

I've chosen to retain the git config change and not do chown of the source tree (only one of them is required). IMO it's useful to test with a read-only tree to since any such write is a bug in the normal build process.

Yes!

Sorry, I got the revision numbers initially wrong. This is my take on D42903.

https://cirrus-ci.com/task/5157804504252416?logs=setup#L15 states that pkg version is 1.20.8, so @override_prefix is not yet available (starting on 1.20.9):

In D36309#977969, @eugen_grosbein.net wrote:

In D36309#935684, @jlduran_gmail.com wrote:

Is there a reason why this change was not MFCd? Thank you!

Forgot about it. I've just merged it downto stable/12.

quite a few other platforms don't have them.

I had missed this important bit. Thank you!

In D42868#977777, @imp wrote:

I plan to push this EOD if I don't hear anything (since it is a build and CI breakage).
However, if there's something better in the wings, I'll back off.. and if something better comes along after my deadline, I'm totally cool deferring to that as well. (unless it is ifdef apple :).

In D42847#977756, @markj wrote:

In D42847#977753, @jlduran_gmail.com wrote:

In D42847#977752, @markj wrote:

In D42847#977744, @jlduran_gmail.com wrote:

Thank you for this nice addition! It does, however, fail when cross-building on macOS:

Hum. Thanks for the report. So we're missing definitions of ALTMON_*. I don't see a preprocessor constant that we can use to gate that

I was thinking about adding an extra header file to tools/build/cross-build/include/mac (with these definitions) and using it to cross-build... but yes, let's gather other opinions.

I think that doesn't make sense unless the corresponding locale files (e.g., /usr/share/local/el_GR.UTF-8/LC_TIME) are also installed on the host?

Hum... Maybe I'm missing something:

➜  uname -a                                      
Darwin macbook-pro.home.arpa 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103 arm64
➜  cat /usr/share/locale/el_GR.UTF-8/LC_TIME
Ιαν
Φεβ
Μαρ
Απρ
Μαϊ
Ιον
Ιολ
Αυγ
Σεπ
Οκτ
Νοε
Δεκ
Ιανουαρίου
Φεβρουαρίου
Μαρτίου
Απριλίου
Μαΐου
Ιουνίου
Ιουλίου
Αυγούστου
Σεπτεμβρίου
Οκτωβρίου
Νοεμβρίου
Δεκεμβρίου
Κυρ
Δευ
Τρι
Τετ
Πεμ
Παρ
Σαβ
Κυριακή
Δευτέρα
Τρίτη
Τετάρτη
Πέμπτη
Παρασκευή
Σάββατο
%H:%M:%S
%d/%m/%Y
%a %e %b %X %Y
πμ
μμ
%a %e %b %Y %X %Z
Ιανουάριος
Φεβρουάριος
Μάρτιος
Απρίλιος
Μάϊος
Ιούνιος
Ιούλιος
Αύγουστος
Σεπτέμβριος
Οκτώβριος
Νοέμβριος
Δεκέμβριος
dm
%I:%M:%S %p

In D42847#977752, @markj wrote:

In D42847#977744, @jlduran_gmail.com wrote:

Thank you for this nice addition! It does, however, fail when cross-building on macOS:

Hum. Thanks for the report. So we're missing definitions of ALTMON_*. I don't see a preprocessor constant that we can use to gate that

Thank you for this nice addition! It does, however, fail when cross-building on macOS:
https://pipelinesghubeus2.actions.githubusercontent.com/8Zobszzx1fzKxF8BHSJLzmYvAIfV7kuYLyhz5o35SqgHcKvvbE/_apis/pipelines/1/runs/19723/signedlogcontent/7?urlExpires=2023-12-01T17%3A06%3A05.6816198Z&urlSigningMethod=HMACV1&urlSignature=SNFGWVRwQUneUXeKKdbEWuKQ64ngWnBLEXpcY8%2FCEI0%3D
The reason being, Darwin does not have those constants (defined in a250649bd8d6999d8511cb826085deb34236f3f3 ):
https://github.com/apple-oss-distributions/Libc/blob/main/include/langinfo.h
On Linux, this is not a problem (https://www.gnu.org/software/libc/manual/html_node/The-Elegant-and-Fast-Way.html).
I trust you would know how best to proceed, whether manually adding the constants to the cross-build tools or #ifdef-ing APPLE or else.
Thank you again!

Is that really testing for the same case?

# setup_vnet(pytest:TestRtNlRoute:test_add_route4_ll_gw)
run: '/sbin/sysctl net.inet6.ip6.dad_count=0'
run: '/sbin/ifconfig epair0a up'
run: '/usr/sbin/ndp -i epair0a -disabled'
run: '/sbin/ifconfig epair0a inet6 2001:db8::1/64'
run: '/sbin/ifconfig epair0a inet6'
run: '/sbin/ifconfig tun create'

The whole point of D41330 was to handle the case where the interface doesn't have a v4/v6 address.

• Add test for IPv6
• Update commit message (plural)

In D41436#976151, @rcm wrote:

In D41436#976128, @jlduran_gmail.com wrote:

In D41436#976125, @rcm wrote:

Would it be possible to also get a v6 case?

Line 29?

ah yes, I should have scrolled up.

Is that really testing for the same case?

# setup_vnet(pytest:TestRtNlRoute:test_add_route4_ll_gw)
run: '/sbin/sysctl net.inet6.ip6.dad_count=0'
run: '/sbin/ifconfig epair0a up'
run: '/usr/sbin/ndp -i epair0a -disabled'
run: '/sbin/ifconfig epair0a inet6 2001:db8::1/64'
run: '/sbin/ifconfig epair0a inet6'
run: '/sbin/ifconfig tun create'

The whole point of D41330 was to handle the case where the interface doesn't have a v4/v6 address.

In D41436#976125, @rcm wrote:

Would it be possible to also get a v6 case?

Line 29?

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275341
Fixes:

# ifconfig wg1 create
# ifconfig wg1 up
# route -n add 10.2.0.0/24 -interface wg1

Sorry to bother again, would it be possible to MFC just this commit (4d348e83b738347f6aaf2b110459a01c5402d04e) to stable/13, the other commits in this series cannot be applied.
Reported by: Jenkins
https://ci.freebsd.org/view/Test/job/FreeBSD-stable-13-riscv64-test/936/testReport/sbin.ping/

make -C lib/libifconfig && make -C lib/libnv && make -C tools/bsdbox works. Thanks!

In D42114#969408, @markj wrote:

In D42114#969308, @jlduran_gmail.com wrote:

I would like to kindly request an MFC to stable/14 of at least this fix.
Reported by: Jenkins
https://ci.freebsd.org/view/Test/job/FreeBSD-stable-14-riscv64-test/lastCompletedBuild/testReport/sbin.ping/ping_test/ping6_c1_s8_t1/
(pasting RISC-V, as aarch64 images are failing)

Done, thanks for the reminder.

I would like to kindly request an MFC to stable/14 of at least this fix.
Reported by: Jenkins
https://ci.freebsd.org/view/Test/job/FreeBSD-stable-14-riscv64-test/lastCompletedBuild/testReport/sbin.ping/ping_test/ping6_c1_s8_t1/
(pasting RISC-V, as aarch64 images are failing)

In D42321#965756, @emaste wrote:

With this applied:

# kyua test -k /usr/tests/sys/fs/tmpfs/Kyuafile
...
82/82 passed (0 failed)

I believe this is the only (consistent) test failure in 14.0-R

I think that we should import https://github.com/NetBSD/src/commit/38862c874c4a2bcca9dce5c0966ea19ddabd523e first.
I wonder if we should skip only the failing one?

In D42268#964458, @markj wrote:

I do not have a 32-bit VM at the moment, would it be possible to run the test on ci.freebsd.org, and verify that test:

Unfortunately there's no easy way to manually test patches using ci.freebsd.org yet. In the meantime I downloaded an i386 VM image and verified that the test passes.

Thank you! I think the project insists that the documentation be in American English:

Test disabled in 2682a15527241278c9aa46c4907d3b07460b8ec0.

As long as we are keeping the old ping6 as an alias, I believe this is OK. Try pinging @asomers .

In D42114#961150, @markj wrote:

In D42114#960701, @jlduran_gmail.com wrote:

I'll submit it with the unification of ping/ping6's statistics section (D39126).

Are some of your older ping patches ready to commit? Please point me at them if so.

Updated commit message.

As you well pointed out, here is the fix from NetBSD:

I'll investigate a bit further. I am able to reproduce it on my mac:

In D42114#960670, @asomers wrote:

If we were computing with real numbers, then it should be impossible for vari to ever be negative. And in fact, all of the failing tests use -t 1, which means that n will be 1, so vari should always be exactly zero. So the fact that you're seeing these errors must mean that we're hitting some kind of floating point round-off error.

Will this affect upgrading poudriere jails with a kernel, see poudriere-jail(8)'s -K?

I noticed this change broke macOS cross-builds on GitHub. I guess due to the fact that man clang on macOS says: The default C++ language standard is gnu++98.

In D41105#953123, @sean.lim_dell.com wrote:

Ping. Any reviewers?

Nice! Thank you!
Also PMTUD problems, UNIX traceroute "not working", the list of issues can be long.
I'll go ahead and disturb @freebsd-transport, to ask if they have something to say against this change.

• Remove extra white lines after the $FreeBSD$ tag removal

• Rebase (remove FreeBSD RCSIDs).

@emaste I was just curious if there is a release-blocking metabug, just like PR 271607, but for phabricator?
I believe D41330 should be in the blocking list.

As you might already know, commit 28f6c2f292806bf31230a959bc4b19d7081669a7 broke GCC 12 compilation (https://cirrus-ci.com/task/6695038801936384).
I did the lazy thing and added:

CXXFLAGS.gcc+= -Wno-error

to gmock_main/Makefile and gtest_main/Makefile, but I believe a more granular approach is also desired for GCC.

Rebase.

Thank you!
I also had to add:

LDFLAGS+=       -Wl,-znoexecstack

to secure/lib/libcrypto/**/**/Makefile.

Is there a reason why this change was not MFCd? Thank you!