freshports.net is 3 days behind

[usbdetach]

No rush but I do hope dan l. is okay.

Tuesday, 21 Jul 2026

23:28 Christian Weisgerber (naddy) devel/got 0.127 Game of Trees version control system devel/got: update to 0.127

 

[nxjoseph@]

I think it might be related to the Ports repository being frozen.

Action Required: Recent ports history has been rewritten

EDIT: There's actually a message about it on the site.

After the ports freeze to fix some stuff, the freeze is over. I have some work to do before FreshPorts can start processing commits again before it can start processing again. I've created an issue for that.

 

[akil]

3 days later Co-Pilot figure it out that there is missing 150mb file in the ports tree

 

[Crivens]

3 days later Co-Pilot figure it out that there is missing 150mb file in the ports tree

No worries. Copilot will find it and re-add it to the next commit...

 

[usbdetach]

Is this a bit of irony? The root cause was a problem around git. While the ports repo remains frozen, the top port listed on freshports is a git alternate - got.

Here's a timeline. Looks like the ports repo no longer frozen.

FreeBSD ports unfrozen and ports history rewritten

Timeline of events: 2026-07-20 — A ~150 MB binary is committed to the ports tree in misc/github-copilot-cli (a routine version bump). It exceeds GitHub’s 100 MB object limit and carries an un…

chrislongros.com

 

[richardtoohey2]

The root cause was a problem around git.

Is that the case? I thought git showed up a real issue - the accidental commit of a 150MB binary file?

Or do you mean the (git) complexity around trying to unwind that accidental commit?

 

[Charlie_]

Refer to the link in comment 2.

git-force-push fixes · Issue #668 · FreshPorts/freshports

Once the FreeBSD git-force-push problem is fixed: compile a list of the redone commits delete the old commits FreshPorts will have the OLD latest commit. It will have to get the NEW latest commit, ...

github.com

Commit processing has resumed on all hosts. It will take a while for prod to catch up.
Probably by 22:00 UTC today.

 

[usbdetach]

... and freshports is back! Woo hoo!

 

[cracauer@]

It wasn't git's fault.

To be honest I would have expected the whole chain of infrastructure to actually handle a 150 MB file. But my understanding is that some upstream pieces had an artificial 100 MB limit. So that is configuration, not a bug or scalability issue.

 

[cy@]

It was discovered when the Github mirror process broke. Github will not accept a 150 MB file. It's a configurable thing. At $JOB we use Github Enterprise. It too will not accept files larger than 50 MB. They recommend GIT LFS. GIT LFS is just a kludge that doesn't work everywhere, plus additional caveats.

 

[T-Aoki]

My understanding with reading announcements and seeing what happened is:

1. A committer accidentally included built (or pre-built that should be one of the distfiles) binary large (150MB) object (aka BLOB) in a commit.
2. It was mirrored fine to official public repo, inofficial codeberg, inofficial gitlab. But official github mirror alone rejected it as of hard size limit of 100MB.
3. Core, portmgr and clusteradm decided to stop sync'ing from (committers only) master repo to all mirrors and freeze master repo.
4. First announcement was done on freebsd-annouce ML.
5. Master repo was somehow rolled back to just before the accidental commit.
6. Commits after the accidental one are redone (with this, commit hashes are changed, at least the one I'm the author).
7. Aftert confirming the master repo is fine again, start mirroring again (mirrors other than github would need to run the script to fixup).
8. Second annoucement (unfreeze) was done, with providing URL of fixup script for affected mirrors / clones.

 

[cracauer@]

My understanding with reading announcements and seeing what happened is:

1. A committer accidentally included built (or pre-built that should be one of the distfiles) binary large (150MB) object (aka BLOB) in a commit.

It wasn't build by the committer, it is a binary by Microsoft.