Remove unnecessary upstream divergence with GZIP call

Install pump with INSTALL_SCRIPT, not INSTALL_PROGRAM, so STRIP can be enabled again

Mute gzip --help noise by redirecting stderr to /dev/null

An internal tool at Isilon expects files named *.list to be in a
certain format, which this file is not. Rename it.

*facepalm* this is really happening? Oy...

Could you please test this change out on amd64?

This is totally fine —- as long as the upstream commits are referenced, I’m ok with that (my concern is with changes not being communicated beforehand and having to reverse engineer where and how to upstream them to the other projects, since things tend to change from time to time).

In D20943#454106, @olivier wrote:

In D20943#453979, @ngie wrote:

Good eye!
Could you please adjust the script from the Makefile so this script doesn’t need to diverge from upstream?

What do you man by adjusting the script from the Makefile ?
Do you mean modifying lib/libc/tests/net/Makefile to add an action to rename services.cdb ?

Good eye!

This should actually be obtained via ctypes.

A change related to this broke CI (example):

...
Fail: incorrect exit status: 1, expected: 0
stdout:

1. This broke the build with gcc:

11:40:34 --- all_subdir_aesni ---
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c: In function 'xor_and_encrypt':
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:61:18: error: incompatible types when initializing type '__m128 {aka __vector(4) float}' using type '__m128i {aka __vector(2) long long int}'
11:40:34   __m128 retval = _mm_xor_si128(a, b);
11:40:34                   ^~~~~~~~~~~~~
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:63:21: error: incompatible type for argument 3 of 'aesni_enc'
11:40:34   retval = AESNI_ENC(retval, k, nr);
11:40:34                      ^
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:47:64: note: in definition of macro 'AESNI_ENC'
11:40:34  #define AESNI_ENC(d, k, nr) aesni_enc(nr-1, (const __m128i*)k, d)
11:40:34                                                                 ^
11:40:34 In file included from /workspace/src/sys/crypto/aesni/aesni_ccm.c:46:0:
11:40:34 /workspace/src/sys/crypto/aesni/aesencdec.h:115:1: note: expected '__m128i {aka const __vector(2) long long int}' but argument is of type '__m128 {aka __vector(4) float}'
11:40:34  aesni_enc(int rounds, const __m128i *keysched, const __m128i from)
11:40:34  ^~~~~~~~~
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:64:9: error: incompatible types when returning type '__m128 {aka __vector(4) float}' but '__m128i {aka __vector(2) long long int}' was expected
11:40:34   return (retval);
11:40:34          ^
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:65:1: error: control reaches end of non-void function [-Werror=return-type]
11:40:34  }
11:40:34  ^

2. Why was this committed without signoff from someone on secteam (CC: secteam)?

In D20092#434855, @trasz wrote:

In D20092#433990, @ngie wrote:

This looks good to me (not a ports committer though, so just reviewing the change).
As a volunteer/co-maintainer on the LTP project, your suggestions make sense.
The only thing that I would do is install LTP to /compat/linux/opt, if at all possible. If not, we can come up with a better way to build/relocate LTP (I wrote the current build system about a decade ago for the project).

But it does install to /compat/linux/opt - except for the documentation (where it follows Linux conventions) and two binaries - not sure what's going on with those two.

The user space and test changes all look great. I’ll defer to someone else (like kib@) about the VM changes.

In D20005#430003, @cem wrote:

It's not a static number, AFAICT, depending on how the kernel maps libraries or waves hands does stuff with virtual memory. Hence the sloppy 66xxx match. I think @lwhsu's proposal is something like atf_check [ "$num" -gt 65535 ], which verifies that the number exceeds the lower 16 bit limit (which is the coredump feature the regression test is attempting to verify).

This looks good to me (not a ports committer though, so just reviewing the change).

In D20124#433272, @ngie wrote:

I’m a bit ambivalent about this change, because it’s up on the wiki in greater detail: https://wiki.freebsd.org/TestingFreeBSD . kyua(1) references atf(7) IIRC, but it’s a level of indirection.
My point is, I’d personally prefer not mentioning just ATF in tests(7), but I want it to be enough of a living document where multiple sources can contribute to it, but mentioning the wiki page doesn’t seem like something that’s generally done from a manpage because the location and content in a wiki page can change.

I’m a bit ambivalent about this change, because it’s up on the wiki in greater detail: https://wiki.freebsd.org/TestingFreeBSD . kyua(1) references atf(7) IIRC, but it’s a level of indirection.