Pamac has been broken ever since pacman moved to a new major version.
Is there a plan to re-introduce it to the distro?
I remember
@artoo was saying that new images will appear at the end of May, I suspect that first the xorg-server mixup and now pamac being gone this would slow down the image creation
Nothing to do with us, it isn't an Artix problem, it's a Pamac problem. We have to wait on the makers of Pamac to change Pamac to work with pacman 5.1.0. They have started working on it: https://github.com/manjaro/pamac/commit/65ae0a678a97d5f31875d9b6279ec8bc8e03d9b3 but we don't know when it will be ready.
The ones from AUR (pamac-aur and pamac-aur-git) which seem to be a newer version than the one on Artix both work with the new pacman.
The ones from the AUR most likely patch it. Will have to check and see.
The comments on the pamac-aur package has people complaining that the update to pacman 5.1.0 breaks it.
The one called pamac-aur-git might already work since it pulls the latest git commits which has some 5.1.0 support. However they have not release a new version of pamac yet, just 1 commit with 5.1.0 code so far.
I would personally like to see users that need a Gui for packages use tkpacman rather than the bloated pamac
I rarely ever use it and that is for an easy way to browse AUR as it orders pkgs by ratings and votes. I wouldn't trust it to install or update anything, especially from AUR.
But, it is not a matter who is using it but that it is an Artix package that is not working or is not installable.
If nobody used it we wouldn't know, would we? But if you had it installed pacman couldn't update till artix/pamac was removed.
Just saying, this is why I advocated to remove all AUR helper packages.
But pamac, and octopi...which is working fine with the updated pacman by the way, are NOT just AUR helpers. They are package managers in their own right. They do not have to be used for AUR.
Best regards.
Yes, tkpacman is a viable option. It's lightweight and can be used with any desktop environment w/o a lot of dependencies.
I personally use octopi and I do like it, but I have tried tkpacman.
Best regards.
That issue can happen to any package. When software gets updated, the software that depends on it either need to get rebuilt against the new lib version, or modified to use the new API. That has nothing to do with being a AUR Helper. This is a rolling release distro problem, and happens to many things. I have had this same issue break my desktop environment, leaving me at the console until the Arch packages for my desktop environment got updated. By your logic we should just remove all packages, who needs a rolling linux distro anyway?
Looks like pamac 6.4.0 just got released to fix the pacman 5.1.0 compat problems. I will update the package when I get home.
I just backported the fixes from pamac into pamac-classic. It should now work as well.
Ok, works. Thank you.
I was expecting to say it is in conflict with pamac-aur-git and ask to remove it first, it didn't, it just returned a bunch of errors because of files owned by that other pkg. So I removed the other one manually and reinstalled, everything ok.
Nothing I can do about that, the AUR is out of our control. However you can ask the maintainer of pamac-aur and pamac-aur-git to add "pamac" and "pamac-classic" to the conflicts in their package build.
I get this error in both user/root in the terminal when starting pamac-manager and I think it comes out when I try preferences:
Error: Error calling StartServiceByName for org.manjaro.pamac.system: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.manjaro.pamac.system': timed out (service_start_timeout=25000ms)
** (pamac-manager:694): CRITICAL **: 17:19:53.890: pamac_system_daemon_get_lock: assertion 'self != NULL' failed
Notify Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files%