For help of others that may experience this its resolved. From sudo rename /home/(user)/.config/audacious folder to something else. Try starting Audacious from the desktop icon. Mine restarted. When you do this Audacious will create a new /.config/audacious folder. Playlists will be empty. In my case one of the things I wanted to save was my playlists. I deleted the Playlists folder in the newly created /config/audacious folder and moved the Playlists folder from the renamed audacious file from .config into the new folder. So far so good, seems to have functionality as before.
Hi, after the update I can login but I canât reach my desktop. Iâve logged in through tty2 and iâve restored my system with timeshift.
I donât have any pacnew file in /etc/pam.d and the cups patchs didnât resolve the problem.
Please tell me what should I do to get some help.
That command enables the cups.service so it auto starts at boot, the --now part says to also start it right after the command is executed so you donât need a reboot for it alone.
This is just evidence that some people are still not familiar enough with systemd, you canât really blame them though because there are so many parts that one needs to get familiar with
But when it comes to the right way of doing things, then i agree with what @Frog suggestedâŚ
Yes that is true, not everyone use printers. Set up printers is sometimes tricky in Linux.
I do not blame Manjaro on this, I understood this is an Arch based distro.
I prefer Manjaro to Arch because I need a rolling distro , that is fast , reliable , but do not update in every hour.
I had issues with upgrading my system with pamac and since then I mainly use pacman to upgrade my system.
So this is pure Arch philosophy , nothing else. Not for average users, right ?
Not so user friendly, RTFM .
I was not aware of the output when updating cups :
[2020-11-28T14:39:01+0100] [ALPM-SCRIPTLET] >>> Cups systemd socket and service files have been
[2020-11-28T14:39:01+0100] [ALPM-SCRIPTLET] >>> renamed by upstream decision. Please make sure
[2020-11-28T14:39:01+0100] [ALPM-SCRIPTLET] >>> to disable/reenable the services to your need.
[2020-11-28T14:39:01+0100] [ALPM-SCRIPTLET] >>> hint: âpacman -Ql cups | grep systemdâ and
[2020-11-28T14:39:01+0100] [ALPM-SCRIPTLET] >>> âls -lR /etc/systemd/ | grep cupsâ
Very strange. I installed LibreOffice-fresh from Manjaro-application-utility with open-jdk (first choice) during installation packages. I received these errors when I launched the application:
âjavaldx failed!
Warning: failed to read path from javaldxâ
Then I removed LibreOffice-fresh and I reinstalled it with pamac, and I tried openjr8 as choice. I didnât have these errors above but LibreOffice donât start.
In the ~./config directory, I donât have libreoffice directory.
Can you try to install unoconv with libreoffice-fresh 7.0.3-2 ? Because I installed it during the first installation with LibreOffice-fresh.
I will give you the result of strace soffice command or libreoffice --strace
I created another user and I will try to launch LibreOffice-fresh with him.
Regards.
Edit: With the other user, Iâve got the same errors.
libreoffice directory is available in the ~/.config directory of the 2 users.
Unoconv package is not installed.
The libreoffice -v command give me this result:
terminate called after throwing an instance of âcom::sun::uno::DeploymentExceptionâ
@Frog
I wonder why it has not been automated with some scripting in post upgrade though. It could have been put in post upgrade of `cups
Because users do not want that a distribution will activate services by upgrade.
@laosom
I love this distro, but this is not really a user friendly in Manjaro. I switched from KDE Neon and I am not used to so many manual hackings after each update.
This is the difference between a rolling release and a distro with stable versions.
In rolling users will get changes time by time. In a stable distro you will get many changes at one point when you install a new version.
In this case, it is more enabling a service that was supposed to be enabled to begin with, but is not anymore because of the name change. By introducing the condition I suggested, it wonât just enable it no matter what, but just if it was enabled beforehand (so it continues to be enabled after the change).
It is not a case of, for example, enabling smb.service and nmb.service by default just because you install the samba package.
Being based on Arch does not imply always follow the philosophy of its parent. There is little to no point to create a fork or a derivative if it is just to follow the same route as the original one.
Ubuntu is based on Debian, and oh boy are they different in term of mentality, am I right?
Manjaro has already derived far from Arch Linux with stuff like having an automated and graphical installer and having GUI tools to manage the system. And Manjaro already goes in a more corporate direction, wanting to sell hardware and stuff; and if they actually want to have a successful business, they will most likely have to go to a direction that will appeal to a broader audience, a broader market (and thus going more and more away from the Arch philosophy) .
No!
There are some little but very impotent things a distro never have to change.
One of these things is:
Never ever activate a system output without asking the user explicitly.
Manjaro will have no users very soon, if they would follow your opinion.
So many changes and so âstableâ that do-release-upgrade leads to an unbootable system unless you jump through the hoops to run grub-install manually at the right moment
I think warning messages at the bottom of the pacman output will be enough.
Search among many text lines in the pacman is very annoying.
I donât think this solution would break the Arch/Manjaro philosophy.