pavucontrol lost settings causing youtube videos did not play among other symptoms. corrected settings … all good
1 Like
I tried to warn people 2 month ago, that this is still a beta feature. Sadly nobody cared…
4 Likes
Isn’t the new Plasma login manager for Plasma version 6.6 and later? The stable branch ships version 6.5.6.
6.5.90 isn’t for 6.5 - it’s a first beta or pre-release of 6.6.
Yes, that is correct. plasma-login-manager is only supposed to be an official component of Plasma — while still leaving the door open for those wanting to use sddm instead — as of Plasma 6.6, and thus, for those of us still on 6.5.x, it’s considered only a pre-release.
4 Likes
But my issue was totally unrelated to plasma-login-manager itself. I guess for everyone else, it will work just fine. I will probably try it again later today, now that I’ve fixed what caused the issue.
2 Likes
I switched my stable install to the new login manager. Worked without any issues.
3 Likes
Hi @philm
Thanks for packaging this latest update. I’m running xfce with a nvidia gpu (590.48.01). It looks like the latest non-free drivers 580.142 / 595.58.03 have a fix to address the screen blinking issue encountered with xfwm.
Can we expect mhwd to have access to 595.58.03 in next month’s stable update?
Best,
James
I found that with auto-login, it sometimes just hung and I didn’t see my desktop. So I’m leaving it until it’s out of beta.
2 Likes
The Botan update issue is related to old CPUs without SSSE3 support. To tell if you have SSSE3 support before upgrading:
PNI implies SSE3
taken from https://unix.stackexchange.com/questions/131954/check-sse3-support-from-bash):
if grep -qE '^flags.* (sse3|pni)' /proc/cpuinfo; then
echo 'Supported!'
else
echo 'Not supported!'
fi
4 Likes
I think the wording could be clearer in the announcement to reflect what you have said above. As without any further context it appears as though anyone should migrate - there is no warning about it being pre-release or for testing only.
I’ve identified lately an issue with dimming the screen while away from the desk.
My device dims the screen to 25% (normally 50%) to save energy after a couple of minutes inactivity
In the past the screen brightness returned to 50% when i moved the mouse or pressed the keyboard.
But now it remain at this 25% brightness. When i use the brightness switch it tells me it is 50%, if i increase it, the 100% are looking like my original 50% before.
Thoughts on that? It’s a Manjaro default install (stable) with KDE
Removing it entirely from the energy options is not a solution for me as it was working before.
there seems to be a pamac issue on fresh systems:
- I just installed the current Manajro 26.0.3 GNOME image on a Dell Optiplex All in One PC that needed to be cleared of windows 10 before being sold on an online fleemarket
- it was the only OS on the PC, I let the installer install everything from scratch with default settings, including erasing the HDD
- everything was fine, LAN and Wireless worked, browsing, libre office.
- it also immediately showed the outstanding updates which is good
- I opened Add/Remove software = pamac
- I did what from the perspective of a new user needs to be done, I clicked Apply in the Update tab and let the update process start, unattended
- when I returned, there was no pamac window, so I started it again to see if I wanted to add some additonal software, assuming the updates went through
- I then saw, that there were still updates to be done, I clicked them (again) and pamac responded in the status bar, that its waiting for another pamac process to finish. Interesting.
- when this didnt change over the next 30 or so minutes, I closed the windows (had to click kill process) and let the computer restart
- the new boot failed, black screen, no kernel found…
so I am telling this in order to help let you check if pamac on the ISO needs to be taken care of in relation to this new update.
From the point of view of a new manjaro user this result would be a red flag I guess. I have no insights if thats Gnome related, if I should have let pamac work even longer, whatever
On my personal system I use KDE und update only the safe way using pacman from TTY…
Please do yourself a favour and never kill a package manager by forcing a reboot or in any other way. Pamac consists of a backend/demon process doing the actual work and several frontends (gui, tray icon, cli). The reason why it takes over 30 minutes may be simply caused by a slow mirror. Anyway never force a reboot until the update process finishes because if it happens to be in the middle of upgrading you’ll end up in a broken state. You could check the process list and/or wait for a notification in your desktop environment.
7 Likes
It is not for testing only, since it works perfectly well for most people, myself included, and I’ve already been using it from the moment it arrived in the Stable branch.
It’s an upstream bug, and it has been fixed in Plasma 6.6.
The problems with pamac are well-known, and there is even an entry about it in the “Known Problems and Solutions” section of post #2. 
Always look at the wiki post before posting about problems, or better still, before updating your system.
5 Likes
Thank you; the CPU does not have SSSE3 support. I hope that a patched package botan 3.11.0-2 will be created or that upstream will release a patched version 3.11.1 so that I do not have to stay on the older versions.
1 Like
I know that and would handle my personal system upgrade differently (no update with the GUI, only via terminal to see the messages). I was playing from the perspective of a new manjaro user with a completely fresh install from ISO and the very first system update, before even trying to understand the system, reading forum posts and wikis.
Since this is that important, I would suggest that a message window opens with pamac during the very first start that explains this and even better links to the wiki.
Otherwise, potential new users could directly turn away from Manjaro after such an experience before even having a chance to get to know the system better and understand.
anyways, this sounds similar to what happened here: Unable to boot manjaro after failed pamac update
2 Likes
Many thanks for the clarification @Aragorn
What is the typical timeframe where the packages are moved to stable? I’ve seen 6.6 is already in unstable, but not yet in testing.
Thanks
2 Likes
Its right that I did kill the second pamac instance (I was asked if I wanted to kill the process after clicking the close button of the window).
More interesting though is what happened with the first pamac process that I started to do the first system update after install. That one must have closed itself / crashed its GUI while still running in the background. Or it crashed too and didnt clean up after itself.
In any case a situation you wouldnt expect/like as a new user.
And as I said before, this was to report such a situation from a new user perspective.
I will update my main system later with pacman… this is what I have learned when I was a Manjaro newbie and it helped me in the transition from Plasma 5.27 to Plasma 6. The explanations made sense to me and I am doing it this way ever since 
1 Like
Well, that is difficult to say, because it depends on what people report in Testing. Sometimes a newer version of single package can seriously delay the update of a whole batch of other packages.
Sometimes we also skip versions in Stable because of the reports in Testing. As an example, say that a newer version of Plasma is released and adopted into Unstable, and that this version is newer than the one in Testing, where in turn the Plasma version is newer than the one in Stable, but with some kind of regression that the newest version in Unstable remedies. So then it boils down to making the wise decision and to not adopt the regressing version into Stable.
But it doesn’t have to be something as elaborate as Plasma. It could just as well be systemd, or it could instead be GNOME. There are no separate updates between Plasma, GNOME and Xfce, and therefore, any component could delay a Stable Update.
This is all part of the curation aspect of Manjaro. Stable is really intended to be as stable as it gets for a rolling-release model — so it’s not like what for instance Debian considers stable.
Also, just because there is a Stable Update does not mean that everything will now be upgraded to the latest version. It all depends on whether it is worth the while pushing out a Stable Update or waiting just a little bit longer and then pushing out a better Stable Update.
When seeking to provide quality — as many people rely on their Manjaro installation for production systems — one has to allow for a certain degree of flexibility in the frequency by which Stable Updates can be pushed out.
We’ve had times when there were two successive Stable Updates over a period of three days, and we’ve had times where there were months between Stable updates due to an unfortunate combination of several individually problematic components. And as hinted at already, the desktop environments — especially Plasma and GNOME, because Xfce is generally better-behaved — are often the decisive factor due to their complexity.
Still — and it really needs to be repeated more often — those who are growing impatient and would like to see more frequent updates can always switch to Testing or even Unstable, the latter being what Arch itself considers stable for them.
And most of the time, Manjaro Unstable is actually quite usable and relatively trouble-free. But to Arch, “most of the time” is good enough. For Manjaro, it’s not. We aim to do better, and that’s why we curate the system.
5 Likes
Thanks. I am simply waiting for getting it updated. Just for this “little” bug i am not going to switch the branch, i am too lazy to fix potential issues 
1 Like