pkg repo quoterly vs latest

Now (april 2025) quoter is changed, so repository is changed. Bunch of packages to upgrage.
And also some packages was lost -- absent in quoterly repository. Among them
* mate
* mate-base
* okular
Looks like the same base of problem is here https://forums.freebsd.org/threads/gnome-gui-crash-of-pkg-upgrade-to-new-at-freebsd14-2p2.97437/

So, while the solution to change main repo to lates looks good, it must follow by changing branch of /usr/ports (now I have also quaterly, i.e. 2025Q2 for now).

And my question is: why theese packages is missing? Maybe it's normal and I just must to wait a couple of days?
 
Right after 2025Q2 was branched off a build was started, those packages have been mirrored to the package servers. I see a whole new build was started (and finished) this weekend, it should appear on the package servers soon. Hopefully this included a bunch of fixes for things that were broken.

You need IPv6 but you can keep track of the builds here: https://pkg-status.freebsd.org/builds?jailname=142amd64
 
Right after 2025Q2 was branched off a build was started, those packages have been mirrored to the package servers. I see a whole new build was started (and finished) this weekend, it should appear on the package servers soon. Hopefully this included a bunch of fixes for things that were broken.

You need IPv6 but you can keep track of the builds here: https://pkg-status.freebsd.org/builds?jailname=142amd64

Oh, thanks. But please, comment that contents... I understand, that is poudriere status. But what means "exp builds", "package builds". I suppose, I'm looking for something like (jail) 142amd64 and 142i386 (I recently find out, that wine is broken too for now -- on amd64 it install local i386 packages, and versions differs for now).
Am I waiting for "done" in "Exp builds" or my builds in "Package builds" and I just waiting for file sync somewhere?
 
Am I waiting for "done" in "Exp builds" or my builds in "Package builds" and I just waiting for file sync somewhere?
Only the "Package Builds" would be interesting for you. There should be two, 'default' (which is main aka 'latest') and 'quarterly'.

What for? i can resolve pkg-status.freebsd.org with ipv4.
You can drill down to the actual build logs on the package builders themselves, those are only accessible using IPv6.
 
Only the "Package Builds" would be interesting for you. There should be two, 'default' (which is main aka 'latest') and 'quarterly'.


You can drill down to the actual build logs on the package builders themselves, those are only accessible using IPv6.
Finally, it still not all clear to me... -- I can see that in "Package builds" ports=quaterly and jails 142amd64 and 142i386 is all done. (by Sun, 06 Apr 2025 01:01:19 GMT and Tue, 01 Apr 2025 01:02:09 GMT respectively).

So I just have to wait packages to appear on pkg servers? Maybe you know from your exipirence, how long one should wait in new quoter to issue "pkg upgrade" ?
 
i386 is not that important, it's Tier 2 now. The builds always take some time (latest packages took more than 40 hours), then they'll need to to be copied to the package mirrors. New build had less failures and less "skipped" ports, but there's still a few that apparently failed to build. So some packages should have returned, just not everything yet.
 
Uh, sorry, one more question, hope last here: is there clear way to see if all synced?

In my case I notice, that new quarter came, so issue pkg upgrade. Yes, I suspect something -- there was some strange, unxpected packages removal,
Code:
[ICODE]Installed packages to be REMOVED:[/ICODE]
[ICODE]        android-tools: 31.0.3p2.0_28[/ICODE]
[ICODE]        atril: 1.28.0_1[/ICODE]
[ICODE]        glade: 3.40.0_4[/ICODE]
[ICODE]        libhandy: 1.6.2_2[/ICODE]
[ICODE]        mate: 1.28.1[/ICODE]
[ICODE]        mate-base: 1.28.1_1[/ICODE]
[ICODE]        mate-user-guide: 1.28.0[/ICODE]
[ICODE]        okular: 23.08.5_4[/ICODE]
[ICODE]        remmina: 1.4.37[/ICODE]
[ICODE]        webkit2-gtk3: 2.34.6_10[/ICODE]
[ICODE]        wx30-gtk3: 3.0.5.1_5[/ICODE]
[ICODE]        wxhexeditor: 0.24_6[/ICODE]
[ICODE]        yelp: 42.1_3[/ICODE]
but I was not ready for such fail...
 
Last edited by a moderator:
Right after 2025Q2 was branched off a build was started, those packages have been mirrored to the package servers. I see a whole new build was started (and finished) this weekend, it should appear on the package servers soon. Hopefully this included a bunch of fixes for things that were broken.

You need IPv6 but you can keep track of the builds here: https://pkg-status.freebsd.org/builds?jailname=142amd64

Thx for the provided link, now I know xfce4-desktop got skipped because of webkit2-gtk_40-2.46.6, which died during the build with the following message:

