Those are packages that lot of other packages rely on and so as a result just needs more testing. Sometimes Arch is faster, sometimes other distros are faster. This is relatively normal.
Wasn’t Python being behind the reason GNOME 44 took a little while to come out? It does seem like things move a little slower than they used to. Might be a good thing for stability in the long run. Think people need to be reminded that Arch is community run too. So updates might lag behind compared to these distros with big corporations behind them.
I believe I read there was only one package maintainer for Gnome on Arch, which is why the release took longer. We have to remember it’s often just regular people, or in that case, person, who maintains this stuff for free or very little. And just because upstream made a release doesn’t mean it’s a simple drop-in to our distro of choice.
To add to this, all of the packages mentioned have a -git version in the AUR. The people who really need the absolute newest version can always install these packages. The rest of the people (those who prefer stability) can continue using a slightly older, but well-tested versions of these programs.
No what you want is unstable Arch which you can freely do by changing the repos, but your user experience will be fraught with pain and issues. You can move to Debian and do the same by running their unstable branches, same results though, most likely a broken system.
And you can also install packages from the Arch testing repos - which I really wouldn’t want to - but it’s entirely up to you.
I appreciate the work that goes into testing and patching stuff for Arch a lot. I don’t want my OS to break for no good reason. Getting an update a month earlier is no good reason.
It seems like you’re having a lot of issues – it really shouldn’t be working that way. Here’s how I do it on desktop; should work on the Deck.
Do a pacman -Syu as others have suggested before installing anything new.
From terminal (X used for AUR package name):
Install auracle with pacman -S auracle; it’s a utility to search and install from AUR easily.
auracle clone X will clone the project in the working directory.
auracle buildorder X will give you a list of dependencies needed to build it. If things say satisfied, you already have them.
install the dependencies with pacman -S. You can get fancy by echoing them to a file and using something like sed, or you can just type them manually.
cd into the directory you cloned and build the package with makepkg.
once done, hit up arrow until you see your installation line for those dependencies with pacman. Change that -S to a -Rs (remove them plus any dependencies installed with them).
install the package you just built with pacman -U name-of-package.zst.
profit
If this doesn’t work for you, check where it doesn’t work. It sounds like you may have an issue with pacman rather than the AUR.
Vanilla Gnome. It’s simple/boring, and I like that. It seems like most people that like Gnome don’t care that it’s not a poweruser DE, and aren’t excited to talk about it either.
Me exactly. I’m totally definitely for sure going to try out all the more complicated DEs and widget tools (eww, maybe AwesomeWM if I’m willing to learn Lua or Hyprland if I’m willing to try Wayland)… Someday
In the meantime, my BSPWM + Polybar setup is there and works while I procrastinate on trying anything else.
VSCode is an electron application, right? Electron apps use xwindow (or xwayland) unless you launched them with certain flags. I’m interested to know if native Wayland app actually works. Or is it possible that distrobox is actually use xwindow and pass everything to the host’s xwayland process? Can’t seem to find anything about it in the docs.
Yes, VSCode is an electron app, and I use flags to launch it with Wayland. I export VSCode to the host system with the flags attached, so that VSCode automatically launches in Wayland. The command I used: distrobox-export --app code --extra-flags “–enable-features=WaylandWindowDecorations --ozone-platform-hint=auto”
I’m pretty sure it’s wayland because on KDE wayland, with 200% scaling, when the cursor is over an xwayland window, it looks blurry. This doesn’t happen on wayland windows. Also for some reason electron and chromium based apps run at 60 fps on wayland, while xwayland apps run at 144 fps as it should, and my VS Code in the Distrobox with the wayland flags also runs at 60 fps. Weird KDE stuff.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.