@asomers As of f4f638eb23d770e19ede167908d8145b8851f835, this test is still failing intermittently in CI as seen here on aarch64: https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/1801/testReport/junit/sys.fs.fusefs/bad_server/main.

I think this commit is missing an addition to BSD.tests.dist because I get an error during make installworld. I've posted a quick github PR here, could you review and merge if it's correct? https://github.com/freebsd/freebsd-src/pull/1877

As listed here: https://tests.reproducible-builds.org/freebsd/freebsd.html, it seems that there are a lot of other parameters that can also be changed to get better coverage. For example, can we also change these parameters? :

• (trivial) UID/GID of the building user
• (trivial) hostname
• (maybe in the future) mounting a disorderfs path and building there?

LGTM and makes sense. Tested on loop for 15+ minutes and found no failures.

This patch seems to break 2/11 of the testcases in the sys/geom/class/multipath/misc test suite with this output:

@bapt any info on the above? Can we get this merged first (since it would be harmless) so that we can start publishing reproducible builds stats for the Ports collection? The python ports can be looked into after that.

Yes, it boots successfully with those two commits applied, thanks! Please update PR 290044 once they land.

This commit (https://cgit.freebsd.org/src/commit/?id=c67ea2707d2b5e6deb5986710f520ff69e4f78a3) seems to break bhyve on an Ampere Altra Mt Collins server that I've been using to do CI testing on arm64:

Instead of skipping these and keeping around lots of code to check the ovpn version, why not just temporarily xfail them like I've done in the attached patch of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289150? That way, once Ports contains ovpn>=2.7, these tests will automatically start failing again with the message "failed: expected failure, but none found". We can remove the xfails promptly afterwards.

someone needs to understand why the not ok package are not ok, is this is related to the timestamp or not.

@bapt any updates on reviewing v2 and the results of the reproducibility test of 160 packages from above?

This commit seems to break the build (even on a clean build) with the following error:

Thanks for the catch, fixed in v2.

Abandoning due to feedback.

In D12099#1176201, @markj wrote:

I think this is OBE. We have a KUBSAN runtime now in kern_ubsan.c.

fixed missing hd1 declaration across all platforms in this revision

In D51479#1175570, @bofh wrote:

I don't this is required anymore after https://cgit.freebsd.org/src/commit/tests/ci/Makefile?id=9f3e4b28f9dec27b73eeebd161d119d1e9864081

before requesting an exp-run or anything like that, have you tested on a bulk of known problematic ports ? python for example or emacs?

Removed mac_ipacl from this revision since it is deny-by-default and causes a portion of sbin/ping tests to fail (needs further work to figure out how to enable the right syctls).

Upon further testing, I am closing this for now and will revisit this change later. For some reason, running the CI test suite with this change causes a large chunk of the sbin/ping test suite to fail with ping: ssend socket: operation not permitted. I think it has something to do with the make distribution or make installworld step being run as non-root.

Narrowed down SU_CMD usage to only those exact commands that need it, rather than an entire make invocation. I will also be moving this patch to the top of the stack.

> Maybe the find was not strong enough. https://www.freshports.org/devel/linux-ltp

Added back linux-c7-ltp and canonicalized it with its origin as devel/linux-ltp.

Rebased in v2.

Rebased in v2.

Rebased in v2.

Moved back to release script style in v2.

Moved back to release script style in v2.

I've added a stack of diffs here. Let me know if I need to add all reviewers to each review in the stack. I didn't want to spam everyone, so I've left it like this.

Thanks! Abandoning this now. I've added a stack of reviews here: https://reviews.freebsd.org/D51303. I tried to use git-arc from /src/tools/tools/git which said that it would automatically link each pair of consecutive commits as a stack, but I had to end up manually editing related revisions in Phabricator web.

I've mostly listed the rationale, notes (e.g. about why some have full vs partial origin), and necessity for each change in each individual commit that is attached in the bugzilla link. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288150

In D50911#1161997, @bapt wrote:

before requesting an exp-run or anything like that, have you tested on a bulk of known problematic ports ? python for example or emacs?

I'd like to take over this patch and the previous one at D4385 to help push this in. I am also currently building some tooling around Poudriere to help verify reproducibilty across the ports tree. Have there been any more recent discussions around implementing SOURCE_DATE_EPOCH in the Ports tree other than these two Phabricator reviews? If not, I'll start testing this and working on the feedback, then resubmit a v2.

Refreshed patch. @ashish any feedback on this?

Reverted the replacement of static release tarball with USE_GITHUB.

Wrong commit order, accidentally deleted license.

Fixed style(9) issues.

That makes sense, I will continue working on an actual solution to the panic. Thanks for the clarification.

Fix style and semantics issues

Thanks for the feedback Kostik! Updated to reflect the changes.

Accidentally had extra whitespace in previous diff

• Moved around kernel options to correct locations and added additional comments
• Added assert for checking bounds of array access

Add license after consulting with Ed

• Add a check for the maximum history size. This maximum is set to the same value as the maximum in syscons(4).
• Fix the error string on a negative number argument

Accidentally updated wrong review, reverting back to previous diff

• Add a check for the maximum history size. This maximum is set to the same value as the maximum in syscons(4).
• Fix the error string on a negative number argument

cngets() already calls cngrab() in sys/kern/kern_cons.c here:

Fixed style issues.

• Added comment to sys/kern/capabilities.conf for more information on where the sysents are being initialized
• Added flags to SYSCALL32 initializers

Changed module syscall init helpers to initialize flags

Shouldn't expose locking macros to makefs

Abandoning because this change doesn't functionally change anything, it isn't actually fixing any bugs.

Reverted DEEXTERNALIZE changes, refer to D11217 for bugfix