Code:
Command '['/wrkdirs/usr/ports/www/webkit2-gtk/work-40/webkitgtk-2.46.6/tmp-introspectuhaycmdx/WebKit2-4.0', '--introspect-dump=/wrkdirs/usr/ports/www/webkit2-gtk/work-40/webkitgtk-2.46.6/tmp-introspectuhaycmdx/functions.txt,/wrkdirs/usr/ports/www/webkit2-gtk/work-40/webkitgtk-2.46.6/tmp-introspectuhaycmdx/dump.xml']' died with <Signals.SIGSEGV: 11>.
ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/webkit2-gtk
=>> Cleaning up wrkdir
===>  Cleaning for webkit2-gtk_40-2.46.6
build of www/webkit2-gtk@40 | webkit2-gtk_40-2.46.6 ended at Tue Apr  8 13:36:59 UTC 2025
build time: 04:43:41
!!! build failure encountered !!!

I guess my attempt to fix that by running
Code:
poudriere bulk -j 14-2-R-amd64 x11-wm/xfce4-wm
on my own is a setup for failure then. 🥺
 
tanis There are a bunch of things that have a dependency on webkit2-gtk, so until that gets fixed. When I looked at the log the webkit2 build got a SIGSEGV, that may or may not happen on your local system based on "what caused it".
Could it have been server ran out of memory because of parallel builds? Maybe.
Could it have been server had a bad memory module? Maybe.
Could it have been someone walked around the server counter clockwise instead of clockwise? Unlikely but still possible :)

So running the commands on your setup could actually work.
 
mer okay so chances are 50:50 I might actually end up with a fully working desktop again, that's great news! :D

On the other hand, chances are high the freebsd builder will surpass me and xfce4 will be available from the FreeBSD repo before my laptop ( bought 2018) finishs it's build on a single core. 😆😅
 
mer okay so chances are 50:50 I might actually end up with a fully working desktop again, that's great news! :D

On the other hand, chances are high the freebsd builder will surpass me and xfce4 will be available from the FreeBSD repo before my laptop ( bought 2018) finishs it's build on a single core. 😆😅
Exactly. But 50:50 is better than 20:80 against, no? :)
 
So how does this work, so far I used to just rely on the binary package repo, but I could just build all my required packages for my workstation and use my own binary repository ? Update would be a git pull request on the ports and just rebuild everything (poudriere) and then move on. If the packages don't build I can't update, if they do, I'm good to go. For release upgrades minor (14.1 to 14.2) or major (14 to 15) can I still rely on freebsd-update ?
 
but I could just build all my required packages for my workstation and use my own binary repository ?
You could, but you're very likely to run into the exact same build issues. Although on a local repository YOU control how and what gets updated. So you could revert the ports tree to last week (or some time before).

For release upgrades minor (14.1 to 14.2) or major (14 to 15) can I still rely on freebsd-update ?
Unless you use PkgBase the ports/packages have nothing to do with the base OS. So yes, you can still use freebsd-update(8) to update the base OS, this is entirely separate from anything happening in the ports tree.
 
but you're very likely to run into the exact same build issues.
After reading some posts on freebsd-ports mailing list, I'm starting to believe the issues are caused by the package build hosts themselves (apparently they've been hit by a bug in -CURRENT), it's not the actual ports that are bad. I've started a new build on my own build server, added Gnome, Mate and XFCE, and I'll try and see how far my system can build them. Although I am also running -CURRENT on my build host, I may have a -CURRENT from before the bug.
 
After reading some posts on freebsd-ports mailing list, I'm starting to believe the issues are caused by the package build hosts themselves (apparently they've been hit by a bug in -CURRENT), it's not the actual ports that are bad. I've started a new build on my own build server, added Gnome, Mate and XFCE, and I'll try and see how far my system can build them. Although I am also running -CURRENT on my build host, I may have a -CURRENT from before the bug.
I would agree with this, at least from my investigation of the webkit2 build failing with SEGV. Root causes for that are one of the magical "I have no idea could be hardware, software, phase of the moon..." so a different environment/configuration may work. I think single threading builds may have a positive impact (this is just a guess)
 
Well, build's finished. Everything appears to build just fine. The only thing failing was x11/gnome, not because of webkit2, but a failure with games/gnome-chess causing games/gnome-games to skip and therefor the "full" flavor of x11/gnome.

Anyway, long story short, if you build your own repository, or just old school from ports, you should be fine. Everything else appears to be complete, GNOME, Mate and XFCE.
 
What about setting-up a new/dedicated quarterly-port mailing list to notify a new quarterly built started or finished with failed port building list?
 
Back
Top