Cleaning out stale reviews.

Updated from discussion offline. I will commit this version instead. I will figure out a way to add "skip reason" metadata to Kyua in a future patch.

Added a comment pointing to the pkg origin of dhcpd

Thanks, will do. Abandoning this now then.

Closed by https://cgit.freebsd.org/ports/commit/?id=c4faf46ff4741f016c5196e1de77822733ff4a1f, I had linked the wrong review in the commit message, sorry about that!

Closed by https://cgit.freebsd.org/ports/commit/?id=919a4da7ff9794ffa53dbdd972ae25ec30368fa0, I had linked the wrong revision in the commit message so the automation didn't pick it up.

Removed python314 from this review, will post in a separate review.

Abandoning this revision since it's already merged in.

Does this have anything to do with Rust ports specifically? This review is tied to the deprecation of the --ar flag in Rust (which is documented to do nothing).

Yes, it passes a make test after successfully building in poudriere testport.

In fact, it looks like Uses/go.mk now has built-in functionality for make gomod-vendor, in the sense that we don't need to update the distinfo or *_TUPLE at all. It builds perfectly fine in a poudriere testport that restricts networking access after the FETCH stage.

Anything further for this review?

Abandoning old stale review.

Sure, I'll commit it then. Thanks for the approval!

Thanks for the clarification, I'll keep that in mind for future patches. I think for this case, it's better if you commit it as the maintainer, especially since I'm a new committer.

Here's an example from the attached full build log of devel/nextest:

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: