It would be upgraded to 580.95.05 on next pkg builds.NVidia upgraded to 580.82.
I refer back to one of my previous posts- there are heuristics to avoid publishing a set that is far too broken, but obviously you'll win some and lose some. That's the nature of software- pkg or poudriere could probably handle something better here, but I don't think I've really seen any workable proposals (and certainly nobody willing to help out with It).Y'know, assuming you are correct, and people are NOT supposed to be able to see even partial results, it would mean thatpkg query
would consistently return 'no packages available' given a list of details like uname -a, whether the user is on quarterly or latest, and the like.
But, it appears that a repo is allowed to appear on schedule, even if there are build failures (which leads to some missing packages). And that is visible to users if the package they query for is missing (but should not be! If a repo is visible, it's kind of expected to be complete... or at least reasonably complete).
Well, rank-and-file users are seeing an awful lot of failures lately, and are getting disillusioned with those heuristics because of those failures. Not directly, but I was hoping that the packagers see that connection, and maybe try do something...I refer back to one of my previous posts- there are heuristics to avoid publishing a set that is far too broken, but obviously you'll win some and lose some. That's the nature of software- pkg or poudriere could probably handle something better here, but I don't think I've really seen any workable proposals (and certainly nobody willing to help out with It).
If true, that would mean that the "pkg upgrade" mechanism has only a reliability of 1-2 nines (about 90% to 99%). That would be insanely bad.
As per kevans (who knows), that is NOT how it works. There are much smaller vulnerabilities, if a small number of packages fails to build, but that is several orders of magnitude lower.
It would be upgraded to 580.95.05 on next pkg builds.
With possible security reason, already merged into 2025Q4, too.
That a relatively small amount of packages that you have, My conclusion is more and more based on experiences that PKG utilitiy is not good at managing a big amount of packages and dependencies.Just did pkg update / pkg upgrade -- and it worked flawlessly !
I picked up around ~471 packages and made ~880 changes. And I (did not) have to manually recompile drm-61-kmod this time! Fantastic ! NVidia upgraded to 580.82.
Awesome job FreeBSD package maintainers !
![]()
I'll be sure to laugh at you when you'll be the one facing issues.Maybe one of 'em broke his ! key? (Sorry, that was mean, but it makes me chuckle, so I'm leavin' it).
That a relatively small amount of packages that you have, My conclusion is more and more based on experiences that PKG utility is not good at managing a big amount of packages and dependencies.
Just from one of the secondary installs (not even my main desktop which has way more pkgs, but I'm booted in Alt Linux ATM building 16.6.7 kernel for QEMU aarch64 Gentoo – it will take some time)That a relatively small amount of packages that you have, My conclusion is more and more based on experiences that PKG utilitiy is not good at managing a big amount of packages and dependencies.
pkg info | wc -l
1566
and I have not been reinstalling the missing one yet, because of lack of time. In fact, I have been restored 16 packages since PKG is mess.
pkg info | wc -l
1768
Yeah, that's a proper spirit of OSS collaboration and helping fellow users /sI'll be sure to laugh at you when you'll be the one facing issues.Maybe one of 'em broke his ! key? (Sorry, that was mean, but it makes me chuckle, so I'm leavin' it).