- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 8 2025
Apr 22 2025
Apr 10 2025
Apr 9 2025
May 15 2024
Apr 9 2024
Dec 21 2023
Dec 7 2023
Oct 3 2023
Sep 4 2023
Sep 2 2023
Sep 1 2023
Aug 31 2023
Aug 28 2023
Aug 27 2023
Aug 26 2023
Jul 31 2023
Jun 24 2023
May 21 2023
May 9 2023
finally 2 cents of review here after a long time hiatus! thank you @des
May 6 2023
hello folks,
Mar 28 2023
ping @src
ping @src
Feb 13 2023
Feb 12 2023
Jan 23 2023
ping
ping
Jan 1 2023
In D36241#861449, @asomers wrote:The only problem I have with this new feature is that it is 75% redundant with updatesready. I think that having two so-similar features will confuse users. Is there any way to get the benefits of both, while not adding any new commands?
Dec 30 2022
any new input from @src would be really appreciated here; this is running smooth for me since past updates (for all supported releases).
In D27318#855240, @bcr wrote:OK from manpages for these latest changes. Thanks for your patience working on this patch!
Dec 27 2022
Dec 21 2022
Dec 6 2022
thanks @gbe !
it would be awesome to get approval from src, so we can land this one -- which I am using solo for quite a time
Nov 27 2022
changes since last update:
- rebased on top of freebsd/main 671f55828d03;
- applied sugestion from @imp, to make output checks more reproducible
Nov 26 2022
Nov 5 2022
any new inputs about it? shall we finally land the patch?
Nov 3 2022
any further suggestions or inputs about this change request? anyone?
I've being running that for quite a while and the fleet is green ever since.
hey there! hello @otis, thanks for flagging (and patching) that. much appreciated; that would speed up the fix you can commit it.
Oct 18 2022
Oct 15 2022
Oct 14 2022
Oct 3 2022
Sep 29 2022
Sep 28 2022
Sep 27 2022
- update diff, to sync latest changes from https://reviews.freebsd.org/D36516;
- apply suggestions from @allanjude (to avoid spawn new processes, using case).
In D27318#827073, @egypcio wrote:ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.
Sep 1 2022
ping?
ping?
ping @kevans (or anyone else from src)?
mind to have a look again, to maybe approve it after all changes got applied; it should be ready-to-go.
Aug 22 2022
In D36241#824095, @asomers wrote:indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.
check the TEST PLAN above
updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.
the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).
But every user who runs "freebsd-update check" will eventually also run "freebsd-update fetch". So is the overall load any less this way? Does "freebsd-update fetch" download all files on every invocation, even if there are already downloaded files that haven't been installed?
In D36241#823751, @asomers wrote:I guess the main difference between check and updatesready is that the latter requires you to fetch the updates first, right? Is the workflow you envision a cron or periodic job that only runs freebsd-update check and informs the user if there are any updates, but makes them actually fetch those updates manually? For a user who eventually applies every update, will this new workflow result in less total load on the update servers, or about the same?