In D22272#486919, @gjb wrote:

Has it been confirmed that the tests-dbg.txz file in fact contains files? I removed it from the list of EXTRA_DISTRIBUTIONS in r278486 because it resulted in an archive that did not have any content.

The changes are great!

Remove unnecessary GitHub boilerplate noted by @bdrewery and @Vladimir.Chukharev_gmail.com .

Oh wait... GitHub was required because the release tarball doesn't contain the tests.

Use CHEESESHOP again.

In D21654#482533, @bdrewery wrote:

In D21654#482501, @ngie wrote:

@bdrewery, @mat, @woodsb02: ping?

The poudriere test completeness is unclear to me. It may seem like a big ask but I'm sure you understand the bound version dependency problem between python ports. I think you did run it but your paste was cut off or something. Just confirm you ran as Ben requested and I'll +1 this.

Use the PORTVERSION for GH_TAGNAME instead of a full hash

@bdrewery, @mat, @woodsb02: ping?

allow_sysctl_side_effects is set in the test already — LGTM!

@fernape: could you please take this revision so I can sign off on the change?

Abandoning this revision.

Still an issue:

$ (cd ~/svn/freebsd/base/head/; svnversion; make -C lib/libc buildenv)
352519
make: "/home/ngie/svn/freebsd/base/head/lib/libc/net/Makefile.inc" line 130: warning: duplicate script for target "afterinstallconfig" ignored
make: "/home/ngie/svn/freebsd/base/head/lib/libc/gen/Makefile.inc" line 554: warning: using previous script for "afterinstallconfig" defined here
Entering world for amd64:amd64

In D19997#468014, @mjg wrote:

So this is not in stable/11 and it probably is not important to get there. It is in 12.0 Can this be closed?

Restore the previous RUN_DEPENDS logic

In D21654#473466, @woodsb02 wrote:

Hi ngie,
Can you please complete build testing ("poudriere bulk -j 12amd64 -t devel/py-buildbot-www devel/py-oslotest ...") for the following ports which depend on this port?
As shown by https://www.freshports.org/devel/py-mock:

This port is required by:

for Build
        devel/py-buildbot-www
        devel/py-oslotest
        graphics/qgis
        graphics/qgis-ltr
        security/py-keystone
for Run
        audio/py-gmusicapi
        devel/py-oslotest
        devel/py-pytest-shutil
        devel/py-responses
        devel/py-sure
        devel/py-vsts-cd-manager
        graphics/qgis
        graphics/qgis-ltr
        science/py-MDAnalysis
        science/py-MDAnalysisTests
        security/py-certbot-apache
        security/py-certbot-dns-cloudflare
        security/py-certbot-dns-cloudxns
        security/py-certbot-dns-digitalocean
        security/py-certbot-dns-dnsimple
        security/py-certbot-dns-dnsmadeeasy
        security/py-certbot-dns-gehirn
        security/py-certbot-dns-google
        security/py-certbot-dns-linode
        security/py-certbot-dns-luadns
        security/py-certbot-dns-nsone
        security/py-certbot-dns-ovh
        security/py-certbot-dns-rfc2136
        security/py-certbot-dns-route53
        security/py-certbot-dns-sakuracloud
        security/py-certbot-nginx
        sysutils/py-azure-cli
        sysutils/py-azure-cli-batchai
        textproc/py-mkdocs
        www/py-kallithea
        www/py-rhodecode

Remove devel/py-tox dependency

Update the diff after feedback received and to fix the test target
by using github to pull down the sources and pytest to run the tests,
like tox.ini does.

Thank you for fixing my flaky test (and for teaching me a new tidbit about shell support)!

I'll take a closer look at this sometime this weekend..

• Shuffle around installing the README files (they shouldn't be reliant on PUMP support)
• Fix the duplicate prefixing of distcc in ETCDIR.

In D21259#462283, @fernape wrote:

Hi Enjie,
Sorry for the last commit.
I arc patched this review and tested in poudriere for {11.2,12.0}{amd64}{i386} and I'm seeing pkg-plist issues:

===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: etc/default/distcc
Error: Orphaned: %%ETCDIR%%/clients.allow
Error: Orphaned: %%ETCDIR%%/commands.allow.sh
Error: Orphaned: %%ETCDIR%%/hosts
Error: Orphaned: man/man1/include_server.1.gz
Error: Orphaned: man/man1/lsdistcc.1.gz
Error: Orphaned: man/man1/pump.1.gz
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/COPYING
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/README.pump
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/TODO
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/README
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/default
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/hosts.allow
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/init
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/init-suse
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/logrotate
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/services
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/example/xinetd
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/protocol-3-impl.txt
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/protocol-3.txt
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/protocol-gssapi.txt
Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/survey.txt
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.

Do you see the same?

Address some of @fernape's concerns and all of @mat's concerns

In D21259#464853, @fernape wrote:

I have a new patch that addresses some of the things pointed by @mat and updates the port to 3.3.3 (recently released).
Since I'm not the creator of the review I don't know if it is OK to just arc diff --update this?

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)?