some gnome packages issues after recent quarterly pkg repo update

W

wismos

so after recent pkg quarterly repo update to 2025Q2, upon doing pkg upgrade some gnome packages got removed from my system
1744041312458.png

and i am unable to reinstall them as my pkg is unable to find them
1744041344267.png

i tried changing mirrors as well but that didn't help as well, any help would be appreciated
 
The gnome and gnome-lite metaports failed to build for amd64 FreeBSD:14:quarterly, you can check the table here: https://www.freshports.org/x11/gnome
I'm not super knowledgeable but as I understand it, if one package from the metaport fails to build the whole metaport gets wiped out. There are 3 solutions.
1- (and best practice) would be to manually issue the pkg upgrade command and review the output before proceeding. In my case the list below would've been a good reason to stop the upgrade.
Installed packages to be REMOVED:
evince: 43.1_11
evolution-data-server: 3.44.4_8
glade: 3.40.0_4
gnome-control-center: 43.2_4
gnome-lite: 42_5
gnome-online-accounts: 3.44.0_3
gnome-shell: 42.4_11
gnome-shell-extensions: 42.3_2
gnome-terminal: 3.44.2_3
gnome-tweaks: 40.10_4
grilo-plugins: 0.3.15_1
libgdata: 0.18.1_1
libhandy: 1.6.2_2
nautilus: 42.2_3
seahorse: 41.0_3
sushi: 42.0_4
totem: 3.38.2_7
tracker: 2.3.4_12
tracker3: 3.5.3_2
webkit2-gtk3: 2.34.6_10
yelp: 42.1_3
2- As others have suggested, you could switch your repos from quarterly to latest because the latest build did not fail. This will get you up and running but will modify all of your packages to the very latest version, not just gnome. Also, running latest comes with more risk because of the increased update frequency. Instead of running into the issue you're having now once per quarter they could happen any time, the latest repo is not immune to failed builds.
3- If you take zfs snapshots you could rollback to the previous state, reboot, and check the freshports link daily until the cell for amd64 FreeBSD:14:quarterly is populated and then proceed with a pkg upgrade. This is the option I chose:
zfs list -t snap zroot/ROOT/default
sudo zfs rollback -r zroot/ROOT/default@<name of snapshot from before pkg upgrade>
sudo shutdown -r now
 
P

Solved Thread 'FreeBSD 14.2 amd64 April 2025 quarterly update KDE5 -> KDE6 issues'

I just ran pkg update/upgrade on one of my systems with KDE as the desktop.

On rebooting sddm is starting twm rather than KDE (ewwww, I feel like I fell into a time machine and went back to 1997).

sddm.log does say

[07:41:45.266] (II) DAEMON: No session manager found

Any ideas what to fix?

Pay attention before you automatically update. It removed those packages. Best I can do is tell you to fall back to a ZFS snapshot if you have one.
 
i do understand the points everyone has mentioned but what i do not understand is the reason why the search doesn't work, even though it is part of a metaport, it is a seperate package as well which should show up in the pkg search right? given it didn't fail
 
wismos said:
i do understand the points everyone has mentioned but what i do not understand is the reason why the search doesn't work, even though it is part of a metaport, it is a seperate package as well which should show up in the pkg search right? given it didn't fail
Click to expand...
Because there is no pkg for those. They were removed. You can't get them. They were not built.
 
Individual packages that fail to build won't be seen in a pkg search. Build cce5eec19b3a shows a status of done and under built ports evince and gnome-terminal are not listed. Once a build comes through that successfully creates the packages you're looking for it will still take time for the binaries to propagate to the pkg servers. Only then will you be able to search/install the individual packages.
Screenshot 2025-04-07 at 4.37.56 PM.png

From what I understand the source of the issue is with webkit2-gtk which failed to build and as a web engine a lot of other packages rely on it. Once someone fixes that package it should allow all the others that are affected to build.
 
