Thanks! Although I don't have a ports commit bit yet, so you'll have to do it :)

Removed test suite after comments from D54668.

That reasoning makes sense, it's not worth it then. Abandoning this revision now. I'll change the meld update review to avoid adding a test suite.

Added better description and link to changelog for evidence, bumped PORTREVISION.

Sorry about the confusion. I had a patch ready to update meld locally that depended on this change. I have submitted it in the patch stack now.

Narrowed down review to purely need-driven changes in v2. textproc/meld needs this for its test suite to pass in a future upgrade.

Yes, I can look into each of those ports in a future review. This review is narrowly scoped to just RUSTFLAGS, can we get this in first?

Thanks, applied feedback now.

Could you make it so that lang/python27 + the ports using python27 do not use this feature?

@charlesrocket How did you reproduce that error? With your ghostty-1.2.0 patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287642 on top of this patch, I ran make patch and things ran successfully. I also tested with poudriere testport and things are building fine. I don't think this patch is the cause of that. This fixes the issues listed in https://github.com/kenrap/zig2tuple/issues/1.

I am trying to port https://github.com/neurosnap/zmx with this patch: {F140747876}. It pulls in dependencies that are tarballs reflecting the above examples in the patch description. Trying to build zmx without this patch fails. I'm sure many other zig projects with a decent number of recursive dependencies will have this issue.

I also notice that Uses/zig.mk is unmaintained. I have a few other fixes/improvements locally that I'd like to submit soon. I am willing to take over maintainership if necessary (I don't have a ports commit bit yet though).

also some packages needs to be run tested, for example install the python package on a system. As root in a python cli import anything which is installed by the package, and run pkg check to see of this pyc were regenerated.

Passes for more than 10000 iterations now, seems to work for my local testing.

Sorry to bring this back, but I'm noticing intermittency again on latest 16-CURRENT HEAD. I can reproduce it locally on amd64, and I'm seeing it fail on aarch64 in jenkins with the same result: https://ci.freebsd.org/view/Test/job/FreeBSD-main-aarch64-test/1857/testReport/sys.fs.fusefs/bad_server/main/

Looks like https://github.com/freebsd/pkg/pull/2577 is needed first after https://github.com/freebsd/pkg/commit/08bf9b3d79b127b127ecf597286ba14c016af8c4 was merged.

@bapt can we get this merged if there are no other issues with it?

Seems to fix the intermittency even with a very long runtime. I'm not the best person to review the changes, but it works well for me.

@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 several 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.