Sadly, the latest pkg upgrade killed KDE Plasma desktops on multiple hardwares.
(Note to self, next time, upgrade just 1 machine, test and sweeten to taste before upgrading others.)
Hopefully there'll soon be a way to recover from this failure, otherwise I'll need to rebuild from scratch (and avoid the latest pkg upgrade).
:-(
 
bgroper said:
Sadly, the latest pkg upgrade killed KDE Plasma desktops on multiple hardwares.
(Note to self, next time, upgrade just 1 machine, test and sweeten to taste before upgrading others.)
Hopefully there'll soon be a way to recover from this failure, otherwise I'll need to rebuild from scratch (and avoid the latest pkg upgrade).
:-(
Click to expand...
It killed Xfce on mine. I didn't think something like this could be pushed to the default repository. I guess there are not enough volunteer testers for latest and quarterly. It will be a long time before I trust pkg upgrade again, so I will test it very thoroughly in future before using it on my main PC. I want it for security fixes.
 
Well, there were some issues with pkg 2.0.x... Right now, pkg is at 2.0.6, and the issues seem to be on the other end of the wire - you send the search request to a remote repo, but the remote repo was not set up right, so it's not responding right.

This is why I use ports. I just fetch the most recent snapshot, compile stuff on my own machine, with my own flags (I turn on all the available sound systems, I also turn off static compilation, and default to OpenSSL rather than WolfSSL) in make.conf.
 
astyle said:
Well, there were some issues with pkg 2.0.x... Right now, pkg is at 2.0.6, and the issues seem to be on the other end of the wire - you send the search request to a remote repo, but the remote repo was not set up right, so it's not responding right.

This is why I use ports. I just fetch the most recent snapshot, compile stuff on my own machine, with my own flags (I turn on all the available sound systems, I also turn off static compilation, and default to OpenSSL rather than WolfSSL) in make.conf.
Click to expand...
there are many who prefer to use pkg and for the right reasons for them as well, i don't think it's a solution to a problem that shouldn't have existed in the first place(i.e. pushing quarterly updates when many dependencies are in queued to be built), i myself prefer pkg because the simplicity, saved time (no compilation) and the defaults are more then enough for me in most cases
 
bgroper said:
Sadly, the latest pkg upgrade killed KDE Plasma desktops on multiple hardwares.
(Note to self, next time, upgrade just 1 machine, test and sweeten to taste before upgrading others.)
Hopefully there'll soon be a way to recover from this failure, otherwise I'll need to rebuild from scratch (and avoid the latest pkg upgrade).
:-(
Click to expand...
E

Solved Post in thread 'FreeBSD 14.2 amd64 April 2025 quarterly update KDE5 -> KDE6 issues'

This may help: x11/kde6 - Notes from updating.

This might have the quick fix for you.
 
thedaemon said:
E

Solved Post in thread 'FreeBSD 14.2 amd64 April 2025 quarterly update KDE5 -> KDE6 issues'

This may help: x11/kde6 - Notes from updating.

This might have the quick fix for you.
Click to expand...
Thanks for suggestion. Sadly, I'm remaining unable to achieve success with KDE/plasma.
# pkg install plasma6-plasma
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'plasma6-plasma' have been found in the repositories
Click to expand...
 
bgroper said:
Thanks for suggestion. Sadly, I'm remaining unable to achieve success with KDE/plasma.
Click to expand...
It appears there are widespread issues with both quarterly and latest repos for FreeBSD 14 on amd64 affecting gnome, kde, and xfce. For KDE the build appears to fail due to the package accounts-qml-module. Once resolved you'll see the KDE version populate in the cell for your platform, repo, & FreeBSD version in the table here https://www.freshports.org/x11/kde for example FreeBSD:14:latest & amd64. Until it is populated for the cells that match up with your system even a fresh OS won't allow you to install the missing package.
mariachi said:
I'm trying FreeBSD for the first time and I can't install `www/caddy`, is it related to this quarterly builds situation?
Freshports (https://www.freshports.org/www/caddy/) says the latest version is in the quarterly branch, pkg-fallout is empty (https://portsfallout.com/fallout?port=www/caddy$)
Click to expand...
No, caddy does not appear to be affected by these issues. I'm on the quarterly repo, FreeBSD 14 amd64 and am able to see it with pkg search. What command are you issuing? sudo pkg install caddy should work if you've installed sudo or you can:
su -
pkg install caddy
 
mariachi said:
pkg-fallout is empty (https://portsfallout.com/fallout?port=www/caddy$)
Click to expand...
Note that portsfallout only shows something if the port itself failed to build. If the port is skipped due to a build failure on a dependency that issue won't show up.

Yesterday (Tue, 08 Apr 2025 01:01:17 GMT) a new quarterly was done, it fixed a bunch of things. www/caddy got skipped due to a failing build of lang/go121. As it did on the previous builds. Seems building every version of the golang ports fail, which has a cascading effect.

Screenshot-caddy.png

Poudriere bulk results

pkg-status.freebsd.org pkg-status.freebsd.org
 
joe81tx said:
It appears there are widespread issues with both quarterly and latest repos for FreeBSD 14 on amd64 affecting gnome, kde, and xfce. For KDE the build appears to fail due to the package accounts-qml-module. Once resolved you'll see the KDE version populate in the cell for your platform, repo, & FreeBSD version in the table here https://www.freshports.org/x11/kde for example FreeBSD:14:latest & amd64. Until it is populated for the cells that match up with your system even a fresh OS won't allow you to install the missing package.

No, caddy does not appear to be affected by these issues. I'm on the quarterly repo, FreeBSD 14 amd64 and am able to see it with pkg search. What command are you issuing? sudo pkg install caddy should work if you've installed sudo or you can:
su -
pkg install caddy
Click to expand...
for me it's missing:
```
# pkg install caddy
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'caddy' have been found in the repositories
```
but it looks like that's expected, according to 👇
SirDice said:
Note that portsfallout only shows something if the port itself failed to build. If the port is skipped due to a build failure on a dependency that issue won't show up.

Yesterday (Tue, 08 Apr 2025 01:01:17 GMT) a new quarterly was done, it fixed a bunch of things. www/caddy got skipped due to a failing build of lang/go121. As it did on the previous builds. Seems building every version of the golang ports fail, which has a cascading effect.

View attachment 22207

Poudriere bulk results

pkg-status.freebsd.org pkg-status.freebsd.org
Click to expand...
 
This is why I stick to ports - I don't have to rely on someone else to build the packages for me (and have building issues and be aware of schedules, what got done, for which package, which arch, and whether remote repos are having issues that prevent pkg from accessing them properly). Granted, you gotta have capable metal, and to do your own scheduling, and to figure out how to manage your own updates.

Yeah, one also needs to be comfortable running make && make install, but that normally takes less time than it takes to figure out that a remote service running the exact same thing is having issues building that exact package, and things won't shake out for a while. Even if it is a major package like editors/libreoffice.... I have compiled it on an i5-2467M. Consider this: If a package doesn't build for the official repos, it's gonna take at least a few days for things to shake out. But a compilation will probably take about 20 hours straight, your own machine will work nonstop until the compilation is over. User can take a break from research and go eat/sleep, computer is not gonna stop, you can set up an overnight job and go to sleep, and wake up to a shiny new package that your computer made for you while you slept.
 
You must log in or register to reply here.
Back
Top